Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Developer tools
Get started
Payments
Finance automation
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Overview
Start an integration
Products
Global Payouts
Capital
Issuing cards
    Overview
    How Issuing works
    Global availability
    Manage fraud
    Cards
    Choose your card type
    Virtual cards
    Issue virtual cards
    Physical cards
    Manage cards
    Digital wallets
    Replacement cards
    Card programs
    Program management
    Customize your card program
    Add funds to your card program
    Credit Consumer Issuing
    Controls
    Spending controls
    Advanced fraud tools
    3DS
    Fraud challenges
    Real-time authorizations
    PIN management
    Issuing Elements
    Token Management
    Funding
    Balance
    Postfund your integration with Stripe
    Postfund your integration with Dynamic Reserves
    Purchases
    Authorizations
    Transactions
    Disputes
    Testing
    Merchant categories
    ATM Usage
    Issuing with Connect
    Set up an Issuing and Connect integration
    Update terms of service acceptance
    Connect funding
    Connected accounts, cardholders, and cards
    Embed card management UI
    Credit
    Overview
    Set up connected accounts
    Manage credit terms
    Report other credit decisions and manage AANs
    Report required regulatory data for credit decisions
    Manage account obligations
    Test credit integration
    Additional information
    Choose a cardholder type
    Customer support for Issuing and Treasury
    Issuing watchlist
    Marketing guidance (Europe/UK)
    Product and marketing compliance guidance (US)
Treasury
Manage money
HomeMoney managementIssuing cards

Issuing authorizations

Learn how to use Issuing to handle authorization requests.

Copy page

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.

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:

Operations on the authorization objectStatus (on versions 2025-03-31.basil and newer)
Waiting for response to the real-time authorization requestPending
The authorization is declined on the response associated with the real-time authorization requestClosed
The authorization is approved, but pending capturePending
The authorization is approved and then fully capturedClosed
The authorization is approved and then partially capturedPending
The authorization is approved and then fully reversedReversed
The authorization is approved and then partially reversedPending
The authorization is approved and then expired by StripeExpired
The authorization is approved, partially captured, and then the balance is fully reversedClosed
The authorization is approved, partially captured, and then expired by StripeClosed
The authorization is approved, partially reversed, and then the balance is fully capturedClosed
The authorization is approved, partially reversed, and then expired by StripeExpired
The authorization is approved, expired by Stripe, and then fully capturedExpired
The authorization is approved, expired by Stripe, and then partially capturedExpired
The authorization is approved, expired by Stripe, and then fully reversedReversed
The authorization is approved, expired by Stripe, and then partially reversedExpired

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.

Some authorizations are partially authorized to limit spending. This allows you to authorize a specific lower amount and is useful when there are not sufficient funds to cover the full purchase.

Fueling stations in the US are a special example of this. Learn more about 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 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.

Testing

To simulate the creation of a new partial authorization, you can use the Authorization Create API in the Issuing test helpers.

Command Line
cURL
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 Stripe Treasury

Authorizations 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 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.

Was this page helpful?
YesNo
Need help? Contact Support.
Join our early access program.
Check out our changelog.
Questions? Contact Sales.
LLM? Read llms.txt.
Powered by Markdoc