Webhooks und ERP: doppelte Aufträge verhindern

Planen Sie Wiederholungen als regulären Fall Ihrer Shop-Anbindung ein. Ein Webhook ist eine vom sendenden System ausgelöste HTTP-Nachricht. Bleibt eine Bestätigung aus, kann die Nachricht erneut eintreffen. Daraus darf kein zusätzlicher ERP-Auftrag entstehen.

Stripe dokumentiert sowohl wiederholte Ereignisse als auch mögliche Mehrfachmeldungen für denselben Gegenstand. Welche Regeln gelten, müssen Sie beim tatsächlichen Absender prüfen. Das folgende Beispiel ist fiktiv und beschreibt keine Stripe-API.

Zwei Kennungen mit verschiedenen Aufgaben

Der Shop shop-1 hat den Auftrag W-240. Das Ereignis evt-17 meldet dessen Anlage. Im ERP erhält der Auftrag die Kennung E-901. Die Ereigniskennung erkennt eine erneute Zustellung; die Kombination aus Shop und Auftragskennung ordnet den Geschäftsvorgang zu. Ein späteres Ereignis evt-18 kann eine Änderung desselben Auftrags melden.

Annahme dauerhaft speichern

Prüfen Sie zuerst die Echtheit der Nachricht nach dem Verfahren des Absenders. Speichern Sie danach das Ereignis dauerhaft, bevor Sie seine Annahme bestätigen. Eine Eindeutigkeitsregel für Absender und Ereigniskennung verhindert, dass zwei gleichzeitig eintreffende Kopien getrennte Jobs erzeugen. Eine reine Suche vor dem Speichern reicht bei Gleichzeitigkeit nicht.

Die weitere Verarbeitung muss zuverlässig aus dieser Ablage entstehen. Ein Worker kann dafür gespeicherte offene Ereignisse übernehmen. So bleibt der Vorgang auch nach einem Absturz zwischen Empfang und Bearbeitung auffindbar.

Eine mögliche Antwort nach dieser Speicherung lautet:

{
  "eventId": "evt-17",
  "orderId": "W-240",
  "status": "queued"
}

Im Beispiel hat diese Antwort den HTTP-Status 202. Sie bestätigt die Aufnahme in die Verarbeitung. Eine ERP-Auftragsbestätigung liegt damit noch nicht vor. Kann die dauerhafte Aufnahme nicht gesichert werden, darf der Empfänger keine erfolgreiche Annahme vortäuschen.

Den ERP-Aufruf ebenfalls gegen Wiederholung schützen

Verwenden Sie für die Anlage einen stabilen Schlüssel wie shop-1:W-240:create, falls das Ziel solche Schlüssel unterstützt. Bei einem sicheren Wiederholungsversuch bleibt er gleich. Stripe zeigt dieses Prinzip für seine eigene API; die genaue Bedeutung und Aufbewahrung hängen vom Zielsystem ab.

Fehlt diese Unterstützung, braucht es eine andere verlässliche Zuordnung, etwa eine im Ziel eindeutig abgesicherte externe Auftragskennung und eine Abfrage des Ergebnisses. Ist nach einer Zeitüberschreitung unbekannt, ob der Auftrag entstanden ist, bleibt der Vorgang zur Klärung offen. Eine neue zufällige Kennung würde die Wiederholung als neue Anlage erscheinen lassen.

Ereignisspeicherung und ERP-Anlage in zwei Systemen bilden nicht automatisch eine gemeinsame Transaktion. Halten Sie deshalb Annahme, Verarbeitung, unklaren Ausgang und bestätigten Abschluss getrennt fest. Erst die bestätigte Zuordnung zu E-901 schließt die Anlage im Beispiel ab.

Mit Fehlern abnehmen

Senden Sie evt-17 nacheinander und gleichzeitig erneut. Unterbrechen Sie die Antwort nach einer erfolgreichen ERP-Anlage. Prüfen Sie anschließend evt-18 als echte Änderung. Erwartet werden ein einziger Anlagevorgang, die erhaltene Zuordnung und ein sichtbarer Klärungsstatus bei unbekanntem Ausgang. Legen Sie auch fest, wie lange die Kennungen für die möglichen Wiederholungen aufbewahrt werden.

Quellen

• Stripe: Receive events in your webhook endpoint

• Stripe: Idempotent requests