Insight · ·

Webhooks sind keine verlässliche Bestandsaufnahme

Ein Webhook meldet eine Änderung. Verlässliche Integrationen brauchen zusätzlich dauerhafte Annahme, sichere Wiederholung und einen Abgleich fehlender Meldungen.

Webhooks sind keine verlässliche Bestandsaufnahme

Die Zahlung ist da, die Bestellung wartet

Eine Zahlung kann erfolgreich sein, während der Shop die Bestellung noch als unbezahlt führt. Zahlungsanbieter und Shop verwalten unterschiedliche Datensätze. Die verbindende Nachricht kann verspätet eintreffen, mehrfach zugestellt oder falsch verarbeitet werden. Wer den zuletzt empfangenen Webhook als vollständige Wahrheit behandelt, erschwert die Korrektur.

Ein Webhook ist ein Anlass, einen Geschäftsvorgang zu prüfen. Er ersetzt keine Entscheidung darüber, welches System Zahlung, Versand oder Kundenkommunikation verantwortet. Der Zahlungsanbieter kann den Zahlungsstatus feststellen. Ob das Lager ein Paket verschickt hat, beantwortet er nicht. Diese Zuständigkeiten bleiben getrennt.

Erst dauerhaft annehmen, dann bearbeiten

Der empfangende Endpoint sollte den Absender prüfen, den Eingang dauerhaft speichern und die Bearbeitung weitergeben. Eine erfolgreiche Empfangsbestätigung bedeutet dann, dass die Nachricht gesichert ist. Sie behauptet nicht, dass sämtliche Folgeaktionen abgeschlossen sind. Scheitert die Speicherung, darf Erfolg die noch offene Arbeit nicht verdecken.

Stripe dokumentiert Signaturprüfung, mögliche Mehrfachzustellungen und nicht garantierte Ereignisreihenfolge. Das sind verbindliche Arbeitsbedingungen einer Integration. Die Webhook-Dokumentation von Stripe beschreibt sie für diesen Anbieter.

Für das Eingangsregister empfehlen wir Ereignisreferenz, Geschäftsreferenz, Empfangszeit und Bearbeitungszustand. Diagnosedaten erhalten angemessene Zugriffs- und Aufbewahrungsregeln. Eine Protokollzeile, die mit dem Anwendungsprozess verschwindet, ersetzt kein dauerhaftes Register.

Wiederholte Nachrichten dürfen keine wiederholten Folgen erzeugen

Ein beispielhafter Bestellablauf verschickt nach dem Zahlungseingang eine Bestätigung. Die Erkennung doppelter Eingangsmeldungen hilft, reicht aber nicht: Der Prozessor könnte nach dem Versand und vor dem Speichern des Abschlusses ausfallen. Beim erneuten Durchlauf würde die Nachricht nochmals verschickt.

Die fachliche Wirkung muss deshalb getrennt vom Zustellversuch verfolgt werden. Bestätigung, Reservierung und Erstattung brauchen jeweils eine stabile Vorgangsreferenz. Unterstützt der Empfänger Idempotenz, bleibt diese Referenz bei Wiederholungen derselben beabsichtigten Aktion gleich. Andernfalls ist festzulegen, wie ein ungewisses Ergebnis vor einer Wiederholung untersucht wird.

Auch die Reihenfolge braucht Fachregeln. Eine alte Zahlungsmitteilung darf einen späteren Erstattungszustand nicht überschreiben, nur weil sie zuletzt ankommt. Zulässige Übergänge bestimmen die Verarbeitung. Reicht das Ereignis zur Beurteilung nicht aus, wird der massgebliche Datensatz abgefragt. Die Ankunftsreihenfolge ist ein Transportdetail.

Wiederherstellung ohne weitere Benachrichtigung

Ein Abgleich vergleicht relevante Datensätze zwischen den Systemen und liefert nachvollziehbare Unterschiede. Er kann etwa Zahlungen ohne passende Bestellaktualisierung finden oder Bestellungen, deren Zahlungsentscheidung andernorts bereits feststeht. Umfang, Seitennavigation und Wiederaufnahmepunkt des Abgleichs müssen definiert sein.

Nicht jede Abweichung sollte automatisch korrigiert werden. Während der Abwicklung kann ein Unterschied berechtigt sein. Eine mehrdeutige Referenz kann eine menschliche Entscheidung erfordern. Sichere Reparaturen und Fälle mit zusätzlichem Nachweisbedarf gehören getrennt. Jede Änderung braucht eine dokumentierte Begründung.

Der unbequeme Aufwand ist eine Betriebsansicht, die tatsächlich betreut wird. Zustellungsstatistiken können gesund aussehen, während Geschäftsdatensätze falsch bleiben. Ein Abgleichsergebnis ohne verantwortliche Person ist lediglich eine weitere unbearbeitete Nachricht.

Diese Woche eine Wiederherstellung proben

Eine harmlose Testbestellung vom Anbieter über den lokalen Zustand bis zur Kundenkommunikation verfolgen. Das Ereignis erneut einspielen, zusammengehörige Meldungen vertauschen und die Bearbeitung nach einer externen Wirkung unterbrechen. Das Ergebnis muss weiterhin erklärbar bleiben.

Danach in der Testumgebung die Benachrichtigung ganz auslassen. Der Abgleich sollte den Unterschied ohne neues Ereignis finden. Festhalten, wer die Korrektur freigibt, welche Nachweise vorliegen und wie der Abschluss dokumentiert wird. Damit wird die Integration geprüft, nicht bloss ihr Empfangsendpunkt.