Issuing authorizations

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 has sufficient funds, that the card is active, and that your spending controls allow the authorization. Sometimes, Stripe immediately approves or declines the authorization request at this stage.

2. 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 to listen for this event so you can synchronously approve/decline Authorizations.

3. You can approve or decline 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 to approve or decline the authorization.

4. Stripe sends an issuing_authorization.created event, notifying you of the Authorization creation and decision.

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 don’t allow it), we’ll decline it.
• If you don’t have a real-time authorization webhook 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 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 object.

Authorization updates

When Stripe receives an authorization request, we send an issuing_authorization.created webhook 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 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 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 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:

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 is not 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.

curl https://api.stripe.com/v1/test_helpers/issuing/authorizations \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d card=
"{{CARD_ID}}" \
  -d amount=100 \
  -d "merchant_data[category]"=automated_fuel_dispensers \
  -d is_amount_controllable=true

Fuel dispenser transactions

When a cardholder attempts a purchase at a fuel dispenser (MCC 5542), 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 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, Stripe receives some information in the Issuing Authorization fleet and 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 have a treasury field with references to related resources: Transaction, ReceivedCredit, and ReceivedDebit.

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.