Разница между Queued и Sent в IOSOR: единый путь сообщения

Разница между Queued и Sent в IOSOR: единый путь сообщения.

Единый стейт-машин для состояний Queued и Sent

Когда API-запрос поступает на платформу для отправки SMS или OTP на номер E.164, продуктовая и финансовая команды должны опираться на единый статус сообщения. В устаревших white-label решениях статус queued считается чисто техническим, пока финансы ждут итоговых отчетов. IOSOR устраняет этот разрыв с помощью детерминированного стейт-машина. После валидации HTTP-нагрузки сообщение мгновенно переходит в состояние queued, создавая запись в транзакционном журнале, фиксируя тариф и оформляя удержание средств на балансе.

Финансовое резервирование при очереди и окончательный расчет

При переходе в статус queued система проверяет остаток средств. Для обеспечения стабильности аккаунты должны соблюдать предоплатный порог USD 20 до запуска трафика в обработку. В момент постановки в очередь стоимость SMS-сегмента блокируется. При переходе из queued в sent холд превращается в окончательное списание. Если валидация не пройдена, заблокированные средства возвращаются на баланс. При росте объема и приближении к мягкому аудиту около USD 1,000/месяц параллельность реестра исключает расхождения баланса.

Триггеры перехода: от приёма API до отправки в сеть

Граница между queued и sent четко определена. Статус queued означает, что запрос валидирован, тариф рассчитан, а средства зарезервированы. Статус sent подтверждает, что шлюз передал PDU в сетевой интерфейс и получил промежуточный отклик. В эту миллисекунду система меняет статус на sent и генерирует событие через webhook. Номера выделяются через JIT-аллокацию, что гарантирует точный учет E.164 и MRC без лишних бронирований.

Сверка финансовых записей с отчетами о доставке DLR

Финансовый аудит часто расходится с логами из-за задержек DLR. В IOSOR статус sent является точкой окончательного фиксации списания. Статусы DLR (DELIVERED или UNDELIVERED) обновляют операционную аналитику, не меняя финансовую запись. Если получен входящий STOP, последующие попытки отправки на этот E.164 отклоняются на уровне API с проверкой Verify OK еще до финансовых холдов.

Операционный регламент и связанная архитектура

Для синхронизации инженерии и финансов используйте следующие руководства по очереди, идемпотентности вебхуков и механике кошелька:

• Ops webhook-consumer на volume
• Первая неделя пилота: правда о холдах и списаниях на живом трафике
• идемпотентность, retry и деньги

Начните с IOSOR

Откройте консоль IOSOR и свяжите статусы вебхуков очереди dispatch с вашей биллинговой системой. Настройте обработку события sent как точку фиксации финансовой транзакции до обработки отчетов DLR. Это позволит продуктовой и финансовой командам опираться на единую модель состояний сообщения.

Итог IOSOR

Этот материал доказал, что единый конечный автомат для статусов queued и sent полностью устраняет разногласия между продуктовой аналитикой и финансовым аудитом. Резервирование баланса при постановке в очередь с последующим списанием в момент отправки обеспечивает точный учет ресурсов независимо от задержек отчетов о доставке.

Фиксируйте финансовые списания строго по событию перехода статуса в sent на краевом шлюзе. Не используйте финальные DLR для признания первичных затрат и не разрешайте продуктовым сервисам трактовать queued как гарантию отправки трафика.