IOSOR

IOSOR База знань

Падіння primary rail: впорядкований backup без подвійного списання

Коли primary rail messaging недоступний, рухайтесь задокументованим порядком backup: один client intent — одне prepaid-списання, white-label статуси без назв upstream-брендів.

Коли основний шлюз не може прийняти або завершити відправку, система повинна запустити суворо впорядкований каскад резервних маршрутів із гарантією захисту від подвійного списання. Перемикання — це не хаотичний перебір усіх каналів, а чітка послідовність із кінцевою зупинкою, де один інтент клієнта формує лише один дебет у гаманці. Для бізнесу на IOSOR із мінімальним поповненням USD 20 та порогом перевірки біля USD 1 000/місяць це повністю усуває фінансові ризики. Докладніше у матеріалах: Гейти failover до будь-якого бейджа Live, DLR, затримка і failover та плейбук низької доставляності SMS.

Впорядкований backup — не хаотичний spray

Порядок фіксують до production. Primary обслуговує коридор, доки здоровий. На hard reject, timeout за смугою коридору або vault-not-ready — перехід до наступного rail. Не розсилайте один OTP паралельно на три rail. Не вигадуйте порядок mid-incident.

Зафіксуйте: які класи вмикають switch, які чекають лагу DLR, які лишаються на primary з failed. Деталі latency — у сусіда з deliverability; тут — «перемикати зараз» проти «чекати».

Одне списання на один client intent

Дотримуйтесь prepaid-резерв до першого списання: резерв один раз, settle один раз, коли rail прийняв unit. Backup під тим самим intent перевикористовує грошову ідентичність — ідемпотентність, retry і гроші. Другий debit «бо інший rail» — баг фінансів, не resilience.

Якщо hold не вдався або unit не був owed — release через збій prepaid-hold: auto-refund і статус. Не два settled debit на один ключ; не фейковий Delivered, якщо жоден rail не завершив доставку.

Подія Гроші Зміст для клієнта
.

White-label статус під час падіння primary

Клієнтський UI і export показують статуси IOSOR: accepted, pending, delivered, failed, needs attention — ніколи рядки брендів rail. Ops може логувати rail, що виконав unit; покупець — ні. На switch оновлюйте той самий рядок intent: змінюються outcome і timestamps; грошова ідентичність — ні.

Коли це ще не failover

Низький inbox за чесного Accepted/Sent — доставляність: плейбук низької доставляності SMS, не сліпий flip. Пізній DLR після здорового accept — лаг: DLR, затримка і failover — не другий debit на backup. Користувацький resend — нова дія з новим ключем.

Обмежте burn через контроль prepaid-витрат до soft USD 1 000/міс.

Чекліст покупця для впорядкованого шляху

  1. Порядок backup записано й власника призначено до Live?
  2. Кожен клас збою = чекати, fail чи наступний rail?
  3. Один idempotency key покриває гроші primary і backup?
  4. Клієнтські статуси white-label без upstream-брендів?
  5. Hold-fail шляхи роблять auto-release без settled-привидів?
  6. Стелі витрат активні проти шторму failover на пілоті?

Почніть з IOSOR

У консолі маршрутизації зафіксуйте єдиний фінансовий інтент перед перемиканням на резервний шлях, щоб повністю уникнути подвійних списань. Завжди перевіряйте леджер, тайм-аути шлюзів та експорт подій у UTC до активації каскаду.

Пов’язане: failover gate before live badge dlr latency failover product finance.

Підсумок IOSOR

Це ops-дисципліна для зміни. Налаштуйте таймаути та єдиний hold у консолі еквайрингу, перевірте ledger і експортуйте звіт у UTC для повної фіксації резервного маршруту без ризику подвійних списань.

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

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