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
- Hold/settle незалежні від HTTP arrival?
- Late DLR оновлює outcome — не другий debit?
- Early MO не списується як outbound?
- Refund/release блокує resettle money?
- Workers на обсязі застосовують ту саму таблицю?
- 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.
Чи був матеріал корисним?
Пов’язані гіди
- Моніторинг стану кінцевих точок вебхуків
Дізнайтеся, як відстежувати затримки відповідей та коди стану в IOSOR для запобігання збоям при доставці сповіщень та забезпечення стабільності системи.
- Налаштування вебхуків для контролю порогів балансу
Дізнайтеся, як налаштувати автоматичні сповіщення про баланс в IOSOR для запобігання перервам у сервісі та ефективного керування JIT-виділенням номерів.
- Обробка подій вебхуків для оперативного виділення номерів
Опануйте автоматизацію життєвого циклу каналів через JIT-вебхуки в IOSOR. Налаштовуйте миттєве призначення номерів та керування балансом у вашій CPaaS-платформі.