Issuing real-time authorizations

Using the synchronous webhook, you can approve or decline authorization requests in real time.

Your webhook endpoint can be configured in your settings. When a card is used to make a purchase, Stripe creates an issuing_authorization.request and sends it to your configured endpoint for your approval.

Get started with our interactive guide to real-time authorisations.

Responding to authorization requests

You can respond to authorisation requests by responding directly to the webhook event.

Respond directly

Respond to the issuing_authorization.request webhook event directly to either approve or decline an authorisation after it’s received.

Webhook response

Our webhook accepts JSON responses with the following parameters:

Status code: Return 200 to indicate success.

Header:

Body:

# Using Sinatra.
require 'sinatra'
require 'stripe'

set :port, 4242

# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 
'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

# Replace with a real secret. You can find your endpoint's secret in your webhook settings.
webhook_secret = 'whsec_...'

post '/webhook' do
  payload = request.body.read
  sig_header = request.env['HTTP_STRIPE_SIGNATURE']

  event = nil

  # Verify webhook signature and extract the event.
  begin
    event = Stripe::Webhook.construct_event(
      payload, sig_header, webhook_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload.
    status 400
    return
  rescue Stripe::SignatureVerificationError => e
    # Invalid signature.
    status 400
    return
  end

  if event['type'] == 'issuing_authorization.request'
    auth = event['data']['object']
    # ... custom business logic

    status 200
    header 'Stripe-Version' => '2025-03-31.basil', 'Content-Type' => 'application/json'
    data = { 'approved' => true }
    body data.to_json
  end
  # ...handle other cases
end

Make an API call Deprecated

This documentation is maintained for existing users. If you’re a new user, respond directly to the webhook. If you’re an existing user, plan to migrate to the direct webhook response. You can follow our direct webhook migration guide.

Make an API call to either approve or decline the request and include the Authorisation ID. If you use this method, your webhook must approve or decline each authorisation before responding to the incoming webhook request.

# Using Sinatra.
require 'sinatra'
require 'stripe'

set :port, 4242

# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 
'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

# Uncomment and replace with a real secret. You can find your endpoint's
# secret in your webhook settings.
# webhook_secret = 'whsec_...'

post '/webhook' do
  payload = request.body.read
  sig_header = request.env['HTTP_STRIPE_SIGNATURE']

  event = nil

  # Verify webhook signature and extract the event.
  begin
    event = Stripe::Webhook.construct_event(
      payload, sig_header, webhook_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload.
    status 400
    return
  rescue Stripe::SignatureVerificationError => e
    # Invalid signature.
    status 400
    return
  end

  if event['type'] == 'issuing_authorization.request'
    auth = event['data']['object']
    handle_authorization(auth)
  end

  status 200
end

def handle_authorization(auth)
  # Authorize the transaction
  authorization = Stripe::Issuing::Authorization.approve(auth["id"])
end

We recommend that you only use one of these two methods to respond to authorisation requests. For users migrating from one method to another, both methods are supported during a migration. In the event both methods are used on the same authorisation, the API call takes precedence over the direct response. For migrations, we recommend only using one method on a given request at a time.

If Stripe doesn’t receive your approve or decline response or request within 2 seconds, the Authorization is automatically approved or declined based on your timeout settings.

Authorization requests

When an authorization request is sent to your webhook, the amount requested is stored in pending_request.

{
  "id": "iauth_1CmMk2IyNTgGDVfzFKlCm0gU",
  "object": "issuing_authorization",
  "approved": false,
  "amount": 0,
  "currency": "usd",
  "status": "pending",
  ...
  "pending_request": {
    "amount": 400,
    "currency": "usd",
    "merchant_amount": 360,
    "merchant_currency": "gbp"
  }
}

The top-level amount in the request is set to 0 and approved is false. Once you respond to the request, the top-level amount reflects the total amount approved or declined, the approved field is updated, and pending_request is set to null.

Testing webhooks locally

To test webhooks locally, you can use Stripe CLI. Once you have it installed, you can forward events to your server:

stripe listen --forward-to localhost:4242/webhook
Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)

In another terminal, you can then manually trigger issuing_authorization.request events from the CLI for more streamlined testing.

stripe trigger issuing_authorization.request

Learn more about setting up webhooks.

Autopilot Public preview

Autopilot provides fallback options that allow you to continue making real-time authorisation decisions when your systems are down, don’t respond to an authorisation request, or provide an invalid response.

Autopilot makes an authorisation decision on your behalf based on a predefined set of rules. We create Authorization objects for transmission to reconcile Autopilot transactions. When Autopilot approves or declines an authorisation, the request_history.reason property of the issuing_authorization.created webhook is either webhook_error or webhook_timeout:

• webhook_error if you respond to the real-time authorisation webhook with an invalid Stripe API version in the request headers, or if we can’t process your response.
• webhook_timeout for all other failure modes.

To configure Autopilot, contact Stripe support.

Stripe Autopilot Public preview

For users with their own dedicated Bank Identification Numbers (BIN), Stripe Autopilot can help make authorisation decisions when the card network can’t reach Stripe.

When an authorisation is approved or declined through Stripe Autopilot while Stripe is down, the request_history.reason property of the issuing_authorization.created webhook is network_fallback.

To configure Stripe Autopilot, contact Stripe support.

Fraud challenges Public preview

Fraud challenges allow your cardholders to retry non-fraudulent transactions that would have otherwise been blocked.

To manage the rules that dictate when a fraud challenge is sent, adjust your response to the issuing_authorization.request webhook. You can trigger fraud challenges in scenarios where you detect spending that appears suspicious and want additional verification (for example, a cardholder using their card outside the country).

To do so, decline the issuing_authorization.request webhook and include the send_fraud_challenges field with the ["sms"] value.

Fraud challenges are currently limited to beta users. You must be an Issuing customer to join the beta. To request access to the beta, log in to your Stripe account and refresh the page. Contact Stripe for more information.

Enriched merchant data Private preview

The enriched_merchant_data hash on Issuing authorisation webhooks passes more comprehensive merchant data in events, such as:

• Merchant categories
• Location data
• Third parties

You can use these details to build more robust authorisation logic and downstream user interfaces.

Common use case examples include:

• Creating real time spend controls
• Automating transaction categorisation
• Developing better fraud detection and prevention