IOSOR Vedomosti

Poradie udalostí vs zaúčtovanie v ledgeris

Udalosti DLR a MO doručené v nesprávnom poradí nesmú narušiť pravidlá predplateného debetu — sekvencia príchodu nie je finančný zákon.

Poradie udalostí vs zaúčtovanie v ledgeris. Operátori doručujú spätné volania v nesprávnom poradí. Neskoré DLR, skoré MO alebo zmena stavu pred vyúčtovaním nesmú vyvolať druhý debet ani prepísať uzatvorený riadok. Táto stránka predstavuje zmluvu o poradí účtovania: pravidlá ledgera prežívajú preusporiadanie — nejde o úvod do korelačných ID ani o esej o fakturácii MO vs MT.

Poradie príchodu nie je zákonom ledgera

Príchod HTTP je transportná nehoda. Peniaze sa účtujú v režime podržanie → vyúčtovanie → aktualizácia výsledku — nie podľa toho, «ktoré spätné volanie dorazilo ako posledné». Mäkká hranica USD 1,000/mesiac považuje preusporiadanie za finančný incident, keď produkt vykazuje úspech, zatiaľ čo ledger vykoná dvojitý pohyb. USD 20 dokazuje, že vynútené neskoré DLR nikdy neotvorí paralelný debet. Opakovania s rovnakým ID: Duplicitný webhook nesmie vytvoriť druhý debet.

Ako vyzerá nesprávne poradie

Vzor príchodu Bezpečné účtovanie Nebezpečná reakcija
DLR pred vyúčtovaním Čaká sa; vyúčtovať raz pod podržaním Debet len z DLR
Zlyhanie a následné doručenie Aktualizovať výsledok na mieste Druhý poplatok za zmenu stavu
MO pred MT koreláciou Uložiť do schránky; spojiť pri MT vyúčtovaní Účtovať MO ako odchádzajúcu správu
Stav po vrátení peňazí Žiadne nové peniaze; pridať poznámku Znovu vyúčtovať uvoľnený zámer
Dva terminály, jeden zámer Jeden peňažný riadok Dva debetné riadky

Pravidlá účtovania, ktoré prežijú preusporiadanie

Pred vedľajšími účinkami vytvorte kľúče pre podržanie a idempotenciu (Webhook zmluva pred prvým odoslaním). Vyúčtujte raz na jeden spoplatniteľný zámer; neskoršie udalosti aktualizujú iba výsledok. Nikdy neotvárajte paralelný debet pre skoré alebo neskoré DLR alebo MO. Odmietnite alebo zaparkujte mimo podpísaného okna — žiadny vymyslený úspech. Export sa spája podľa zámeru — nie podľa časovej pečiatky príchodu.

Oneskorenie je normálne, dvojité peniaze nie

Keď sieť doručí neskoré DLR po dokončení vyúčtovania, ledger musí zostať nedotknutý. Systém uzamkne stav a ignoruje neskoré zmeny smeru. Riadiaci panel môže byť mätúci, ale zostatok na účte nesmie trpieť dopravným oneskorením. Počítačové zdroje slúžia na zachovanie presnosti, nie na zmierenie sieťových oneskorení. Znalosť týchto pravidiel zabraňuje vzniku finančných dier skôr, než sa stanú kritickými pre podnikanie.

Kontrolný zoznam kupujúceho pre poradie udalostí

Skontrolujte, či sú vaše webhooky idempotentné a používajú správne kľúče pre podržanie. Zabezpečte, aby fakturačný systém nikdy neotváral nový debet na základe neskorých stavov doručenia. Sledujte metriky oneskorenia, aby ste zachytili sieťové anomálie skôr, než vplyv na peniaze prerastie do problému. Porovnávajte prichádzajúce správy s pôvodným zámerom, nie s poradím, v akom pristáli na serveri.

Začnite s IOSOR

Zaúčtujte prepaid odpis na obchodný kľúč, nie na poradie príchodu webhooku. Neskorý DLR a rané accepted môžu pristáť v akomkoľvek poradí; register predsa píše jeden riadok. Replay v okne podpisu nesmie vytvoriť druhý odpis. Vynúťte jeden neskorý a jeden raný stav na zaplatené odoslanie a dokážte jedno zaúčtovanie.

Zhrnutie IOSOR

Poradie príchodu nie je zákon registra. Kľúč zaúčtovania vlastní peniaze; poradie frontu nie.

Robte: zaúčtujte raz na kľúč idempotencie; neskorý DLR je stav, nie nový odpis.

Nerobte: odpisovať znova, lebo DLR prišiel prvý, ani nechávať druhý riadok za opakovaný webhook.

Pomohol tento sprievodca?

Súvisiace návody