A card limit seems simple until a tip, a fuel pump or a refund hits. Here is how three issuer APIs set and count it.
Card spending controls are rules an issuer platform checks at authorization time to decline a purchase before money moves. They limit where a card can be used (merchant category, merchant ID, country, card-present or not) and how much or how often it can be used over a period. Stripe Issuing, Marqeta and Lithic all offer card spending controls, but they attach them to different objects and count spend in different ways.
Where controls live in three issuer APIs
| Stripe Issuing | Marqeta | Lithic | |
|---|---|---|---|
| Object | spending_controls on a card or a cardholder | Authorization controls and velocity controls | Authorization Rules, including velocity limit rules |
| Levels | Card, cardholder | Program, card product, user | Card, account, program |
| Where rules | Allowed or blocked categories, merchant countries, card presence; merchant ID in private preview | Merchant ID, MCC or MCC group | Conditional action rules on transaction attributes |
| Amount rules | Spending limits per interval, optionally per category | Amount limit and usage (count) limit per velocity window | Amount limit, count limit, or both, per period |
Marqeta does not let a program attach controls to a single card, and in production only Marqeta creates program-level controls, often based on the issuing bank’s requirements. Its guide says controls apply to a user or a card product, and a user-level control affects all of that user’s cards. Stripe’s cardholder limits apply across all of the cardholder’s cards, and a card’s limits carry over to the cards that replace it.
Merchant rules: allow lists and block lists
Stripe takes allowed_categories or blocked_categories. An allow list blocks every category not on it. A block list lets everything else through. Stripe adds that a spending limit alone does not block a category; it has to be paired with one of the two lists.
Marqeta works from the program’s default. A program can block all merchants by default or allow all of them by default, and an authorization control is an exception to that default. The same control with MCC 7011 for hotels blocks hotels in a deny-list program and allows them in an allow-list program. Marqeta also warns that acquirers format merchant IDs differently, with or without leading zeros, so a merchant group should hold every MID form seen in live transactions.
Amount and count limits
Each platform counts spend over time in its own way.
- Stripe: limits per authorization or per interval, such as weekly or monthly. Date-based intervals start at midnight UTC.
- Marqeta: velocity windows such as per day, per week, per month, forever or per transaction, plus a usage limit on the number of transactions.
- Lithic: fixed day, week, month or year windows aligned to midnight Eastern time, or a custom rolling window from 10 seconds to about 31 days. A rule can be scoped to one card or to all cards on an account, and filtered by MCC, country or PAN entry mode.
Defaults matter too. Stripe applies a 500 USD daily limit to a new card when no spending_limits are set, and an unconfigurable 10,000 USD limit on each authorization. Lithic says that for customers onboarded after February 1, 2026, no default account limits are set, and new programs should use velocity limit rules instead of its older spend limits.
Where limits leak
Limits act on authorizations, and several things happen outside them.
| Gap | What the provider says |
|---|---|
| Aggregation delay | Stripe aggregates spend on a best-effort basis, with a delay of up to 30 seconds. Lithic says its older spend limits may miss transactions from the past several seconds. |
| Clearing above the authorized amount | Stripe notes that tips and fees posted later can push spend past a limit. Marqeta names automated fuel dispenser transactions. Lithic gives the case of a $90 authorization that clears at $110. |
| Force-posted charges | Lithic’s spend limits cannot block a clearing message sent without a prior authorization. |
| Refunds | In Marqeta, a refund restores the amount limit but still counts against the usage limit, and refunds cannot lift spend above the set amount. |
None of these spend counters is a ledger. Lithic says its spend limits are not built for balance tracking or reconciliation-level accuracy, and points programs to its balances product for that. The issuer ledger still has to reconcile authorizations, clearings and reversals; see card authorization reversal.
Static controls and real-time decisions
Static controls run first. In Stripe Issuing, spending controls can decline a purchase before the issuing_authorization.request reaches the program’s own endpoint. Programs that need their own logic answer that synchronous webhook. Stripe waits 2 seconds for an approve or decline answer and then applies the program’s timeout or Autopilot settings.
Lithic’s Auth Stream Access sends the authorization to the program’s endpoint as an HTTP POST. If no response arrives within 6 seconds, the transaction is declined. Lithic recommends answering within 3 seconds, because merchants and acquirers time out too, and slow approvals are more often voided soon after.
Lithic also lets a team test a rule before it bites. A new Authorization Rule starts as a draft that runs in shadow mode next to the active version, so the team can see what it would decline before promoting it.
A checklist for a new card program
- Decide the level for each rule: card, cardholder or user, card product, account or program.
- Know the program’s default: allow all merchants or block all.
- Pair amount limits with category rules where the category matters.
- Record every merchant ID format the program sees before building merchant groups.
- Plan for spend that clears above the authorized amount, and for force posts.
- Test new rules in shadow mode where the platform offers it.
- Monitor timeouts on real-time decisioning, not only approval rates.
Issuer processors differ in how much of this they expose; see how to choose an issuer processor and card issuing platforms.
