Issuing authorizations

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

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

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

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

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

Authorization updates

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

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 authorisation 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, Stripe receives some information in the Issuing Authorisation 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 Stripe Treasury

Authorisations on cards that use funds stored in Treasury FinancialAccounts have a treasury field with references to Treasury resources: Treasury Transaction, ReceivedCredit, and ReceivedDebit.

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.