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

Откройте консоль IOSOR и проверьте маппинг DLR-вебхуков для входящих статусов доставки. Разделите обработку Undelivered, Rejected и Expired на уровне шлюза и логики повторных попыток. Настройте правила биллинга так, чтобы отклоненные до отправки трафика запросы не тарифицировались как доставленные.

Итог IOSOR

Смешивание статусов доставки создает хаос в продуктовых метриках и биллинге.

Был ли материал полезен?

Связанные гайды