# Stripe se souvient de votre requête quand la réponse disparaît Published: 2026-10-11 Un délai d'attente peut laisser un paiement incertain après que le serveur a terminé l'opération. Cet article d'explication « Sous le capot » utilise le contrat d'idempotence documenté de l'API Stripe v1 pour montrer des clés d'opération stables, la relecture de réponses enregistrées, les limites de paramètres et de concurrence, l'horizon de rétention et la réconciliation des résultats. Canonical: https://thedailydiff.dev/fr-CA/video/idempotency-retries/ ## Ce que cette vidéo couvre - L'idempotence concerne l'effet recherché de la répétition d'une opération. L'API Stripe v1 ajoute un contrat documenté de relecture de réponse enregistrée. - Une nouvelle tentative de la même action logique utilise la même clé et les mêmes paramètres. Conservez la clé d'opération à travers les appels SDK séparés ou les redémarrages d'application; une action véritablement nouvelle nécessite sa propre clé. - Une fois que l'exécution du point de terminaison commence, l'API Stripe v1 enregistre le statut et le corps de la première requête, y compris les erreurs 500, et renvoie cette réponse enregistrée lors des nouvelles tentatives. - Des paramètres modifiés avec la même clé produisent une non-concordance. Les échecs de validation et les conflits d'exécution concurrents n'enregistrent aucun résultat idempotent pour cette tentative et peuvent être réessayés. - Stripe conserve les clés de l'API v1 pendant au moins 24 heures et peut les purger ensuite. Limitez les nouvelles tentatives réseau non résolues aux premières 24 heures, puis arrêtez-vous et réconciliez avant de répéter l'opération. - Une erreur 500 mise en cache peut continuer à être rejouée après le rétablissement de la connectivité. L'opération originale peut avoir des effets secondaires; utilisez l'objet pertinent, la requête du Tableau de bord et les webhooks pour établir son résultat. - L'API v2 utilise une sémantique de relecture différente. Une clé n'établit pas une livraison universelle exactement une fois pour les e-mails, l'inventaire et toutes les opérations de base de données locales. ## Chapitres - 0:00 Un délai d'attente a-t-il annulé votre paiement? - 0:21 Qu'identifie une clé d'idempotence? - 0:43 Comment la même clé rend-elle une nouvelle tentative sûre? - 1:07 Que sauvegarde exactement Stripe? - 1:28 Que se passe-t-il lorsque la requête change? - 1:56 Combien de temps le résultat mémorisé est-il sûr à réessayer? - 2:19 Pourquoi une erreur mémorisée peut-elle revenir constamment? - 2:39 Expédiérais-je un bouton de nouvelle tentative avec ce contrat? ## Transcription traduite Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont contrôlés par YouTube. ### Un délai d'attente a-t-il annulé votre paiement? 0:00 Vous pensez qu'un délai d'attente signifie l'échec de votre paiement. Le serveur peut terminer tandis que la réponse disparaît, laissant votre paiement afficher absolument rien. Pourquoi une nouvelle tentative peut-elle facturer à nouveau? Comment Stripe se souvient-il d'une tentative? Quand devriez-vous arrêter de réessayer? Et gardez un vilain détail en tête. Une erreur mémorisée peut survivre au problème réseau. 0:17 Nous y reviendrons. Ceci est The Daily Diff, sous le capot. ### Qu'identifie une clé d'idempotence? 0:21 L'idempotence signifie que répéter une opération a le même effet souhaité que de la faire une seule fois. Une clé d'idempotence étiquette une action logique. L'API version un de Stripe reconnaît cette étiquette lors des nouvelles tentatives et rejoue une réponse enregistrée. Imaginez acheter un café. Stripe complète votre demande de paiement, et la réponse est perdue au retour à la maison. Le client voit un curseur d'attente. Sa banque peut avoir une interprétation plus excitante. Une requête de création non protégée peut répéter l'effet secondaire. ### Comment la même clé rend-elle une nouvelle tentative sûre? 0:45 Joignez une clé unique avant la première tentative et conservez-la pour les nouvelles tentatives. Si votre application redémarre, conservez cette clé avec l'opération dans vos enregistrements. Pour l'API version un de Stripe, une fois que l'exécution du point de terminaison commence, le statut et le corps de la première requête sont enregistrés. Envoyez à nouveau la même clé et les mêmes paramètres, et Stripe renvoie la réponse enregistrée. Le café reste en place pendant que son reçu voyage à nouveau. ### Que sauvegarde exactement Stripe? 1:07 Voici la formulation actuelle de Stripe. Les nouvelles tentatives avec la même clé renvoient la réponse enregistrée, y compris les erreurs cinq cents. La documentation fait plus de travail que votre aide à la nouvelle tentative nommée avec optimisme. Le client tape à nouveau. Votre application décide si cela reprend l'achat en attente ou en démarre un autre. Un café véritablement nouveau obtient une nouvelle clé. Une nouvelle clé pour chaque nouvelle tentative réseau annule la protection. 1:27 Des paramètres différents avec la même clé déclenchent une non-concordance. ### Que se passe-t-il lorsque la requête change? 1:30 Si les paramètres échouent à la validation, ou si une autre requête avec cette clé est toujours en cours d'exécution, Stripe n'enregistre aucun résultat idempotent pour cette tentative. Ces requêtes peuvent être réessayées. Une requête en course entraîne un conflit. Ce sont les règles de la version un. La version deux se comporte différemment. Un en-tête ne peut pas promettre une livraison exactement une fois à travers votre système. Les e-mails, l'inventaire et votre base de données ont chacun besoin d'une gestion des échecs. 1:52 La clé protège l'opération dans son champ d'application documenté. Stripe conserve les clés de la version un pendant au moins vingt-quatre heures et peut les purger ### Combien de temps le résultat mémorisé est-il sûr à réessayer? 1:59 après. Une clé purgée peut exécuter une nouvelle requête. Gardez les nouvelles tentatives non résolues au cours du premier jour. Au-delà, arrêtez-vous et réconciliez le résultat original. Utilisez un backoff exponentiel et une gigue pour donner au serveur une marge de manœuvre. Sinon, les nouvelles tentatives forment une file d'attente devant un café en feu. Les bibliothèques de Stripe gèrent les nouvelles tentatives, mais vérifiez les paramètres par défaut de votre bibliothèque. Cette erreur tenace est le piège. ### Pourquoi une erreur mémorisée peut-elle revenir constamment? 2:20 Une réponse cinq cents en cache continue d'être rejouée après le rétablissement de la connectivité. L'opération originale peut avoir produit des effets secondaires. Résolvez son résultat en utilisant des objets, le tableau de bord et les webhooks. Une nouvelle clé peut répéter l'action. Si vous préférez lire ceci plutôt que de m'entendre le dire, le diff arrive dans votre boîte de réception chaque matin, gratuitement sur the daily diff dot dev, lien ci-dessous. ### Expédiérais-je un bouton de nouvelle tentative avec ce contrat? 2:39 Verdict, sous le capot. Expédiez-le. J'expédierais des clés stables avec des nouvelles tentatives bornées et une réconciliation, afin que les clients obtiennent du café sans financer votre éducation aux systèmes distribués. Et c'est le diff pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable. ## Sources - [Idempotent requests](https://docs.stripe.com/api/idempotent_requests) — Stripe Docs - [Designing robust and predictable APIs with idempotency](https://stripe.com/blog/idempotency) — Stripe Engineering — Brandur Leach - [Advanced error handling](https://docs.stripe.com/error-low-level) — Stripe Docs - [HTTP Semantics — RFC 9110 §9.2.2 Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110.html) — IETF / RFC Editor