IOSOR

IOSOR Znalosti

Pořadí událostí vs účetní zápis v ledgeru

Události DLR a MO dorazilové v nesprávném pořadí nesmí porušit pravidla předplaceného odepsání — sekvence příjezdu není peněžní zákon.

Sítě doručují callbacky v nesprávném pořadí. Pozdní DLR, časná MO nebo změna stavu před vypořádáním nesmí vymyslet druhý debet ani přepsat vypořádaný řádek. Tato stránka je smlouvou o pořadí zápisů: pravidla ledgeru přežijí přerovnání — nejde o úvod do korelačního ID ani o esej o fakturaci MO vs MT.

Pořadí příjezdu není zákon ledgeru

HTTP příjezd je transportní nehoda. Peníze se připisují v režimu hold → vypořádat → aktualizace výsledku — nikoli podle toho, «jaký callback dorazil jako poslední». Měkká hranice USD 1,000/měsíc zachází s přerovnáním jako s finančním incidentem, když produkt hlásí úspěch, zatímco ledger se hýbe dvakrát. USD 20 dokazuje, že vynucené pozdní DLR nikdy neotevře paralelní debet. Opakování se stejným ID: Duplicitní webhook nesmí vytvořit druhý debet.

Jak vypadá špatné pořadí

Vzor příjezdu Bezpečný zápis Nebezpečná reakce
DLR před vypořádáním Čeká; vypořádat jednou pod hold Debet pouze z DLR
Selhal a pak doručen Aktualizovat výsledek na místě Druhý poplatek za změnu
MO před MT korelací Uložit do schránky; spojit při MT Účtovat MO jako odchozí
Stav po vrácení peněz Žádné nové peníze; opatřit poznámkou Znovu vypořádat uvolněný záměr
Dva terminály, jeden záměr Jeden peněžní řádek Dva řádky debetu

Pravidla zápisu, která přežijí přerovnání

Generujte klíče hold a idempotence před vedlejšími účinky (Smlouva o webhooku před prvním odesláním). Vypořádejte jednou za fakturovatelný záměr; pozdější události aktualizují pouze výsledek. Nikdy neotevírejte paralelní debet pro časné či pozdní DLR nebo MO. Odmítněte nebo zaparkujte mimo podepsané okno — žádný vymyšlený úspěch. Exportujte spojení podle záměru — nikoli podle času příjezdu.

Zpoždění je normální; dvojí peníze ne

Zpoždění sítě je v distribuovaných systémech normální. Pokud jsou peníze strženy dvakrát za jeden záměr, jde o selhání logiky zápisu. Pokud váš systém vytvoří duplicitní debet z pozdního DLR, řešíte chybnou finanční událost. Odsouhlasení musí vycházet z ID záměru, nikoli z pořadí příjezdu HTTP. Nenechte zpoždění sítě určovat váš finanční stav.

Kontrolní seznam kupujícího pro pořadí událostí vs zápis

Ověřte, zda váš systém rozlišuje mezi 'příjezdem události' a 'vypořádáním'. Potvrďte, že klíč idempotence je vytvořen před prvním odesláním. Zkontrolujte, zda pozdní DLR nespustí nový debet. Ujistěte se, že změna stavu (např. ze selhání na úspěch) aktualizuje původní řádek namísto vytvoření nového. Ujistěte se, že vaše odsouhlasení používá ID záměru jako primární zdroj.

Začněte s IOSOR

V konzoli: Event order vs ledger posting must reconcile by shared id.. Pojmenujte vlastníka a brány před rozšířením.

Související: duplicate webhook no second debit webhook consumer ops at volume

Shrnutí IOSOR

Ops disciplína pro směnu—ne brochure.

Dělejte: name owner + gate. Nedělejte: skip the gate.

Byl tento průvodce užitečný?

Související průvodci