Skip to main content
Spend control lets you declare velocity caps on each card without tracking the cardholder’s accrued spend yourself. You set the caps; the issuer enforces them at authorization time. Each card has two transaction-type buckets:
  • sales — purchase (point-of-sale) transactions
  • cash — cash withdrawal (ATM) transactions
Each bucket accepts up to six independent caps. Omit a key to leave that bucket uncapped on that horizon.

Set spend control

The example above caps in-store purchases at $200 per transaction, $1,000 per day, and $50,000 over the card’s lifetime — and disables cash withdrawals entirely by setting an allTime cap of 0.

Read spend control

GET /partner/cards/{id} returns the active caps under spendControl. Where the card program supports it, accrued spend is reported under spendControl.spent:

Common patterns

Cash-disabled card. Set cash.allTime: 0 to block ATM withdrawals while leaving purchases uncapped.
Lifetime budget card. Cap total purchases over the card’s lifetime — useful for one-shot expense cards or per-vendor budgets.
Daily allowance. Cap purchases per calendar day with a per-transaction ceiling for fraud control.

Card program capabilities

Not every card program supports every cap horizon. Caps a program cannot enforce are rejected at request time with a 400 and the message Card program "<name>" does not support <capKey> spend-control cap. Ask your Contro admin which caps the programs assigned to your account support.

Migrating from { limit }

The legacy body { "limit": 5000 } is still accepted on PATCH /partner/cards/{id}/limits and is mapped to:
Send null to clear the cap. The legacy limit field will be removed in a future release — switch to spendControl to take advantage of per-transaction-type caps and finer-grained horizons.