Різниця між 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 на обсязі
• Перший тиждень пілоту: правда про холди та списання на живому трафіку
• ідемпотентність, retry і гроші

Почніть з IOSOR

Синхронізуйте фінансові та інженерні журнали в консолі IOSOR, встановивши фіксацію списання на статус «sent». Налаштуйте вебхуки для відстеження переходу від резервування коштів у стані «queued» до остаточного проведення транзакції. Це усуне розбіжності між звітами розробників та бухгалтерією ще до отримання остаточних DLR.

Підсумок IOSOR

Цей матеріал довів, що статуси «queued» та «sent» мають служити єдиним джерелом правди як для продуктової команди, так і для фінансового відділу. Резервування балансу під час перебування повідомлення в черзі гарантує платоспроможність платформи, а статус «sent» є невідворотним моментом списання коштів незалежно від затримок операторських DLR.

Використовуйте статус «sent» як єдиний тригер для фінансових аудитів і проведення дебету. Не переносьте списання коштів на етап отримання DLR і не трактуйте статус «queued» як зафіксоване витрачання бюджету до моменту фактичної передачі PDU у мережу.