IOSOR

IOSOR База знань

Undelivered vs rejected vs expired: словник статусів для продукту та білінгу

Спільний словник статусів для B2B: що насправді означають undelivered, rejected і expired, кого за що списують, і як зупинити суперечку продукту й фінансів навколо одного webhook.

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

IOSOR — white-label prepaid messaging з одним словником статусів для продукту, ops і гаманця: слово статусу означає те саме в дашборді, тілі webhook і в інвойсі.

Чому слова статусів створюють більше інцидентів, ніж збої

Реальний збій рідкісний і очевидний. Вівторок спалює тікет support «повідомлення не дійшло», коли три різні системи залогували три різні terminal state.

Словник статусів, який приймуть продукт і білінг

Статус Що означає Хто виправляє
Accepted / queued Платформа прийняла задачу; ще не пішла в маршрут Ніхто — це норма
Sent / submitted Пішло в live-маршрут Не proof доставки на пристрій
Delivered Позитивне terminal-підтвердження Сигнал рівня конверсії
Undelivered Прийнято й відправлено, але доставка не підтверджена до timeout Ops: здоров'я маршруту/напрямку
Rejected Відхилено до/під час передачі мережею чи policy Продукт: формат номера, opt-out, контент, compliance
Expired Сплив TTL у черзі чи в польоті; не вирішено Продукт: політика retry/TTL, не «баг»

Роздрукуйте цю таблицю — нехай на неї вказують продукт, support і фінанси під час інциденту.

Undelivered vs rejected: різні класи відмови, різні фікси

Undelivered зазвичай означає: повідомлення коректно пішло з платформи, але щось нижче за потоком — мертвий handset, carrier-фільтр, тимчасова проблема маршруту — мовчки його проковтнуло. Фікс — у маршрутизації, retry чи ревʼю якості напрямку, не в коді застосунку.

Rejected зазвичай означає: у повідомлення ніколи не було шансу — невірний формат номера, opt-out у списку, заблокований sender ID, чи compliance-правило спрацювало до відправки. Фікс — у продукті: валідувати ввід, поважати suppression-листи, полагодити реєстрацію відправника — не в ескалації support «зробіть доставку кращою».

Змішування цих двох витрачає час інженерів на гонитву за проблемою маршрутизації, яка насправді баг валідації, або навпаки.

Expired: TTL, черги й тайм-вікна OTP

Expired — окрема категорія, бо це проблема часу, не доставки.

  1. TTL коротший за реалістичну latency коридору для цього напрямку.
  2. Черга скупчилася вище за потоком до відправки (rate limits, retries, batch-джоби).
  3. Користувач все одно не збирався використовувати код через кілька хвилин.

Для OTP-потоків expired-сегменти найчастіше — питання UX і налаштування TTL, а не скарга на мережу; звіртеся з гайдом платформи щодо TTL/resend, перш ніж відкривати тікет про доставку.

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

  • Існують лише два стани: «sent» і «failed»
  • Support не може за запитом сказати, якому рядку інвойсу відповідає який статус
  • «Rejected» і «undelivered» біляться однаково без пояснення
  • Expired трактується як загадка, а не питання налаштування TTL
  • Визначення статусів відрізняються між дашбордом, webhook та інвойсом

Почніть з IOSOR

Перевірте мапінг DLR у консолі IOSOR та розмежуйте обробку термінальних статусів у вебхуках для білінгу й продуктової команди. Налаштуйте шлюз так, щоб події Expired коригували TTL для OTP, а статуси Rejected відразу зупиняли повторні спроби. Це усуне розбіжності в інвойсах та зменшить кількість звернень до саппорту.

Підсумок IOSOR

Цей гайд довів, що більшість інцидентів виникає не через збої мережі, а через плутанину між поняттями Undelivered, Rejected та Expired.

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

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