Un acheteur paie, ferme son navigateur et demande ensuite où est passé son achat. Un autre revient deux fois sur la page de succès. Aucune de ces actions ne devrait décider si une commande est payée. L’interface de paiement dialogue avec le client ; le registre des paiements relève séparément du serveur. Cette distinction compte particulièrement pour les domaines : l’étape suivante peut transférer un actif qu’il est impossible de remettre simplement dans un panier. PARTIR D’UNE COMMANDE Avant d’ouvrir le paiement, créez une commande interne avec un identifiant stable, un acheteur, un article, le montant attendu et la devise. Imaginez une enveloppe scellée qui décrit la transaction à accepter. À son arrivée, la notification doit correspondre à cette enveloppe. Une notification authentique concernant une autre commande reste la mauvaise notification. Un paiement en dollars ne doit pas valider une commande en euros parce que les chiffres sont identiques. Prenons un domaine à €500. Enregistrez 50000 centimes d’euro, plutôt qu’une chaîne formatée avec un symbole monétaire. Figez la remise et le montant final lors de la création de la commande. Un changement ultérieur du catalogue ne doit pas réécrire discrètement une session existante. Définissez précisément comment annuler l’ancienne commande et en créer une nouvelle. L’AUTHENTICITÉ AVANT LA LOGIQUE MÉTIER Stripe décrit la vérification de signature avec le corps original de la requête, l’en-tête de signature et le secret du endpoint. Ses bibliothèques officielles effectuent ce contrôle. Gardez le secret dans la configuration serveur, séparez test et production et ne l’envoyez jamais au frontend. Lors de la revue technique, suivez la requête depuis son entrée réseau jusqu’au traitement. Où son corps est-il lu ? Quel middleware le transforme ? Un proxy le modifie-t-il ? L’équipe doit pouvoir montrer la frontière exacte de vérification. N’imprimez pas de secrets dans les journaux pour chercher une panne. Enregistrez un identifiant de requête, l’environnement et une catégorie d’erreur nettoyée. Distinguez l’échec d’authenticité d’une indisponibilité temporaire de la base : les réactions et alertes nécessaires diffèrent. RÉCEPTION NE SIGNIFIE PAS EXÉCUTION Stripe signale que les notifications peuvent être répétées et livrées dans un ordre variable. Son guide d’exécution distingue les résultats de paiement différés. Ce sont des réalités de transport et de paiement, pas la preuve d’un mauvais clic du client. Prévoyez une boîte de réception persistante pour les notifications acceptées, puis une transition distincte de la commande. Un identifiant d’événement unique évite de traiter deux fois une livraison. L’opération métier exige aussi son propre garde-fou : une commande exécutée ne doit pas transférer à nouveau son domaine. Imaginez deux workers atteignant simultanément la même commande. Une contrainte ou transaction de base doit arbitrer cette transition, plutôt qu’une variable du navigateur ou un contrôle optimiste. Choisissez des états compréhensibles : paiement attendu, paiement confirmé, exécution en attente, terminé, examen nécessaire. Une tentative échouée ou expirée conserve son historique. Elle ne doit pas remplacer un paiement réussi plus récent simplement parce qu’un vieux message est arrivé après lui. LES TESTS AVANT LE LANCEMENT Établissez un tableau de résultats attendus. Une signature invalide ne modifie aucune commande. Un événement valide répété ne déclenche pas un deuxième transfert. Un paiement authentique avec montant, devise ou session inattendus nécessite un examen. Une confirmation reçue navigateur fermé doit apparaître dans le compte. Une interruption de base doit laisser assez d’informations pour reprendre sans danger. Testez séparément succès différé et échec différé. Essayez aussi le scénario moins spectaculaire : la notification est acceptée, mais le worker s’arrête au milieu de l’exécution. La reprise doit utiliser un état sauvegardé, pas la mémoire d’un collègue. Ne transférez pas un véritable actif simplement pour afficher une page verte. RENDRE L’INCERTITUDE LISIBLE Le client doit distinguer « paiement confirmé » de « transfert terminé ». Affichez le numéro de commande et la prochaine étape ; n’annoncez pas un succès tant que le serveur attend. Pour l’équipe, prévoyez une file d’examen avec motifs et une action de rapprochement avec l’enregistrement de paiement faisant autorité. Il s’agit de notre recommandation opérationnelle, pas d’une promesse qu’un webhook élimine tous les incidents. Un projet de domaine commence par un nom adapté, mais la fiabilité du paiement fait partie de l’expérience de marque. Consultez le catalogue DomainEvery: https://domainevery.com/fr/domains et budgétez vérification, reprise et exécution avec le design du site. SOURCES Stripe : webhooks: https://docs.stripe.com/webhooks Stripe : endpoints et signatures: https://docs.stripe.com/events/manage-webhook-endpoints Stripe : exécution avec hosted Checkout: https://docs.stripe.com/checkout/fulfillment.md?payment-ui=stripe-hosted