IOSOR

IOSOR Wiedza

Kolejność zdarzeń a księgowanie na ledgerze

Zdarzenia DLR i MO dostarczone w złej kolejności nie mogą psuć reguł debetu prepaid — sekwencja nadejścia to nie prawo pieniądza.

Sieci doręczają callbacki w losowej kolejności. Spóźniony DLR, wczesny MO lub zmiana statusu przed rozliczeniem nie mogą wygenerować drugiego obciążenia ani przepisać rozliczonego wiersza. Ta strona to kontrakt kolejności księgowania: reguły ledgera przeżywają zmianę kolejności — to nie poradnik ID korelacji ani esej o rozliczeniach MO kontra MT.

Kolejność nadejścia to nie prawo ledgera

Nadejście HTTP to wypadek transportowy. Pieniądze są księgowane w trybie hold → rozliczenie → aktualizacja wyniku — a nie «który callback dotarł jako ostatni». Miękkie USD 1.000/miesiąc traktuje zmianę kolejności jako incydent finansowy, gdy produkt pokazuje sukces, podczas gdy ledger wykonuje podwójny ruch. USD 20 udowadnia, że wymuszony późny DLR nigdy nie otwiera równoległego obciążenia.

Jak wygląda zaburzona kolejność

Wzorzec nadejścia Bezpieczne księgowanie Niebezpieczna reakcja
DLR przed rozliczeniem Oczekujące; rozlicz raz pod hold Obciążenie tylko z DLR
Błąd, a potem doręczenie Aktualizuj wynik na miejscu Druga opłata za zmianę
MO przed korelacją MT Do skrzynki; połącz przy MT rozliczeniu Obciążenie MO jako wychodzące
Status po zwrocie Brak nowych pieniędzy; adnotacja Ponowne rozliczenie intencji
Dwa callbacki z tym samym kluczem Rozlicz pierwszy; ignoruj drugi Drugie obciążenie

Reguły księgowania odporne na zmianę kolejności

Twórz klucze hold i idempotencji przed skutkami ubocznymi (Kontrakt webhooka przed pierwszą wysyłką). Rozliczaj raz na intencję podlegającą opłacie; późniejsze zdarzenia aktualizują tylko wynik. Nigdy nie otwieraj równoległego debetu dla wczesnego lub późnego DLR albo MO. Odrzuć lub zparsuj poza podpisanym oknem — żadnego zmyślonego sukcesu. Podpis i okno powtórzeń zapobiega podwójnym rozliczeniom.

Opóźnienie jest normalne; podwójne pieniądze nie

Opóźnienie jest normą, podwójne pobranie opłaty już nie. System musi radzić sobie z asynchronicznością sieci bez uszczerbku dla salda klienta. Operacje konsumenta webhooka przy dużej ilości pomagają zarządzać tymi wyzwaniami.

Lista kontrolna kupującego dla kolejności zdarzeń a księgowania

Sprawdź, czy Twoje endpointy poprawnie weryfikują podpis i okno czasowe. Brakujące zabezpieczenia prowadzą do strat finansowych. Duplikaty webhooków nie powinny tworzyć drugiego obciążenia.

Zacznij od IOSOR

Księguj prepaid-obciążenie na kluczu biznesowym, nie na kolejności przyjścia webhook. Późny DLR i wczesny accepted mogą wylądować w dowolnej kolejności; rejestr i tak pisze jeden wiersz. Powtórka w oknie podpisu nie może stworzyć drugiego obciążenia. Wymuś jeden późny i jeden wczesny status na opłaconej wysyłce i udowodnij jedno księgowanie.

Podsumowanie IOSOR

Kolejność przyjścia nie jest prawem rejestru. Klucz księgowania posiada pieniądze; kolejność kolejki nie.

Rób: księguj raz na kluczu idempotencji; późny DLR to status, nie nowe obciążenie.

Nie rób: obciążać znów, bo DLR przyszedł pierwszy, ani zostawiać drugiego wiersza za powtórzonym webhook.

Czy ten przewodnik był pomocny?

Powiązane przewodniki