Comment éviter les commandes en double lorsqu’un webhook de paiement arrive deux fois ?

Réponse courte

La création de commande ne doit pas être relancée quand le même webhook de paiement est livré à nouveau. Utilisez l’identifiant d’événement du fournisseur avec une clé métier unique et conservez l’état de traitement de façon atomique en base. Répondre avec succès au webhook et terminer réellement une commande sont deux étapes distinctes.

Identifiant d’événement et identifiant de commande : deux protections

L’identifiant du fournisseur aide à reconnaître la nouvelle livraison d’une même notification. Plusieurs types d’événements peuvent toutefois concerner un même paiement. Vérifier seulement si cet événement est déjà arrivé peut donc être insuffisant. L’association entre commande, paiement et clé métier doit aussi être protégée par une règle d’unicité. La livraison répétée est un scénario d’échec légitime et attendu à prévoir.

Consulter la base de données puis insérer un enregistrement expose deux requêtes simultanées à une condition de concurrence. Protégez le traitement avec une contrainte d’unicité et un périmètre transactionnel adapté. Distinguez les états « reçu », « en traitement », « terminé » et « en erreur ». La présence d’un enregistrement inachevé ne signifie pas que l’opération a réussi.

Vérification de signature et file sécurisée

Appliquez la méthode de vérification de signature du fournisseur avant les règles métier. Consultez la documentation officielle pour le format du corps requis. Ne placez pas une requête invalide dans la file comme un paiement normal. Une fois l’événement valide enregistré durablement, les tâches longues peuvent être exécutées dans une file contrôlée. Les journaux ne doivent pas contenir de détails de paiement sensibles.

Le comportement de livraison décrit par Stripe concerne les intégrations Stripe ; ne supposez pas que les délais de nouvelle tentative et les signatures des autres fournisseurs sont identiques. La proposition doit préciser fournisseur, types d’événements, règles de nouvelle tentative et responsable des tâches échouées. Les requêtes API idempotentes sont également une couche distincte de la protection du traitement des webhooks.

Le rapprochement est aussi important que la prévention des commandes en double

Testez le même événement reçu deux fois, simultanément et après une interruption de traitement. Si le paiement est terminé sans création de commande, ouvrez une tâche de rapprochement. L’écran opérationnel doit relier paiement et commande et montrer ce que modifiera un retraitement. Le test doit détecter les commandes manquantes, pas seulement éviter les doublons.

Liste de contrôle de mise en œuvre

La signature du webhook est-elle vérifiée ?
L’identifiant d’événement a-t-il une contrainte d’unicité ?
La clé de commande liée au paiement est-elle protégée séparément ?
Un traitement interrompu peut-il être repris ?
Le rapprochement paiement–commande est-il visible ?

Questions fréquentes

Une réponse HTTP réussie indique-t-elle une commande terminée ?

Non. L’accusé de réception de l’événement et l’achèvement du processus métier font l’objet de deux enregistrements distincts.

Tous les fournisseurs ont-ils les mêmes règles de nouvelle tentative ?

Non. Le contrat et la documentation officiels du fournisseur choisi font référence.

Périmètre et limites

Cette approche ne remplace pas les tests d’intégration propres au fournisseur. Vérifiez les paiements et remboursements dans son environnement de test avant la mise en production.

Sources et actualité

Vérification des sources : 7 octobre 2026. Les versions des documents liés et les conditions des fournisseurs peuvent changer. Vérifiez la version actuelle de la source concernée avant toute mise en œuvre.

Service associé

Découvrir les logiciels sur mesure et les applications mobiles