Recevoir des événements Stripe dans votre endpoint de webhook
Envoyer des événements à votre compte AWS
Nous lançons la prise en charge de la réception d’événements Stripe dans Amazon EventBridge en version bêta privée. Pour bénéficier d’un accès anticipé, inscrivez-vous sur eventbridge.stripe.dev.
Pourquoi utiliser des webhooks ?
Lors de la création d’intégrations Stripe, il est possible que vous souhaitiez que vos applications reçoivent les événements au fur et à mesure qu’ils se déclenchent dans vos comptes Stripe, afin que vos systèmes back-end exécutent des actions en conséquence.
Pour activer les événements webhook, vous devez enregistrer des endpoints de webhook. Une fois que vous les avez enregistrés, Stripe peut transmettre des données d’événement en temps réel au endpoint de webhook de votre application lorsque des événements se déclenchent dans votre compte Stripe. Stripe utilise le protocole HTTPS pour envoyer des événements webhook à votre application sous forme de charge utile JSON qui comprend un objet Event.
La réception d’événements webhook est particulièrement utile pour écouter des événements asynchrones tels que la confirmation d’un paiement par la banque d’un client, la contestation d’un paiement par un client, l’aboutissement d’un paiement récurrent ou l’encaissement des paiements d’un abonnement.
Aperçu de l’événement
Stripe génère des données d’événement que nous pouvons vous envoyer pour vous informer de l’activité de votre compte.
Lorsqu’un événement se déclenche, Stripe génère un nouvel objet Event. Une seule requête d’API peut entraîner la création de plusieurs événements. Par exemple, si vous créez un abonnement pour un client, vous recevez les événements customer.subscription.created
et payment_intent.succeeded
.
En enregistrant des endpoints de webhook sur votre compte Stripe, vous permettez à Stripe d’envoyer automatiquement des objets Event dans des requêtes POST au endpoint de webhook enregistré et hébergé par votre application. Une fois que votre endpoint de webhook a reçu l’événement, votre application peut exécuter des actions de back-end (par exemple, appeler les API de votre prestataire de services d’expédition pour planifier une expédition après avoir reçu un événement payment_intent.succeeded
).
Objet Event
L’objet Event que nous envoyons à votre endpoint de webhook fournit un aperçu de l’objet modifié. Il peut inclure une propriété previous_attributes
qui indique le changement, le cas échéant.
Consultez la liste complète des types d’événements que nous envoyons à votre webhook.
Exemple de charge utile d’un événement
L’événement suivant indique une mise à jour d’abonnement à la fin d’une période d’essai.
{ "id": "evt_1MqqbKLt4dXK03v5qaIbiNCC", "object": "event", "api_version": "2024-04-10", "created": 1680064028,
Structure de l’objet Event
Passez en revue la structure des objets Event pour mieux comprendre les événements et les informations sous-jacentes qu’ils fournissent.
Type d’événement
Vous recevez des événements pour tous les types d’événements que votre endpoint de webhook écoute dans votre configuration. Utilisez l’événement type
reçu pour déterminer le traitement que votre application doit effectuer. data.object
varie en fonction de chaque type
d’événement.
Mode production et mode test
Il est possible que vos endpoints reçoivent des requêtes de remise d’événements à la fois du mode test et du mode production. Cela peut se produire si vous utilisez un seul endpoint pour le mode test et le mode production, ou si vous êtes une plateforme Connect qui effectue des requêtes en mode test pour des comptes connectés Standard en production. Utilisez l’attribut livemode
pour vérifier si l’objet existe en mode test ou production et pour déterminer la façon dont l’événement doit être traité.
Version de l’API
Le paramètre api_version
indique la version d’API de l’événement et détermine la structure du data.object inclus. Votre endpoint reçoit les événements à l’aide de la version d’API configurée, qui peut différer de la version d’API par défaut de votre compte ou de la version d’API d’une requête liée à l’événement. Cet attribut est déterminé par le endpoint de destination, ce qui signifie qu’un même événement peut être remis à plusieurs endpoints avec différentes versions d’API. Si vous utilisez nos bibliothèques client Java, .NET ou Go, veillez à configurer le endpoint de sorte qu’il utilise la même version d’API que celle épinglée dans le client. Sinon, vous pourriez ne pas être en mesure de désérialiser les objets Event.
Lorsque vous récupérez un objet Event depuis l’API, vous ne pouvez pas contrôler la version de l’API associée à la structure de data.object
. Récupérez plutôt cet objet à partir du endpoint d’API approprié et utilisez l’en-tête Stripe-Version
pour spécifier une version d’API.
Événements de requête API
Lorsqu’un événement est généré à la suite d’une requête à l’API, cette requête s’affiche sous le nom request.id
. Si vous utilisez une idempotency_key
dans votre requête, elle figurera également dans le paramètre request.idempotency_key
. Consultez le hachage de la request
quand vous recherchez la cause d’un événement.
Objet Data et attributs précédents
Pour les événements *.updated
, la charge utile de l’événement inclut un attribut data.previous_attributes
qui vous permet d’inspecter les changements concernant l’objet Stripe. Dans l’exemple d’événement customer.subscription.updated
ci-dessus, previous_attributes
indique que l’abonnement avait précédemment pour valeur status: trialing
, entre autres changements. Le paramètre data.object
indique que l’état est défini sur active
, ce qui implique que l’abonnement n’est plus en période d’essai.
Remises en attente
Utilisez pending_webhooks
pour déterminer le nombre de endpoints configurés pour cet événement n’ayant pas renvoyé de réponse de réussite de la remise. Lors de la remise initiale, cette valeur est d’au moins 1, car votre endpoint n’a pas répondu. Si vous récupérez cet événement par la suite, pending_webhooks
diminue au fur et à mesure des réponses (hors échec) de chaque endpoint, jusqu’à atteindre 0. Cette information est importante dans le cas des événements invoice.created
, car les remises en échec peuvent retarder la finalisation de la facture.
Événements de compte connecté
Les événements de comptes connectés remis à un endpoint Connect incluent l’account
, qui vous permet de déterminer à quel account
connecté un objet correspond et pour vérifier que votre plateforme peut traiter les données des événements correctement.
Pourquoi des objets Event sont-ils générés ?
Ce tableau décrit différents scénarios qui déclenchent la génération d’objets Event.
Source | Déclencheur |
---|---|
Dashboard | Lorsque vous appelez une API en modifiant vos ressources Stripe depuis le Dashboard Stripe. |
API | Lorsqu’une action de l’utilisateur dans votre application ou votre site Web engendre un appel à l’API. |
API | Lorsque vous déclenchez manuellement un événement avec la CLI Stripe. |
API | Lorsque vous appelez une API directement avec la CLI Stripe. |
Démarrer
Pour commencer à recevoir des événements webhook dans votre application, créez et enregistrez un endpoint de webhook en suivant les étapes ci-dessous :
- Créez un gestionnaire de endpoints de webhook pour recevoir des requêtes POST de données d’événement.
- Testez votre gestionnaire de endpoints de webhook à l’aide de la CLI Stripe.
- Enregistrez votre endpoint auprès de Stripe à l’aide du Dashboard ou de l’API.
- Sécurisez votre endpoint de webhook.
Vous pouvez enregistrer et créer un endpoint pour gérer plusieurs types d’événements à la fois, ou configurer des endpoints pour des événements spécifiques.
Créer un gestionnaire
Configurez une fonction endpoint HTTP ou HTTPS pouvant accepter des requêtes de webhook avec une méthode POST. Si votre fonction endpoint est toujours en développement sur votre machine locale, elle peut utiliser le protocole HTTP. Une fois rendue publique, elle devra utiliser le protocole HTTPS.
Configurez votre fonction endpoint de façon à ce qu’elle :
- Gère les requêtes POST avec une charge utile JSON composée d’un objet Event.
- Renvoie rapidement un code d’état réussi (
2xx
) avant le déclenchement de toute logique complexe qui pourrait provoquer une expiration du délai imparti. Par exemple, vous devez renvoyer une réponse200
avant de mettre à jour la facture d’un client comme étant payée dans votre système comptable.
Note
Vous pouvez également créer une fonction endpoint de webhook dans votre langage de programmation à l’aide de notre créateur interactif de endpoint de webhook.
Exemple de endpoint
Cet extrait de code est une fonction webhook configurée pour vérifier que le type d’événement a été reçu, pour gérer l’événement et pour renvoyer une réponse 200.
Tester votre gestionnaire
Avant de mettre en production votre fonction endpoint de webhook, nous vous recommandons de tester l’intégration de votre application. Pour ce faire, configurez un écouteur local pour envoyer des événements à votre ordinateur local, puis envoyez des événements de test. Vous devez utiliser la CLI pour effectuer le test.
Transmettre des événements à un endpoint local
Pour transférer des événements vers votre endpoint local, exécutez la commande suivante avec la CLI afin de configurer un écouteur local. L’indicateur --forward-to
envoie tous les événements Stripe en mode test à votre endpoint de webhook local.
stripe listen --forward-to localhost:4242/stripe_webhooks
Note
Vous pouvez également exécuter la commande stripe listen sur le shell Stripe pour voir les événements via le terminal du shell Stripe, même si vous ne serez pas en mesure de transférer les événements du shell vers votre endpoint local.
Voici quelques exemples de configurations utiles pour vous aider à effectuer vos tests avec votre écouteur local :
- Pour désactiver la vérification des certificats HTTPS, utilisez le flag facultatif
--skip-verify
. - Pour ne transférer que des événements spécifiques, utilisez le flag facultatif
--events
et transmettez une liste d’événements séparés par des virgules.
stripe listen --events payment_intent.created,customer.created,payment_intent.succeeded,checkout.session.completed,payment_intent.payment_failed \ --forward-to localhost:4242/webhook
- Pour transférer des événements vers votre endpoint de webhook local à partir du endpoint de webhook public que vous avez déjà enregistré sur Stripe, utilisez le flag facultatif
--load-from-webhooks-api
. Il charge votre endpoint enregistré, analyse le chemin d’accès et ses événements enregistrés, puis ajoute le chemin d’accès à votre endpoint de webhook local à--forward-to path
.
stripe listen --load-from-webhooks-api --forward-to localhost:5000
- Pour vérifier les signatures de webhook, utilisez le paramètre
{{WEBHOOK_SIGNING_SECRET}}
dans la sortie initiale de la commande listen.
Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)
Déclencher des événements test
Pour envoyer des événements de test, déclenchez un type d’événement auquel votre destination d’événements est abonnée en créant manuellement un objet via le Dashboard Stripe. Sinon, vous pouvez également utiliser la commande suivante dans le shell Stripe ou la CLI Stripe.
Cet exemple déclenche un événement payment_intent.succeeded
:
stripe trigger payment_intent.succeeded Running fixture for: payment_intent Trigger succeeded! Check dashboard for event details.
Note
Comment déclencher des événements avec Stripe pour VS Code.
Enregistrer votre endpoint dans Stripe
Après avoir testé votre fonction endpoint de webhook, enregistrez l’URL accessible du endpoint de webhook à l’aide de la section Webhooks dans le Dashboard développeur ou de l’API afin que Stripe sache où envoyer les événements. Vous pouvez enregistrer jusqu’à 16 endpoints de webhook avec Stripe. Les endpoints de webhook enregistrés doivent être des URL HTTPS accessibles publiquement.
Format d’URL de webhook
Le endpoint de webhook doit être enregistré avec le format d’URL suivant :
https://<your-website>/<your-webhook-endpoint>
Par exemple, si votre domaine est https://mycompanysite.com
et que le chemin vers votre endpoint de webhook est @app.route('/stripe_webhooks', methods=['POST'])
, spécifiez https://mycompanysite.com/stripe_webhooks
comme URL d’endpoint.
Ajouter un endpoint de webhook
Note
Si vous avez activé Workbench sur votre compte, vous devez utiliser Workbench pour enregistrer votre endpoint de webhook.
Stripe prend en charge deux types de endpoints, les endpoints Account et les endpoints Connect. Créez un endpoint de type Account, sauf si vous avez créé une application Connect. Menez à bien les étapes suivantes pour enregistrer votre endpoint de webhook dans le Dashboard des développeurs. Vous pouvez enregistrer jusqu’à 16 endpoints de webhook sur chaque compte Stripe.
- Accédez à la page Webhooks.
- Cliquez sur Ajouter un endpoint.
- Ajoutez l’URL HTTPS de votre endpoint de webhook dans URL d’endpoint.
- Si vous utilisez un compte Stripe Connect, saisissez une description, puis cliquez sur Écouter des événements sur des comptes connectés.
- Dans Sélectionner des événements, spécifiez les types d’événements que vous recevez actuellement sur votre endpoint de webhook local.
- Cliquez sur Ajouter un endpoint.
Enregistrer un endpoint de webhook avec l’API Stripe
Vous pouvez également créer des endpoints de webhook par programmation.
Pour recevoir des événements de comptes connectés, utilisez le paramètre connect.
L’exemple suivant crée un endpoint qui vous informe de l’aboutissement ou de l’échec d’un paiement.
Sécuriser votre endpoint
Nous vous recommandons vivement de sécuriser votre intégration en vous assurant que votre gestionnaire vérifie que toutes les requêtes de webhook sont générées par Stripe. Vous pouvez choisir de vérifier les signatures de webhook à l’aide de nos bibliothèques officielles ou de les vérifier manuellement.
Déboguer des intégrations de webhooks
Plusieurs types de problèmes peuvent survenir lors de la remise d’événements à votre endpoint de webhook :
- Il est possible que Stripe ne parvienne pas à remettre un événement à votre endpoint de webhook.
- Votre endpoint de webhook comporte peut-être une erreur SSL.
- Votre connexion réseau est intermittente.
- Votre endpoint de webhook ne reçoit pas les événements attendus.
Afficher les remises d’événements
Note
Si vous avez activé Workbench sur votre compte, vous devez utiliser Workbench pour gérer vos remises d’événements.
Pour afficher les événements remis à un endpoint spécifique, sélectionnez le endpoint de webhook dans l’onglet Webhooks.
Pour afficher tous les événements qui ont été déclenchés sur votre compte, affichez l’onglet Événements.
Corriger les codes d’état HTTP
Lorsqu’un événement affiche un code d’état 200
, cela indique qu’il a bien été remis au endpoint de webhook. Vous pouvez aussi recevoir un code d’état autre que 200
. La liste ci-après détaille les codes d’état fréquents pour le protocole HTTPS, ainsi que les solutions préconisées.
État des webhooks en attente | Description | Rectifier |
---|---|---|
ERR (connexion impossible) | Nous ne parvenons pas à établir une connexion avec le serveur de destination. | Assurez-vous que votre domaine d’hébergement est accessible publiquement sur internet. |
(302 ) ERR (ou autre état 3xx ) | Le serveur de destination a tenté de rediriger la requête vers un autre emplacement. Nous considérons les réponses de redirection aux requêtes de webhook comme des échecs. | Définissez la destination de votre endpoint de webhook vers l’URL déterminée par la redirection. |
ERR (400 ) (ou autre état 4xx ) | Le serveur de destination ne parvient pas à traiter ou rejette la requête. Cela peut se produire si le serveur détecte une erreur (400 ), si l’URL de destination présente des restrictions d’accès (401 , 403 ) ou si l’URL de destination n’existe pas (404 ). |
|
(500 ) ERR (ou autre état 5xx ) | Le serveur de destination a rencontré une erreur lors du traitement de la requête. | Vérifiez les logs de votre application pour comprendre pourquoi vous recevez une erreur 500 . |
ERR (erreur TLS) | Nous n’avons pas pu établir de connexion sécurisée avec le serveur de destination. Ces erreurs sont généralement causées par un problème avec le certificat SSL/TLS ou un certificat intermédiaire dans la chaîne de certificats du serveur de destination. | Pour identifier d’éventuels problèmes pouvant engendrer cette erreur, effectuez un test du serveur SSL. |
ERR (expiré) | Le serveur de destination a mis trop de temps à répondre à la requête de webhook. | Veillez à reporter la logique complexe et à renvoyer immédiatement une réponse positive dans votre code de gestion des webhooks. |
Comportements de remise d’événements
Cette section vous aide à comprendre les différents comportements auxquels vous pouvez vous attendre concernant la manière dont Stripe envoie des événements à votre endpoint de webhook.
Comportement des nouvelles tentatives
En mode production, Stripe tente de remettre un événement donné à votre endpoint de webhook pendant 3 jours maximum, avec un allongement exponentiel du délai entre chaque tentative. Dans la section Événements du Dashboard, vous pouvez voir à quel moment aura lieu la prochaine tentative.
En mode test, Stripe procède à 3 tentatives sur une période de quelques heures. Passé ce délai, vous pouvez retenter manuellement la transmission d’événements individuels à votre endpoint de webhook à l’aide de la section Événements du Dashboard. Vous pouvez également envoyer une requête portant sur les événements manqués pour rapprocher les données sur n’importe quelle période.
Les nouvelles tentatives automatiques se poursuivent, même si vous réessayez manuellement de transmettre des événements webhook individuels vers un endpoint donné et que la tentative aboutit.
Si votre endpoint est désactivé ou supprimé au moment où Stripe effectue une nouvelle tentative, les futures tentatives pour cet événement sont bloquées. Cependant, si vous désactivez puis réactivez un endpoint de webhook avant que Stripe ne puisse effectuer une nouvelle tentative, il est possible que d’autres tentatives aient lieu.
Désactiver le comportement
En mode test et en mode production, Stripe tente de vous informer par e-mail de l’existence d’un endpoint incorrectement configuré lorsque le endpoint ne répond pas par un code d’état HTTP 2xx
pendant plusieurs jours d’affilée. Cet e-mail indique également que le endpoint sera désactivé automatiquement.
Gestion des versions de l’API
La version de l’API indiquée dans les paramètres de votre compte au moment où l’événement est déclenché détermine la version de l’API et, par conséquent, la structure de l’objet Event
envoyé dans un webhook. Par exemple, si votre compte utilise une ancienne version de l’API (telle que 2015-02-16) et que vous modifiez la version de l’API pour une requête spécifique à l’aide de la gestion des versions, l’objet Event
généré et envoyé à votre endpoint reste basé sur la version 2015-02-16.
Vous ne pouvez pas modifier les objets Event
une fois qu’ils ont été créés. Par exemple, si vous mettez à jour un paiement, l’événement de paiement initial reste inchangé. Cela signifie que les mises à jour apportées par la suite à la version de l’API de votre compte ne modifient pas de manière rétroactive les objets Event
. La récupération d’événements plus anciens en appelant /v1/events
à l’aide d’une version récente de l’API n’a pas non plus de conséquences sur la structure des événements reçus.
Vous pouvez configurer les endpoints de webhook de test sur votre version d’API par défaut ou sur la version la plus récente de l’API. L’objet Event
envoyé à l’URL du webhook est structuré conformément à la version spécifiée pour le endpoint. Vous pouvez également créer des endpoints par programmation avec une api_version spécifique.
Ordre des événements
Stripe ne garantit pas que les événements sont remis dans l’ordre dans lequel ils sont générés. Par exemple, la création d’un abonnement peut générer les événements suivants :
customer.subscription.created
invoice.created
invoice.paid
charge.created
(si un paiement a lieu)
Les événements ne seront pas nécessairement remis à votre endpoint dans cet ordre précis. Vous devez en tenir compte. Vous pouvez également utiliser l’API pour récupérer les éventuels objets manquants (par exemple, vous pouvez récupérer les objets Invoice, Charge et Subscription à l’aide des informations contenues dans l’événement invoice.paid
, si vous le recevez en premier).
Bonnes pratiques pour l’utilisation des webhooks
Passez en revue ces bonnes pratiques pour vous assurer que vos webhooks restent sécurisés et fonctionnent bien avec votre intégration.
Gérer les événements en double
Les endpoints de webhook peuvent recevoir plusieurs fois un même événement. Pour éviter de rencontrer ce phénomène, vous pouvez rendre votre traitement des événements idempotent. Pour ce faire, vous pouvez par exemple consigner les événements traités, puis ignorer ceux qui sont déjà consignés.
Écouter uniquement les types d’événements requis par votre intégration
Configurez vos endpoints de webhook de sorte à ne recevoir que les types d’événements requis par votre intégration. L’écoute d’événements supplémentaires (ou de tous les événements) alourdit inutilement la charge de votre serveur, c’est pourquoi nous vous déconseillons cette pratique.
Vous pouvez modifier les événements qu’un endpoint de webhook reçoit dans le Dashboard ou à l’aide de l’API.
Gérer les événements de manière asynchrone
Configurez votre gestionnaire de façon à traiter les événements entrants avec une file d’attente asynchrone. Si vous choisissez de traiter les événements de manière synchrone, vous risquez de rencontrer des problèmes d’évolutivité. Une hausse importante des remises de webhooks (en début de mois par exemple, lors du renouvellement des abonnements) peut submerger vos hôtes de endpoints.
Les files d’attente asynchrones vous permettent de traiter les événements simultanés à un rythme que votre système adapté à votre système.
Exempter la route des webhooks de la protection CSRF
Si vous utilisez Rails, Django ou une autre infrastructure Web, il est possible que votre site vérifie automatiquement que chaque requête POST contient un token CSRF. Il s’agit d’une fonctionnalité de sécurité importante qui vous protège, vous et vos utilisateurs, contre les tentatives de falsification de requêtes intersites. Cependant, cette mesure de sécurité peut également empêcher votre site de traiter des événements légitimes. Dans ce cas, vous devrez peut-être retirer la protection CSRF du chemin des webhooks.
Recevoir des événements sur un serveur HTTPS
Si vous utilisez une URL HTTPS pour votre endpoint de webhook, Stripe vérifie que la connexion à votre serveur est sécurisée avant d’envoyer les données de votre webhook. Pour que ce processus fonctionne, votre serveur doit être configuré de sorte à prendre en charge le protocole HTTPS avec un certificat valide. Les URL HTTPS sont obligatoires en mode production. Les webhooks Stripe ne prennent actuellement pas en charge TLS v1.3.
Invalider régulièrement les clés secrètes de signature des endpoints
La clé secrète utilisée pour vérifier que les événements proviennent de Stripe peut être modifiée dans la section Webhooks du Dashboard. Pour chaque endpoint, cliquez sur Invalider la clé secrète. Vous pouvez choisir de faire expirer la clé secrète actuelle immédiatement ou de retarder son expiration jusqu’à 24 heures maximum pour vous permettre de mettre à jour le code de vérification sur votre serveur. Pendant cette période, plusieurs clés secrètes sont actives pour le endpoint. Stripe génère une signature par clé secrète jusqu’à son expiration. Pour assurer leur sécurité, nous vous recommandons d’invalider les clés secrètes à intervalles réguliers ou lorsque vous soupçonnez que l’une d’entre elles est compromise.
Vérifier que les événements sont envoyés par Stripe
Stripe envoie des événements webhook à partir d’une liste définie d’adresses IP. Ne faites confiance qu’aux événements provenant de ces adresses IP.
Vérifiez également les signatures de webhook pour vous assurer que les événements reçus sont bien envoyés par Stripe. Stripe signe les événements webhook envoyés vers vos endpoints en incluant une signature dans l’en-tête Stripe-Signature
de chaque événement. Cela vous permet de vérifier que les événements ont été envoyés par Stripe et non par un tiers. Vous pouvez vérifier les signatures à l’aide de nos bibliothèques officielles ou manuellement en utilisant votre propre solution.
La section suivante décrit comment vérifier les signatures de webhook :
- Récupérez la clé secrète de votre endpoint.
- Vérifiez la signature.
Récupérer la clé secrète de votre endpoint
Utilisez la section Webhooks du Dashboard. Sélectionnez un endpoint dont vous souhaitez obtenir la clé secrète et recherchez-le en haut à droite de la page.
Stripe génère une clé secrète unique pour chaque endpoint. Si vous utilisez le même endpoint pour les clés API de production et de test, la clé secrète est différente pour chacune d’elles. De plus, si vous utilisez plusieurs endpoints, vous devez obtenir une clé secrète pour chacun d’entre eux pour lequel vous souhaitez vérifier les signatures, et Stripe commence à signer chaque webhook qu’il envoie au endpoint.
Prévenir les attaques par rejeu
Une attaque par rejeu se produit lorsqu’un attaquant intercepte une charge utile valide et sa signature, puis les retransmet. Pour limiter ce type d’attaques, Stripe inclut un horodatage dans l’en-tête Stripe-Signature
. Comme cet horodatage fait partie de la charge utile signée, il est également vérifié par la signature. Un attaquant ne peut donc pas modifier l’horodatage sans invalider la signature. Si la signature est valide mais que l’horodatage est trop ancien, votre application peut refuser la charge utile.
Nos bibliothèques ont une tolérance par défaut de 5 minutes entre l’horodatage et l’heure actuelle. Vous pouvez modifier cette tolérance en fournissant un paramètre supplémentaire lors de la vérification des signatures. Utilisez le protocole Network Time Protocol (NTP) pour vous assurer que l’heure de votre serveur est correcte et synchronisée avec celle des serveurs de Stripe.
Stripe génère l’horodatage et la signature chaque fois que nous envoyons un événement à votre endpoint. Si Stripe tente à nouveau de transmettre un événement (par exemple, si votre endpoint a précédemment répondu avec un code d’état autre que 2xx
), nous générons une nouvelle signature et un nouvel horodatage pour la nouvelle tentative de remise.
Renvoyer rapidement une réponse 2xx
Votre endpoint doit renvoyer rapidement un code d’état réussi (2xx
) avant le déclenchement de toute logique complexe qui pourrait provoquer une expiration du délai imparti. Par exemple, vous devez renvoyer une réponse 200
avant de mettre à jour la facture d’un client comme payée dans votre système comptable.