Webhook-Idempotenz: doppelte Zahlungswirkungen verhindern

Idempotenz bedeutet, dass ein logischer Zahlungsvorgang auch bei Wiederholung nur die beabsichtigte Wirkung erzeugt.

Dunkle Buchungsstapel mit indigofarbenen Transaktionswegen und einer Abgleichmarkierung.

Idempotenz bedeutet, dass ein logischer Zahlungsvorgang auch bei Wiederholung nur die beabsichtigte Wirkung erzeugt. Sie garantiert nicht, dass eine Nachricht nur einmal ankommt. Prüfen Sie Empfang, dauerhafte Speicherung, Zustandsänderung und nachgelagerte Arbeit als getrennte Fehlergrenzen.

Die passende Identität wählen

Eine Ereigniskennung erkennt wiederholte Zustellungen desselben Ereignisses. Eine Zahlungskennung verbindet verschiedene Ereignisse mit einer Zahlung. Ein Idempotenzschlüssel für eine ausgehende Anbieteranfrage schützt wiederum diese Operation nach den Regeln des Anbieters. Kundenname und Betrag ersetzen keine dieser Kennungen: Zwei legitime Käufe können denselben Betrag haben. Legen Sie zusätzlich fest, welche Zustandsübergänge zulässig sind.

Dauerhafte Verarbeitung absichern

Prüfen Sie die Signatur nach der Anbieterdokumentation und speichern oder übernehmen Sie das Ereignis dauerhaft, bevor Sie dessen erfolgreiche Annahme bestätigen. Verknüpfen Sie Zustandsänderung und Verarbeitungsnachweis atomar oder durch einen gleichwertigen dauerhaften Schutz. Eine Ausgangsqueue kann nachgelagerte Arbeit fortsetzen, wenn der Prozess nach dem Datenbankabschluss ausfällt. Beschränken Sie Zugriff und Aufbewahrung sensibler Ereignisdaten.

Wiederholung als normalen Betriebsfall testen

Stellen Sie ein Testereignis nacheinander und gleichzeitig zu. Stoppen Sie den Worker an jeder dauerhaften Grenze und prüfen Sie danach Buchungen, Freischaltungen und weitere Aufrufe. Späte Ereignisse dürfen den Zustand nicht allein aufgrund ihrer Ankunftszeit zurücksetzen. Überwachen Sie Alter und Status unerledigter Ereignisse. Ein kontrolliertes Wiederholen muss dieselben Schutzregeln verwenden wie die normale Verarbeitung und einen nachvollziehbaren Bedienvorgang hinterlassen.

Ein konkreter Abnahmetest

Ein Worker kann den Bestellstatus speichern und unmittelbar danach abstürzen, bevor er das Ereignis als erledigt markiert. Beim Neustart wird dieselbe Aufgabe erneut angeboten. Die Abnahme prüft deshalb zuerst den dauerhaften Schutz der Bestellung und anschließend den Zustand der Folgelieferung. Zählen Sie die erzeugten Geschäftsoperationen, nicht nur Logeinträge. Eine weitere erfolgreiche Verarbeitung darf keinen zweiten Zugang erzeugen. Bleibt die Lieferung offen, muss ein eigener wiederaufnehmbarer Auftrag existieren. So werden doppelte Wirkung und verlorenes Folgegeschäft als zwei unterschiedliche Fehler sichtbar.

Stripe — Referenzdokumentation

Häufige Fragen

Reicht eine Liste im Arbeitsspeicher?

Nein. Neustarts und mehrere Worker erfordern gemeinsam nutzbare dauerhafte Nachweise.

Schützt Anbieter-Idempotenz den Webhook?

Nur die jeweilige Anbieteranfrage. Eingehende Ereignisse und eigene Folgeaktionen brauchen eigene Schutzgrenzen.

Müssen alle Ereignisse gespeichert werden?

Definieren Sie Relevanz, Untersuchungsbedarf und Aufbewahrung bewusst; unbegrenzte Speicherung ist kein Standardziel.

Kann Wiederholung eine weitere Erstattung auslösen?

Ja, ohne Schutz der Geschäftswirkung. Prüfen Sie dies mit synthetischen Vorgängen.

Woran erkennen wir Stillstand?

An unerledigten Ereignissen, deren Alter, Wiederholungszahl und dem Ergebnis unabhängiger Abgleiche.

Vom Vorhaben zu einem umsetzbaren Umfang

Teilen Sie Nutzerablauf, Schnittstellen und Rahmenbedingungen. Gemeinsam klären wir den Umfang und erstellen eine Schätzung mit Annahmen und Ausschlüssen.

Leistungsumfang ansehen →