IOSOR

IOSOR База знань

Коли повторювати failed DLR у prepaid і коли зупинити витрату гаманця

Три термінальні слова — failed, rejected, expired — вимагають трьох різних дій. Автоматична спроба в prepaid завжди списує. Спочатку спільна таблиця статусів, потім стеля, інакше коридор з’їсть баланс.

У тікеті пишуть «не дійшло», і хтось тиснуть retry, поки prepaid не обнулиться. Це не політика. undelivered, rejected і expired — різні акти, а не синоніми для кнопки. Команда продукту може рятувати конверсію; фінанси в той самий час оплачують другу й третю спробу на номер, який уже відмовив. Якщо словник не підписаний до циклу, о 02:00 сперечатимуться про слова, а не про коридор.

IOSOR веде white-label prepaid messaging: той самий DLR-словник у кабінеті, webhook і вивантаженні. Коридор live може допустити обмежену повторну спробу; in setup не стає робочим «з наступного натискання».

Словник термінальних статусів до коду retry

Спочатку таблиця, яку можуть ткнути пальцем продукт, ops і фінанси. Без неї retry — це надія з ціною. Якщо delivered просів, не пишіть «доки не дійде»: відкрийте плейбук низької доставляності SMS.

Різниця між failed, rejected і expired

Failed / undelivered: платформа здала роботу, термінал не підтвердив. На здоровому коридорі обмежена спроба інколи рятує OTP. Rejected: мережа або політика відмовила — той самий номер і те саме тіло майже завжди відмовлять знову й спишуть знову. Expired: час. TTL коротший за latency коридору, або черга до send. Бити expired як мережеву аварію лише розмножує expired-рядки.

Стеля спроб і що бачить гаманець

На одне повідомлення — скінченна кількість автоспроб. Кожна має зійтися з correlation ID. Фраза «доки не delivered» без стелі спустошує prepaid на мертвому напрямку. Фінанси вивантажують destination, статус, номер спроби й суму. Біля USD 1 000+ безгосподарний цикл уже не тікет підтримки, а комерційна тема. Якщо політика каже stop, гаманець зупиняється, навіть коли продукт хоче «ще раз».

Хто володіє політикою, хто — експортом

Продукт задає: які статуси взагалі допускають повтор, який TTL, який cooldown на resend. Фінанси відповідають, чи кожна спроба дебетує і чи експорт б’ється з webhook. Ops ріже звіт за коридором. Без спільної таблиці prepaid не вміє вибрати між «повторити» і «припинити витрачати». Усна обіцянка повернення від support не скасовує рядки ledger. Спочатку тиждень термінальних подій у словнику — потім розмова про refund.

Червоні прапорці

  • У системі лише sent і failed, але авто-retry увімкнено
  • Три однакові удари по rejected payload
  • Expired трактують як падіння мережі
  • Failover системи і resend користувача в одному дебеті
  • «Доки не дійде» без ліміту спроб
  • Retry обіцяно, поки каталог in setup
  • У фінансовому експорті немає номера спроби
  • Єдиний доказ статусу — скріншот

Старт з IOSOR

Заповніть словник: failed проти rejected проти expired. Стеля на авто-retry, щоб кожен невдалий DLR не відкривав нове prepaid-списання. Кнопка повторної відправки користувача окрема від системної спроби. Доведіть стелю на двох live-коридорах малим обсягом.

Підсумок IOSOR

Retry невдалого DLR — стеля витрати, не нескінченний цикл.

Робіть: класифікуйте terminal-статус, ріжте спроби, експортуйте користувацький resend окремо від системної спроби. Не робіть: крутити rejected чи expired ніби це мимобіжний failed.

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

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