IOSOR База знань

Порядок подій vs posting у ledger

Out-of-order DLR і MO не мають ламати правила prepaid debit — порядок прибуття HTTP не закон грошей.

Мережа доставляє callbacks out of order. Пізній DLR, ранній MO чи status flip до settle не мають вигадувати другий debit або переписувати settled-рядок. Ця сторінка — контракт порядку posting: правила ledger переживають перестановку подій. Це не primer про correlation ID і не есе MO-vs-MT billing.

Пов’язані: Дублікат webhook не повинен писати другий debit, Ops webhook-consumer на обсязі, Гейт підпису й вікна replay, Контракт webhook перед першим надсиланням, debit і delivery status в одному ledger.

IOSOR — white-label prepaid. USD 20 фінансує smoke out-of-order на одному коридорі; soft review близько USD 1 000/міс робить «остання подія перемагає money» боргом recon. Клієнт бачить лише white-label слова статусів.

Порядок прибуття — не закон ledger

HTTP arrival — транспортна випадковість. Money поститься за hold → settle → outcome-update з контракту, а не за «який callback прийшов останнім». Soft USD 1 000/міс вважає перестановку інцидентом finance, коли product показує success, а ledger рухається двічі. USD 20 доводить: forced late DLR не відкриває parallel debit. Same-ID replay: Дублікат webhook не повинен писати другий debit. Тут — різні події, хибна послідовність.

Як виглядає out-of-order

Патерн прибуття Безпечний posting Небезпечна реакція
DLR до settle ack Pending; settle один раз під hold Debit з одного DLR
Failed → delivered (один ключ) Outcome in place Другий charge за flip
MO до correlate MT Inbox; join коли MT settles Charge MO як outbound
Status після refund/release Без нових money Resettle released intent
Два terminal, один intent Один money-рядок Два debit-рядки.

Правила posting, що переживають перестановку

Hold і idempotency keys до side effects (Контракт webhook перед першим надсиланням). Settle money один раз на billable intent; пізні події оновлюють лише outcome. Не відкривати parallel debit через ранній чи пізній DLR/MO. Reject/park поза signed window — без invented success. Export join за intent — не за arrival timestamp. Money↔outcome: debit і delivery status в одному ledger. Soft volume language blocked, доки smoke показує два money-рядки на один intent.

Lag нормальний; double money — ні

Pending після settle звичний. Другий charge за той самий ключ через пізній callback — баг. Product і finance ділять terminal words без hero upstream codes: Спільна мова статусів для product і finance. USD 20 доводить коридор, де DLR-before-settle і settle-before-DLR лишають один prepaid-рядок.

Чекліст покупця: порядок подій vs posting

  1. Hold/settle незалежні від HTTP arrival?
  2. Late DLR оновлює outcome — не другий debit?
  3. Early MO не списується як outbound?
  4. Refund/release блокує resettle money?
  5. Workers на обсязі застосовують ту саму таблицю?
  6. Soft USD 1 000/міс blocked, доки smoke червоний?

Будь-яке «ні» тримає ordered ledger posting у draft.

Почніть з IOSOR

У консолі: Event order vs ledger posting must reconcile by shared id.. Назвіть власника і гейти перед розширенням.

Пов’язане: duplicate webhook no second debit webhook consumer ops at volume.

Підсумок IOSOR

Це ops-дисципліна для зміни—не брошура.

Робіть: name owner + gate. Не: skip the gate.

Чи був матеріал корисним?

Пов’язані гіди