Статус UNKNOWN не є доставкою: фіксація DLR в IOSOR

У платформі IOSOR будь-який DLR зі статусом UNKNOWN повинен трактуватися як недоставлений для збереження цілісності балансу. Штучне переписування помилок OTP на успішний стан призводить до фінансових розбіжностей. Точне відображення API та webhook гарантує коректне списання USD і синхронізацію JIT-операцій.

Аналіз статусу UNKNOWN у системних логах

У бізнес-моделі white-label CPaaS остаточний статус повідомлення визначає точность доставки та правильність фінансових розрахунків. Коли вихідне SMS або OTP відправляється у форматі E.164, ядро платформи відстежує проходження трафіку через операторські вузли. Якщо звіт про доставку (DLR) повертає статус UNKNOWN або undelivered, це означає відсутність підтвердження від мобільної мережі отримувача. Платформа IOSOR записує кожну зміну стану до незмінного реестру.

Чому недоставлені коди не перезаписуються як Success

Фундаментальне правило обробки повідомлень полягає у тому, що статуси UNKNOWN або недоставлені коди не перезаписуються як success у реєстрі. Спроба примусово змінити стан на 'Verify OK' або 'Delivered', коли DLR містить неопределеність, є порушенням фінансового контролю. Якщо сервіс надсилає авторизаційний пароль і не отримує підтвердження, штучна зміна статусу створює ризик помилкових дій.

Фінансові утримання та звірка балансу при збоях

Розрахунковий модуль white-label платформи функціонує за предоплатною схемою. Під час виклику API для відправки повідомлення система робить тимчасове утримання (hold) коштів на балансі. Після завершення обробки утримання перетворюється на списання (debit) або повертається згідно з правилами маршруту. Оскільки запити до мереж несуть реальні витрати, статус UNKNOWN не завжди передбачає повернення коштів.

Робота з webhook-сповіщеннями та кодами відповідей

Зовнішні додатки отримують інформацію про статус доставки через автоматичні webhook-повідомлення. Структура payload містить ID повідомлення, часову мітку, номер E.164 та статус, наприклад UNKNOWN. Інтеграційний код повинен обробляти ці параметри без спроб корегування первинного стану. Якщо відправка OTP виходить за межі таймауту, додаток має запускати резервні сценарії.

Оптимізація трафіку та внутрішні правила маршрутів

Щоб зменшити кількість нечітких статусів доставки, необхідно постійно аналізувати логи та очищати бази від недійсних номерів. Недоступні адресати E.164 та системні затримки мають швидко виявлятися.

Пов’язані матеріали: Довідник кодів помилок для фінансистів та технічної підтримки · Довідник помилок та інструкції з доставляння у CPaaS · prepaid-резерв до першого списання.

Почніть з IOSOR

Щоб забезпечити цілісність балансу в консолі IOSOR, перейдіть до панелі маршрутизації шлюзів та мапування DLR для перевірки правил трансляції статусів. Переконайтеся, що будь-які вхідні колбеки зі статусами 'UNKNOWN' або 'UNDELIVERED' суворо мапуються на кінцеві помилки без можливості перехоплення чи зміни. Запустіть симуляцію в тестовому середовищі IOSOR, щоб підтвердити блокування ручних коригувань реєстру для цих кодів.

Підсумок IOSOR

Спроби штучного перетворення статусів UNKNOWN або недоставлених повідомлень на успішні транзакції є критичним порушенням стандартів звітності. Такі маніпуляції призводять до невідповідностей у фінансових реєстрах та викривлення метрик доставки. Щоб уникнути помилок, операторам слід перевіряти статус через консоль або вивантажувати логи в UTC для порівняння з даними шлюзу. Замість примусової зміни статусів, налаштуйте автоматичні вебхуки для передачі реальних результатів DLR у вашу систему. Детальніше про налаштування сповіщень читайте у /learn/webhooks-setup. Завжди зберігайте цілісність даних, щоб уникнути розбіжностей у білінгу.