IOSOR

IOSOR Wissen

Ein doppelter Webhook darf keine zweite Belastung erzeugen

Fehlerpfad: Wiederholungen und Replays bleiben bei Prepaid-Geld und Posteingang idempotent – eine Event-ID, eine Belastungszeile, eine Posteingangszeile.

Die At-least-once-Zustellung wird es erneut versuchen. Ein doppelter Webhook, der eine zweite Belastung oder eine zweite Posteingangszeile sendet, ist ein Geld- und Betriebsvorfall, kein "harmloses ACK". Diese Seite ist der Fehlerpfad: Wiederholungen und Replays bleiben bei Prepaid-Geld und Posteingang idempotent – dies ist weder der API-Sende-Idempotenz-Aufsatz noch das Inbound-SMS-Wiederholungs-Playbook.

Ähnlich: Signatur- und Replay-Fenster-Gate, Webhook-Vertrag vor dem ersten Senden, Debit-Zeilen und Zustellstatus im selben Ledger.

IOSOR ist White-Label-Prepaid.

Idempotenz ist ein Fehlerpfad, kein Slogan

Happy Path: ein signiertes Event, eine Annahme, eine Belastung. Der Fehlerpfad zerstört Vertrauen – Timeout, 5xx, Anbieter-Replay, Betreiber-Neuschub. Speichern Sie den Idempotenzschlüssel aus dem Webhook-Vertrag vor dem ersten Senden vor den Nebeneffekten: Ledger, Posteingang, CRM.

Was als Duplikat gilt

Signal Als Duplikat behandeln wenn Sicheres Ergebnis
Event-ID Gleiche ID bereits im Fenster akzeptiert ACK; keine zweite Belastung
Nachrichten-ID Gleiche Nachricht bereits mit Ledger verknüpft Zeile wiederverwenden; keine neue Gebühr
Posteingangsschlüssel Gleiches MO/MT bereits abgelegt Keine zweite Posteingangszeile
Außerhalb Replay-Fenster Veralteter Retry nach Gate-Ablehnung Ablehnung; kein Geld- oder Status-Schreiben

Geld darf sich nicht zweimal bewegen

Eine zweite Belastung für dieselbe Event-ID ist ein Fehler, selbst wenn das Produkt "immer noch zugestellt anzeigt". Die Finanzabteilung filtert nach Event- oder Nachrichten-ID und sieht eine Prepaid-Zeile für dieses UTC-Fenster. Partielle Nebeneffekte nach ACK – CRM zuerst, Ledger später – erzeugen eine doppelte Wahrheit.

Auch der Posteingang darf sich nicht verdoppeln

Idempotenz betrifft nicht nur Geld. Ein wiederholtes Eingangs- oder Zustellungsereignis, das einen zweiten Posteingangs-Thread öffnet, trainiert den Support, Geister zu jagen, und kann Auto-Antwort-Schleifen auslösen. Speichern Sie den Posteingangsschlüssel mit derselben Event-ID, die für die Belastung verwendet wurde. Produkt und Finanzen teilen sich Ablehnung und Duplizierung.

Käufer-Checkliste für duplikatsichere Webhooks

Verlangen Sie von Ihrem Anbieter die Bestätigung der Idempotenzschlüssel-Speicherung vor dem Nebeneffekt. Stellen Sie sicher, dass Netzwerkfehler keine zweite Belastung im selben UTC-Fenster erzeugen. Verlangen Sie, dass Retries dasselbe gespeicherte ACK zurückgeben, ohne das Guthaben zu berühren. Testen Sie mit USD 20, bevor Sie zu höheren Volumina übergehen.

Beginnen Sie mit IOSOR

Erzwingen Sie eine signierte Replay innerhalb des Fensters auf einem Korridor, der schon abgebucht hat. Exportieren Sie die Event-id neben der Ledger-id und beweisen Sie eine Debit-Zeile plus eine Inbox-Zeile. Erscheint ein zweites Debit, stoppen Sie diesen Consumer und erstatten Sie die Extra-Zeile — nicht gegen späteren Traffic saldieren. Dieses Tor ist Replay-Geld, keine E.164-Prüfung und kein Versandtext.

IOSOR Fazit

Ein Replay ist kein neuer Send. Eine Event-id schreibt ein Debit.

Tun: Signatur und Replay-Fenster anlassen, dann ein Debit nach einem POST im Fenster beweisen. Nicht tun: jeden POST abbuchen oder einen Netz-Retry als zweite Rechnung behandeln.

War dieser Leitfaden hilfreich?

Verwandte Leitfäden