IOSOR

IOSOR Ghiduri

Un webhook duplicat nu trebuie să creeze un al doilea debit

Cale de eșec: reîncercările și reluările rămân idempotente pentru bani prepaid și inbox — un ID de eveniment, un rând de debit, o linie de inbox.

Livrarea la cel puțin o dată va reîncerca. Un webhook duplicat care trimite un al doilea debit sau a doua linie în inbox reprezintă un incident financiar și operațional, nu o simplă confirmare inofensivă. Această pagină reprezintă calea de eșec: reîncercările și reluările rămân idempotente pe soldul prepaid și inbox — nu eseul despre idempotența trimiterii prin API și nici ghidul de reîncercare SMS inbound.

Legate: Poartă pentru semnătură și fereastră de replay, Contractul webhook înainte de prima trimitere, Rânduri debit vs status livrare pe același ledger.

IOSOR este o soluție prepaid white-label.

Idempotența este o cale de eșec, nu un slogan

Calea fericită: un eveniment semnat, o acceptare, un debit. Calea de eșec distruge încrederea — timeout, 5xx, reluare de la furnizor, re-push din partea operatorului. Salvați cheia de idempotență din Contractul webhook înainte de prima trimitere înainte de efectele secundare: ledger, inbox, CRM.

Ce se consideră un duplicat

Semnal Tratează ca duplicat când Rezultat sigur
ID Eveniment Același ID acceptat deja în fereastră ACK; fără al doilea debit
ID Mesaj Același mesaj legat deja de ledger Reutilizare rând; fără taxă nouă
Cheie Inbox Același MO/MT deja înregistrat Fără a doua linie în inbox
În afara ferestrei Reîncercare veche după respingere Respingere; fără scriere bani/status
Tip necunoscut Nu este pe lista de evenimente a

Banii nu trebuie să se miște de două ori

Un al doilea debit pentru același ID de eveniment este un bug, chiar dacă produsul «arată în continuare livrat». Finanțele filtrează după ID-ul de eveniment sau de mesaj și văd un singur rând prepaid pentru acea fereastră UTC. Efectele secundare parțiale după confirmare — CRM mai întâi, ledger mai târziu — produc un adevăr dublu. Dacă procesarea eșuează după persistență, reîncercați worker-ul pe aceeași cheie; nu reacceptați corpul HTTP ca o nouă taxă.

Nici inboxul nu trebuie să se dubleze

Idempotența nu se referă doar la bani. Un eveniment inbound sau de livrare reluat care deschide un al doilea fir de inbox antrenează suportul să vâneze fantome și poate declanșa bucle de auto-răspuns. Stocați cheia de inbox cu același ID de eveniment folosit pentru debit. Produsul și finanțele împart regulile de respingere și duplicare pentru a menține inbox-ul curat.

Lista de verificare pentru cumpărători privind webhook-urile sigure la duplicate

Mai întâi testați reluarea înainte de lansarea în producție. Trimiteți același webhook de două ori imediat: primul produce un debit, al doilea returnează ACK fără o a doua taxă sau rând. Verificați că ledger-ul backend arată un singur rând de tranzacție pentru acel marcaj temporal. Verificați că jurnalul de erori separă respingerile reale de reluările prin reîncercare.

Începeți cu IOSOR

Forțați un replay semnat în fereastră pe un coridor care a debitat deja. Exportați event id lângă id-ul din registru și dovediți un singur rând de debit plus un singur rând inbox. Dacă apare un al doilea debit, opriți acel consumator și rambursați rândul în plus — nu-l compensați cu trafic ulterior. Această poartă e bani de replay, nu o verificare E.164 și nu un text de livrare.

Materiale: Contractul webhook înainte de prima trimitere Poartă pentru semnătură și fereastră de replay Rânduri debit vs status livrare pe același ledger.

Rezumat IOSOR

Un replay nu e un trimis nou. Un event id scrie un debit.

A fost util acest ghid?

Ghiduri conexe