Autorisations en temps réel Issuing

Votre webhook synchrone vous permet d’approuver ou de refuser les demandes d’autorisation en temps réel.

Vous pouvez configurer votre endpoint de webhook dans vos paramètres. Lorsqu’une carte est utilisée pour effectuer un achat, Stripe crée une requête issuing_authorization.request et l’envoie à l’endpoint configuré pour obtenir votre approbation.

Démarrez avec notre guide interactif sur les autorisations en temps réel.

Réponse aux demandes d’autorisation

Vous pouvez répondre aux demandes d’autorisation en répondant directement à l’événement de webhook.

Répondre directement

Répondez directement à l’événement de webhook issuing_authorization.request pour approuver ou refuser une autorisation après sa réception.

Réponse du webhook

Notre webhook accepte les réponses JSON avec les paramètres suivants :

Code d’état : renvoyez 200 pour indiquer une réussite.

En-tête :

Corps :

# 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

Effectuer un appel à l’API Deprecated

Cette documentation est conservée pour les utilisateurs existants. Si vous êtes un nouvel utilisateur, répondez directement au webhook. Si vous êtes un utilisateur existant, prévoyez de migrer vers la réponse directe du webhook. Vous pouvez suivre notre guide de migration directe des webhooks.

Effectuez un appel à l’API pour approuver ou refuser la requête et inclure l’ID Authorization. Si vous utilisez cette méthode, votre webhook doit approuver ou refuser chaque autorisation avant de répondre à la requête de webhook entrante.

# 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

Nous vous recommandons de n’utiliser que l’une de ces deux méthodes pour répondre aux demandes d’autorisation. Pour les utilisateurs qui migrent d’une méthode vers une autre, les deux méthodes sont prises en charge lors d’une migration. Si les deux méthodes sont utilisées pour la même autorisation, l’appel à l’API prime sur la réponse directe. Dans le cadre des migrations, nous vous recommandons de n’utiliser qu’une méthode à la fois pour une requête donnée.

Si Stripe ne reçoit pas votre réponse ou demande d’autorisation ou de refus dans les 2 secondes, l’Authorization est automatiquement approuvée ou refusée en fonction de vos paramètres d’expiration.

Demandes d’autorisation

Lorsqu’une demande d’autorisation est envoyée à votre webhook, l’amount demandé est stocké dans le champ 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"
  }
}

Le champ amount du haut dans la demande est défini sur 0 et approved prend la valeur false. Lorsque vous répondez à la demande, le montant total approuvé ou refusé est renseigné dans ce champ amount, le champ approved est mis à jour et la valeur du champ pending_request passe à 0.

Test des webhooks en local

Pour tester des webhooks localement, vous pouvez utiliser l’interface de ligne de commande Stripe. Après l’avoir installée, vous pouvez transférer les événements à votre serveur :

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

Sur un autre terminal, vous pouvez ensuite déclencher manuellement des événements issuing_authorization.request depuis la CLI pour simplifier les tests.

stripe trigger issuing_authorization.request

En savoir plus sur la configuration des webhooks.

Autopilot Public preview

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

Autopilot makes an authorization 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 authorization, 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 authorization 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 Version bêta publique

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

When an authorization 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.

Étapes de détection de la fraude Public preview

Les étapes de détection de la fraude permettent aux titulaires de carte de relancer des transactions non frauduleuses qui, sans cette fonctionnalité, auraient été bloquées.

Pour gérer les règles qui dictent quand une étape de détection de la fraude est envoyée, réajustez votre réponse au webhook issuing_authorization.request. Vous pouvez déclencher des étapes de détection de la fraude lorsque vous détectez des dépenses qui vous semblent suspectes et souhaitez effectuer une vérification supplémentaire (par exemple, lorsqu’un titulaire de carte utilise sa carte à l’étranger).

Pour ce faire, refusez le webhook issuing_authorization.request et incluez le champ send_fraud_challenges en indiquant la valeur ["sms"].

Les étapes de détection de la fraude sont actuellement limitées aux utilisateurs de la version bêta. Vous devez être un client Issuing pour accéder à la version bêta. Pour demander l’accès à la version bêta, connectez-vous à votre compte Stripe et actualisez la page. Contactez Stripe pour en savoir plus.

Données enrichies sur les marchands Private preview

Le hachage enriched_merchant_data des webhooks d’autorisation Issuing transmet des données marchandes plus complètes lors d’événements tels que :

• Catégories de marchands
• Données de localisation
• Tiers

Vous pouvez utiliser ces détails pour créer une logique d’autorisation et des interfaces utilisateur plus robustes en aval.

Voici quelques exemples de cas d’utilisation courants :

• Mise en place d’un contrôle des dépenses en temps réel
• Automatisation de la catégorisation des transactions
• Améliorer la détection et la prévention de la fraude