# Issuing authorizations Learn how to use Issuing to handle authorization requests. When a card is used to make a purchase, it generates an authorisation 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 authorisation. Sometimes, Stripe [immediately approves or declines the authorisation 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 authorisation webhook, we approve the authorisation without sending the `issuing_authorization.request`. > #### Listen for Stripe events > > Set up a [real-time authorisation webhook](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) to listen for this event so you can synchronously approve/decline Authorisations. 1. You can [approve or decline](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) the authorisation 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 authorisation. 1. Stripe sends an `issuing_authorization.created` event, notifying you of the [Authorisation](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 authorisation request Sometimes, Stripe receives an authorisation request from the card network and approves or declines it without sending you an `issuing_authorization.request` event: - If Stripe decides that the authorisation 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 authorisation webhook](https://docs.stripe.com/issuing/controls/real-time-authorizations.md) configured, and we don’t have a reason to decline the authorisation request, we’ll approve it. When this occurs, Stripe still sends an `issuing_authorization.created` event, notifying you of the [Authorisation’s](https://docs.stripe.com/api.md#issuing_authorization_object) creation. ### Refunds Many businesses send real-time authorisation 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 authorisation request, we send an `issuing_authorization.created` [webhook](https://docs.stripe.com/webhooks.md) event. If you approve the authorisation, we deduct the `amount` from your Issuing balance and hold it in reserve until the authorisation is either captured, voided, or expired without capture. If you decline the authorisation, the status is set to `closed` and we don’t place any holds. When the authorisation is captured, a [transaction](https://docs.stripe.com/issuing/purchases/transactions.md) is created and the `status` of the authorisation is set to `closed`. If the authorisation 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 authorisation. Stripe can expire an authorisation by releasing the hold on the balance of an authorisation after a period of time. If the authorisation 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 authorised for possible late captures. We add the expired amount back to your Issuing balance, essentially undoing the balance impact of the original authorisation. This table describes the sequence of operations on an authorisation and the status associated with each operation: | Operations on the authorisation object | Status (on versions 2025-03-31.basil and newer) | | ------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Waiting for response to the real-time authorisation request | Pending | | The authorisation is declined on the response associated with the real-time authorisation request | Closed | | The authorisation is approved, but pending capture | Pending | | The authorisation is approved and then fully captured | Closed | | The authorisation is approved and then partially captured | Pending | | The authorisation is approved and then fully reversed | Reversed | | The authorisation is approved and then partially reversed | Pending | | The authorisation is approved and then expired by Stripe | Expired | | The authorisation is approved, partially captured, and then the balance is fully reversed | Closed | | The authorisation is approved, partially captured, and then expired by Stripe | Closed | | The authorisation is approved, partially reversed, and then the balance is fully captured | Closed | | The authorisation is approved, partially reversed, and then expired by Stripe | Expired | | The authorisation is approved, expired by Stripe, and then fully captured | Expired | | The authorisation is approved, expired by Stripe, and then partially captured | Expired | | The authorisation is approved, expired by Stripe, and then fully reversed | Reversed | | The authorisation 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 `Authorisation` 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 authorisations are partially authorised to limit spending. This allows you to authorise a specific lower amount and is useful when there aren’t sufficient funds to cover the full purchase. Fuelling 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 authorisation is partially authorised, the `is_amount_controllable` field on the authorisation 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 authorisation, 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 authorisation, you can use the [Authorisation 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 authorisations. When incremental authorisations 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 authorisation 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 authorisation. 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 authorisation request remains approved), and `authorization.amount` remains 100 USD. Any approved incremental amount is deducted from your Issuing balance. Approving an incremental authorisation extends the expiry date. You can see a history of requests for an authorization in the `request_history` of the `Authorization`. ### Testing To simulate an increment in authorisation, you can use the [Authorisation 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 authorised, they can perform a partial reversal. Partial reversals affect the original authorisation and create `issuing_authorization.updated` events, where the original authorisation’s `amount` and `merchant_amount` lowers. Surplus held funds release back to your available balance immediately. ### Testing To simulate a partial reverse of an authorisation, you can use the [Authorisation 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 Authorisation”) 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 authorisation](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 authorisations, you must either approve the network default amount (Stripe ignores any amount you specify), or decline the entire authorisation. For [Commercial Fleet programmes](https://docs.stripe.com/issuing/customize-your-program.md#card-product-type), Stripe receives some information in the Issuing Authorisation [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 Authorisations 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 authorisations in the Dashboard or API In some cases, an authorisation made with an Issuing Card might be declined and neither you or your connected accounts will receive a webhook event or an authorisation record (`iauth_`). In these cases, make sure that you collect as much information as possible about the declined authorisation before contacting 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 authorisation - The merchant involved in the authorisation - Any other circumstances about the authorisation It’s possible that the authorisation 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 authorisation request. You might encounter additional instances of declines without an associated webhook event or authorisation 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.