IOSOR

IOSOR Viden

Duplikerede webhooks må ikke udløse en ekstra debitering

Fejlsti: Genforsøg og genspilsforløb forbliver idempotente på forudbetalte midler og indbakke — ét event-ID, én debiteringsrække, én indbakkelinje.

At-least-once-levering vil genforsøge. Et duplikeret webhook, der poster en anden debitering eller en anden indbakkelinje, er en penge- og driftsincident, ikke en «ufarlig kvittering». Denne side er fejlstien: genforsøg og genspild forbliver idempotente på forudbetalte midler og indbakke — ikke essayet om API-afsendelses-idempotens og ikke playbooken for indgående SMS-genforsøg.

Relateret: Signatur- og replayvindue-port, Webhook-kontrakt før den første afsendelse, Debiteringsrækker vs leveringsstatus på samme ledger.

IOSOR er white-label forudbetalt.

Idempotens er en fejlsti, ikke et slogan

Successti: én signeret hændelse, én accept, én debitering. Fejlstien brænder tillid af — timeout, 5xx, provider-genspil, operatør-repush. Gem idempotensnøglen fra Webhook-kontrakt før den første afsendelse før sideeffekter: ledger, indbakke, CRM.

Hvad der tæller som en duplikering

Signal Behandl som duplikat når Sikker udfald
Hændelses-ID Samme ID allerede accepteret i vinduet KVITTERING; ingen anden debitering
Besked-ID Samme besked allerede ledger-linket Genbrug række; ingen ny betaling
Indbakkenøgle Samme MO/MT allerede arkiveret Ingen anden indbakkelinje
Uden for replayvindue Gammelt genforsøg efter port-afvisning Afvis;

Penge må ikke flytte sig to gange

En anden debitering for det samme hændelses-ID er en fejl, selvom produktet «stadig viser leveret». Finans filtrerer efter hændelses- eller besked-ID og ser én forudbetalt række for det UTC-vindue. Delvis sideeffekter efter KVITTERING — CRM først, ledger senere — fremstiller dobbelt sandhed.

Indbakken må heller ikke fordobles

Idempotens handler ikke kun om penge. En afspillet indgående eller leveringshændelse, der åbner en anden indbakke-tråd, træner supporten til at jage spøgelser og kan udløse automatiske svar-loops. Gem indbakkenøglen med det samme hændelses-ID, der bruges til debitering. Produkt og finans deler afvisning/duplikat.

Købers tjekliste for duplikat-sikre webhooks

Sørg for, at idempotensnøglen gemmes før eventuelle CRM- eller databasehandlinger. Bekræft, at der sendes et HTTP 200-svar for et anerkendt duplikat uden at udløse en ekstra ledger-debitering. Sørg for, at genspilsvinduet håndhæves ved signaturporten, før nogen forretningslogik kører. Test dit system regelmæssigt med duplikat-belastningsinjektioner.

Start med IOSOR

Tving ét underskrevet replay inden for vinduet på en korridor, der allerede har debiteret. Eksportér event-id ved siden af ledger-id og bevis én debitlinje plus én indbakkelinje. Viser en anden debit sig, stop den forbruger og refundér ekstralinjen — net den ikke mod senere trafik. Denne port er replay-penge, ikke et E.164-tjek og ikke forsendelsestekst.

IOSOR takeaway

Et replay er ikke en ny sending. Ét event-id skriver én debit.

Gør: hold underskrift og replay-vindue tændt, bevis så én debit efter en POST i vinduet. Lad være: at debitere hver POST, eller behandle et netværksretry som en anden faktura.

Var denne guide nyttig?

Relaterede vejledninger