# Issuing authorizations Learn how to use Issuing to handle authorization requests. When a card is used to make a purchase, it generates an authorization request, which is approved or declined based on the following steps: 1. Stripe checks that the [balance used for Issuing](https://docs.stripe.com/issuing/funding/balance.md) has sufficient funds, that the card is active, and that your [spending controls](https://docs.stripe.com/issuing/controls/spending-controls.md) allow the authorization. Sometimes, Stripe [immediately approves or declines the authorization request](https://docs.stripe.com/issuing/purchases/authorizations.md#scenarios-without-a-real-time-authorization-request) at this stage. 1. Stripe sends an `issuing_authorization.request` event. If you don’t have a real-time authorization webhook, we approve the authorization without sending the `issuing_authorization.request`. > #### Listen for Stripe events > > Set up a [real-time authorization webhook](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) to listen for this event so you can synchronously approve/decline Authorizations. 1. You can [approve or decline](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) the authorization by responding directly to the webhook event. If you don’t approve or decline the `issuing_authorization.request` within 2 seconds, Stripe uses your [webhook timeout settings](https://dashboard.stripe.com/settings/issuing) to approve or decline the authorization. 1. Stripe sends an `issuing_authorization.created` event, notifying you of the [Authorization](https://docs.stripe.com/api.md#issuing_authorization_object) creation and decision. (See full diagram at https://docs.stripe.com/issuing/purchases/authorizations) ## Scenarios without a real-time authorization request Sometimes, Stripe receives an authorization request from the card network and approves or declines it without sending you an `issuing_authorization.request` event: - If Stripe decides that the authorization request can’t be approved (for example, because the card is inactive or your [spending controls](https://docs.stripe.com/issuing/controls/spending-controls.md) don’t allow it), we’ll decline it. - If you don’t have a [real-time authorization webhook](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) configured, and we don’t have a reason to decline the authorization request, we’ll approve it. When this occurs, Stripe still sends an `issuing_authorization.created` event, notifying you of the [Authorization’s](https://docs.stripe.com/api.md#issuing_authorization_object) creation. ### Refunds Many businesses send real-time authorization requests for refunds. Stripe has default logic in place to process these requests. If the business proceeds with sending the refund, you’ll see a [refund transaction](https://docs.stripe.com/issuing/purchases/transactions.md?issuing-capture-type=refunds#handling-other-transactions) object. ## Authorization updates When Stripe receives an authorization request, we send an `issuing_authorization.created` [webhook](https://docs.stripe.com/webhooks.md) event. If you approve the authorization, we deduct the `amount` from your Issuing balance and hold it in reserve until the authorization is either captured, voided, or expired without capture. If you decline the authorization, the status is set to `closed` and we don’t place any holds. When the authorization is captured, a [transaction](https://docs.stripe.com/issuing/purchases/transactions.md) is created and the `status` of the authorization is set to `closed`. If the authorization request is voided, we send an `issuing_authorization.updated` [webhook](https://docs.stripe.com/webhooks.md) event with its `status` set to `reversed` and the `amount` as `0`. We add the voided amount back to your Issuing balance, essentially undoing the balance impact of the original authorization. Stripe can expire an authorization by releasing the hold on the balance of an authorization after a period of time. If the authorization request expires without capture, we send an `issuing_authorization.updated` [webhook](https://docs.stripe.com/webhooks.md) event with its `status` set to `expired` in API versions 2025-03-31.basil or later, or status set to `reversed` in API versions 2025-03-31.basil or earlier. The `amount` field represents any remaining amount authorized for possible late captures. We add the expired amount back to your Issuing balance, essentially undoing the balance impact of the original authorization. This table describes the sequence of operations on an authorization and the status associated with each operation: | Operations on the authorization object | Status (on versions 2025-03-31.basil and newer) | | ------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Waiting for response to the real-time authorization request | Pending | | The authorization is declined on the response associated with the real-time authorization request | Closed | | The authorization is approved, but pending capture | Pending | | The authorization is approved and then fully captured | Closed | | The authorization is approved and then partially captured | Pending | | The authorization is approved and then fully reversed | Reversed | | The authorization is approved and then partially reversed | Pending | | The authorization is approved and then expired by Stripe | Expired | | The authorization is approved, partially captured, and then the balance is fully reversed | Closed | | The authorization is approved, partially captured, and then expired by Stripe | Closed | | The authorization is approved, partially reversed, and then the balance is fully captured | Closed | | The authorization is approved, partially reversed, and then expired by Stripe | Expired | | The authorization is approved, expired by Stripe, and then fully captured | Expired | | The authorization is approved, expired by Stripe, and then partially captured | Expired | | The authorization is approved, expired by Stripe, and then fully reversed | Reversed | | The authorization is approved, expired by Stripe, and then partially reversed | Expired | ## Purchases in different currencies Cards can be used for purchases in any currency that the card network supports. Stripe automatically converts the currency of the purchase into the card’s currency when holding funds, using the card network’s daily rate. The `merchant_amount` represents the cost of the purchase in the local currency. The `amount` field represents the expected amount of the `Transaction` in the card’s currency and isn’t final until the `Authorization` has been captured. ## Handling other authorizations In addition to regular authorizations, there are a few other cases that you should be ready to handle. #### Partial authorization Some authorizations are partially authorized to limit spending. This allows you to authorize a specific lower amount and is useful when there aren’t sufficient funds to cover the full purchase. Fueling stations in the US are a special example of this. Learn more about [fuel dispenser transactions](https://docs.stripe.com/issuing/purchases/authorizations.md#fuel-dispenser-transactions). When an authorization is partially authorized, the `is_amount_controllable` field on the authorization request is set to `true`. You can specify the amount you want to approve by setting the `amount` in the webhook response body or the [approve](https://docs.stripe.com/api/issuing/authorizations/approve.md) call. If you partially approve a cashback authorization, you must approve the full cashback amount. You can’t set the approved `amount` lower than the `cashback_amount`. (See full diagram at https://docs.stripe.com/issuing/purchases/authorizations) ### Testing To simulate the creation of a new partial authorization, you can use the [Authorization Create API](https://docs.stripe.com/api/issuing/authorizations/test_mode_create.md) in the Issuing test helpers. ```curl curl https://api.stripe.com/v1/test_helpers/issuing/authorizations \ -u "<>:" \ -d card="{{ISSUINGCARD_ID}}" \ -d amount=100 \ -d "merchant_data[category]"=automated_fuel_dispensers \ -d is_amount_controllable=true ``` #### Incremental authorization Incremental authorizations are additional authorizations that come in after an original authorization. These are common in the hotel industry, for instance to cover room service or cleaning fees after checking out. (See full diagram at https://docs.stripe.com/issuing/purchases/authorizations) You can approve or decline incremental requests with the same [webhook integration](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) as regular authorizations. When incremental authorizations occur, Stripe sends another `issuing_authorization.request` event for the original `Authorization` object so you can decide whether to approve the updated amount. This object has an updated `pending_request`, with `pending_request.amount` corresponding to the requested incremental amount. (See full diagram at https://docs.stripe.com/issuing/purchases/authorizations) Note that `approved` is `true`, because the original authorization remains approved, and that `status` is `pending` because it isn’t cleared yet. The top-level `amount` field corresponds to the original, approved amount for the authorization. In the example above, if you approve the incremental amount, `authorization.amount` updates to 120 USD. If you decline the incremental amount, `approved` is still `true` (because the original authorization request remains approved), and `authorization.amount` remains 100 USD. Any approved incremental amount is deducted from your Issuing balance. Approving an incremental authorization extends the expiration date. You can see a history of requests for an authorization in the `request_history` of the `Authorization`. ### Testing To simulate an increment in authorization, you can use the [Authorization Increment API](https://docs.stripe.com/api/issuing/authorizations/test_mode_increment.md) in the Issuing test helpers. ```curl curl https://api.stripe.com/v1/test_helpers/issuing/authorizations/{{ISSUINGAUTHORIZATION_ID}}/increment \ -u "<>:" \ -d increment_amount=4242 ``` #### Partial reversal If a business decides to reduce the amount authorized, they can perform a partial reversal. Partial reversals affect the original authorization and create `issuing_authorization.updated` events, where the original authorization’s `amount` and `merchant_amount` lowers. Surplus held funds release back to your available balance immediately. ### Testing To simulate a partial reverse of an authorization, you can use the [Authorization Reverse API](https://docs.stripe.com/api/issuing/authorizations/test_mode_reverse.md) in the Issuing test helpers. If you don’t specify the `reverse_amount` parameter, the total amount reverses. ```curl curl https://api.stripe.com/v1/test_helpers/issuing/authorizations/{{ISSUINGAUTHORIZATION_ID}}/reverse \ -u "<>:" \ -d reverse_amount=4242 ``` #### Card verifications A merchant can use a card verification (sometimes called an “Account Verification”, “Account Status Inquiry”, or “Zero Amount Authorization”) to ensure a card is valid without requesting any funds. For example, a subscription service might use a card verification to validate a card used to sign up for a free trial. By default, Stripe approves all card verifications that pass basic security checks. ## Fuel dispenser transactions When a cardholder attempts a purchase at a fuel dispenser ([MCC 5542](https://docs.stripe.com/issuing/categories.md)), an `issuing_authorization.request` for 1 USD is sent (called a “status check”). The default amount held is 100 USD to cover the unknown purchase amount. When the cardholder finishes pumping fuel, an `issuing_authorization.updated` event is sent to reflect the amount of the purchase. When the fuel dispenser allows a [partial authorization](https://docs.stripe.com/issuing/purchases/authorizations.md?issuing-authorization-type=partial_authorization#handling-other-authorizations) by setting the field `is_amount_controllable` to `true`, you can respond with a lesser approved amount (for example, 50 USD). However, when a fuel dispenser doesn’t allow partial authorizations, you must either approve the network default amount (Stripe ignores any amount you specify), or decline the entire authorization. For [Commercial Fleet programs](https://docs.stripe.com/issuing/customize-your-program.md#card-product-type), Stripe receives some information in the Issuing Authorization [fleet](https://docs.stripe.com/api/issuing/authorizations/object.md#issuing_authorization_object-fleet) and [fuel](https://docs.stripe.com/api/issuing/authorizations/object.md#issuing_authorization_object-fuel) hashes after the fuel has been dispensed. As a result, some of these fields won’t be populated during the `issuing_authorization.request` webhook and will be sent later in the `issuing_authorization.updated` webhook. ## Using with Financial Accounts for platforms Authorizations on cards that use funds stored in [FinancialAccounts](https://docs.stripe.com/api/treasury/financial_accounts.md) have a [`treasury` field](https://docs.stripe.com/api/issuing/authorizations/object.md#issuing_authorization_object-treasury) with references to related resources: [Transaction](https://docs.stripe.com/api/treasury/transactions.md), [ReceivedCredit](https://docs.stripe.com/api/treasury/received_credits.md), and [ReceivedDebit](https://docs.stripe.com/api/treasury/received_debits.md). ## Scenarios with no record of declined authorizations in the Dashboard or API In some cases, an authorization made with an Issuing Card might be declined and neither you or your connected accounts will receive a webhook event or an authorization record (`iauth_`). In these cases, make sure that you collect as much information as possible about the declined authorization before reaching out to Stripe support for assistance. We recommend including the following information: - The time of the decline - The cardholder (`ich_`) who made the purchase - The card (`ic_`) used for the authorization - The merchant involved in the authorization - Any other circumstances surrounding the authorization It’s possible that the authorization is declined before any related information is transmitted to Stripe. In these cases, the cardholder involved must directly contact the business to determine the cause of the decline because Stripe hasn’t received a record of the authorization request. You might encounter additional instances of declines without an associated webhook event or authorization object that Stripe can assist with. To determine the classification of the decline, contact Stripe support with the information provided above. We can help to determine the most appropriate steps to investigate the declines.