Card authorization controls
An authorization requests approval for an amount before the merchant submits it for settlement. You can restrict which requests Increase approves by declaring controls on the card, deciding each request through a real-time webhook, or using both. These rules govern authorization; they do not prevent a merchant from submitting a different amount for settlement.
Where a rule lives
Declare controls on the card when the rule depends on an amount, the card’s spending history, or the merchant information in the request. Increase evaluates these controls without a round trip to your server. A vendor card restricted to one merchant and $250 can use card controls alone, and those controls keep working when your server is unavailable.
Use Real-time decisions for rules that depend on state only your application holds: an invoice’s approval status, an employee’s remaining budget across several cards, or whether a trip is still active. Your handler must retrieve and action the decision before its deadline. If you subscribe to authorization decisions, passing the card’s controls still requires a response from your handler. By default, a timeout declines the request.
You can combine the two. Declare a monthly limit on an employee’s card and use your handler to check whether the employee is still permitted to spend. The handler can decline a request that passed the card’s controls, but cannot approve one that failed them.
Creating a card with controls
Include authorization_controls in the body of POST /cards. This sandbox request creates a single-use card for exactly $250, restricted to one merchant acceptor ID. Replace ACCOUNT_ID with your sandbox Account ID and use your sandbox API key. Amounts are in cents.
curl -X "POST" \
--url "https://sandbox.increase.com/cards" \
-H "Authorization: Bearer ${INCREASE_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"account_id": "ACCOUNT_ID",
"description": "Vendor invoice",
"authorization_controls": {
"usage": {
"category": "single_use",
"single_use": {
"settlement_amount": {
"value": 25000,
"comparison": "equals"
}
}
},
"merchant_acceptor_identifier": {
"allowed": [{"identifier": "5665270011000168"}]
}
}
}'For an existing card, send authorization_controls to PATCH /cards/{card_id}. See the create and update references for the full request shapes.
You can also configure usage, spending limits, and merchant category or acceptor restrictions in the Dashboard. Open the card and select Authorization controls.
Card authorization controls work the same way in sandbox. Use the card authorization simulation to test requests against your controls.
Restricting usage and amount
One payment
Use a single-use card for one payment of a known or bounded amount. For a $250 invoice, require exactly $250. If the final invoice is not yet known, permit an authorization of at most $250. A $200 approval consumes the single use; it does not leave $50 for another payment.
For a positive authorization amount, Increase counts the card’s prior authorizations and single-message financial transactions, then subtracts full authorization reversals. If that count is greater than zero, the request is declined. Otherwise, Increase compares the requested amount in the settlement currency with the configured amount. This comparison happens during authorization, despite the API’s use of the name settlement_amount.
A full reversal restores the use. A partial reversal, expiration, or refund does not. A zero-dollar validation bypasses the single-use count and amount comparison, but still has to pass the merchant restrictions. Refund authorizations bypass card controls; recorded refund authorizations and financial transactions are nevertheless included in the single-use count.
Repeated spending
Use a multi-use card with spending limits for repeated payments. A $2,000 monthly limit permits requests until the amount already counted plus the new request would exceed $2,000. A request that brings the total to exactly $2,000 passes this control.
Limits can apply to each request, a calendar day, week, month, or the card’s lifetime. A limit can cover all merchants or only specified merchant category codes (MCCs), the four-digit codes that classify a merchant’s business. A category-specific limit counts only spending in those categories and does not restrict requests in other categories.
All matching limits apply. With a $2,000 monthly limit across all merchants and a $500 monthly restaurant limit, a restaurant authorization needs capacity under both. A narrower limit does not override a broader one.
Restricting merchants
Merchant restrictions compare the information in the authorization request with an allow list or a block list:
- Merchant categories restrict types of business. An office supplies category restriction applies to merchants classified in that category, not to individual items in a purchase.
- Merchant acceptor IDs restrict particular acceptors. The merchant acceptor ID identifies the merchant accepting the payment; it is distinct from the merchant descriptor displayed with the transaction. Use the ID submitted in authorizations for the vendor you intend to pay.
- Merchant countries restrict the merchant country reported in the request, using two-letter country codes such as
USandCA. This does not establish the cardholder’s location.
An allow list declines values outside the list. A block list declines values in the list. Choose one list type for each dimension; the API does not accept both for the same dimension. Omit a dimension to impose no additional restriction on it. Category, acceptor, and country restrictions all apply together, along with the usage and amount controls.
These lists cannot override Increase’s built-in restrictions. See Card issuing fraud controls for the built-in restrictions and recommended categories and countries to consider for your program.
Evaluation and declines
For a purchase authorization, Increase first checks card and account eligibility and built-in controls, including restricted categories and countries, verification failures, and merchant blocking. We then evaluate the card’s usage and spending limits, followed by its category, acceptor, and country restrictions. Any breach declines the request before your authorization webhook is sent.
If those checks pass and you have an authorization decision subscription, we send the real-time webhook. Available balance is checked after your approval, using the approved amount. Without that subscription, available balance is checked before the card controls. An approval from your handler therefore does not override insufficient available funds. Card controls evaluate the requested amount before your handler can offer a partial approval.
A card-control decline creates a Declined Transaction with source.card_decline.reason of breaches_limit. This reason covers merchant restrictions as well as amount limits; it does not identify the individual rule. For Visa, Increase returns response code 61, activity amount limit exceeded. The merchant controls the message shown to the cardholder and does not receive your control configuration. A declined initial authorization creates no hold. A declined increment leaves the existing hold in place.
Limits through the payment lifecycle
Increments and settlements
An increment requests an additional amount against an existing authorization. Increase evaluates that additional amount against the controls currently on the card. With $800 counted against a $1,000 monthly limit, a $200 increment passes and a $201 increment fails. Once approved, the increment increases the pending hold used by subsequent limit checks.
A per-transaction limit compares only the amount of the current request. A $500 authorization followed by a $100 increment can pass a $500 per-transaction limit even though the hold reaches $600. Use an interval limit if the accumulated amount matters. A single-use card declines a positive increment once its initial authorization has consumed the use.
Settlement does not run authorization controls or send an authorization decision webhook. A merchant can settle $1,050 against a $1,000 hold even when the card has a $1,000 limit. The $1,050 settlement counts toward subsequent interval checks, which can then decline further spending. An exact-amount single-use control likewise checks the authorization, not the eventual settlement.
Reversals and refunds
A reversal reduces or releases an authorization’s pending hold. A partial reversal from $800 to $300 reduces the amount counted to $300; a full reversal removes the pending amount. Expiration also removes the hold from the running total. These changes restore interval capacity only if that hold was counted in the interval.
A refund posts a separate credit. Refunds and pending refund authorizations do not subtract from the spending total, so a $100 refund after a $500 settlement leaves $500 counted. Refund authorizations still undergo Increase’s initial eligibility and built-in restriction checks, but bypass the card’s controls and the authorization decision webhook.
Interval boundaries
Daily limits reset at midnight UTC, weekly limits on Monday at midnight UTC, and monthly limits on the first of the month at midnight UTC. These are calendar intervals, not rolling windows. Lifetime limits do not reset.
Increase selects records by when each was created. A pending authorization is assigned to the interval containing its original creation time, even if it is incremented later. A settlement is assigned to the interval in which the settlement record is created. An authorization on September 30 that settles on October 1 therefore counts against September while pending, then against October when settled. An older hold still pending on October 1 is excluded from October’s monthly total; incrementing it does not change its original creation time.
Changing controls
Updating authorization_controls replaces the previous control set rather than merging individual rules. Include the controls you intend to retain. An update that omits authorization_controls leaves the existing set in place.
The new set applies when Increase next evaluates a request, including an increment on an existing authorization. It does not cancel existing holds, re-evaluate an authorization already sent to your handler, or prevent settlement. Changing controls also does not clear spending history: new limits use the card’s existing records within the selected interval. Lowering a monthly limit below the amount already counted causes subsequent positive requests to decline.