IOSOR

IOSOR Ghiduri

Ordinea evenimentelor față de înregistrarea în ledger

Evenimentele DLR și MO sosite în dezordine nu trebuie să strice regulile de debit prepaid — ordinea sosirii nu este legea banilor.

Rețelele livrează callback-urile în dezordine. Un DLR întârziat, un MO prematur sau o inversare de status înainte de decontare nu trebuie să inventeze un al doilea debit sau să rescrie un rând decontat. Această pagină reprezintă contractul ordinii de înregistrare: regulile ledgerului supraviețuiesc reordonării — nu este un ghid pentru ID-uri de corelare și nici un eseu de facturare MO vs MT.

Ordinea sosirii nu este legea ledgerului

Traficul HTTP este un accident de transport. Banii se înregistrează după reținere → decontare → actualizarea rezultatului — și nu după «ce callback a sosit ultimul». Limita soft de USD 1,000/lună tratează reordonarea drept un incident financiar atunci când produsul raportează succes în timp ce ledgerul face mișcări duble. USD 20 dovedește că un DLR târziu forțat nu deschide niciodată un debit paralel.

Cum arată dezordinea în livrare

Model de sosire Înregistrare sigură Reacție nesigură
DLR înainte de decontare În așteptare; decontare unică sub reținere Debit doar pe baza DLR
Eșuat apoi livrat Actualizare rezultat pe loc A doua taxare pentru schimbare
MO înainte de corelare MT Fișier în inbox; asociere la decontare MT Taxare MO ca outbound
Status după rambursare Fără bani noi; adnotare Redecontare intenție eliberată
Două terminale, o intenție Un rând de bani Două rânduri de debit .

Reguli de înregistrare care supraviețuiesc reordonării

Creați cheile de reținere și idempotență înainte de efectele secundare (Contractul webhook înainte de prima trimitere). Decitați o singură dată per intenție taxabilă; evenimentele ulterioare actualizează doar rezultatul. Nu deschideți niciodată un debit paralel pentru un DLR sau MO sosit devreme/târziu. Respingeți sau parcați în afara ferestrei semnate — niciun succes inventat. Exportați asocierile după intenție — nu după timpul sosirii.

Întârzierea este normală, banii dubli nu sunt

Întârzierea rețelei este normală în sistemele distribuite. Faptul că banii sunt debitați de două ori pentru o singură intenție este un eșec al logicii de înregistrare. Dacă sistemul tău creează un debit duplicat dintr-un DLR întârziat, gestionezi un eveniment financiar defectuos. Reconcilierea trebuie să se bazeze pe ID-ul intenției, nu pe ordinea sosirii HTTP. Nu lăsa întârzierea rețelei să îți determine starea financiară.

Checklist pentru cumpărători privind ordinea evenimentelor

Verifică dacă sistemul tău distinge între 'sosirea evenimentului' și 'decontare'. Confirmă că cheia de idempotență este creată înainte de prima trimitere. Verifică dacă un DLR întârziat nu declanșează un nou debit. Asigură-te că schimbarea de status (ex. de la eșuat la succes) actualizează rândul original în loc să creeze unul nou. Asigură-te că reconcilierea ta folosește ID-ul intenției ca sursă primară.

Începeți cu IOSOR

În consolă: Event order vs ledger posting must reconcile by shared id.. Notați proprietarul și porțile înainte de scalare.

Legat: duplicate webhook no second debit webhook consumer ops at volume.

Rezumat IOSOR

Este o disciplină operațională de tură, nu un material promoțional. Echipa de gardă trebuie să numească explicit responsabilul de proces și să treacă prin verificarea obligatorie din consolă înainte de orice înregistrare în ledger. Este strict interzisă omiterea etapei de control pentru a grăbi procesarea operațiunilor de decontare în timp UTC.

A fost util acest ghid?

Ghiduri conexe