SMS с сайта: почему успешный запрос не равен доставке

Сайт получил успешный ответ сервиса и написал «SMS доставлено», но клиент сообщения не увидел. Возможная ошибка интеграции — общий результат API принят за результат конкретного отправления. При работе с SMS нужно отдельно учитывать запрос, отдельное сообщение и последующее состояние доставки. Иначе зелёная отметка подтверждает лишь часть цепочки, а поддержка не может установить, что случилось дальше.

Ниже разобран документированный пример SMS.RU и предложен порядок проверки собственной интеграции. Числовые коды нельзя переносить на другого поставщика без его документации. Материал не рекомендует рассылку по чужим базам, обход ограничений или массовые проверочные отправки. Испытания проводят с разрешёнными учебными данными и контролируемыми получателями; параметры реальной услуги согласуют отдельно.

У ответа есть несколько уровней

В JSON-примере отправки SMS.RU есть общий status_code и отдельные сведения для получателей внутри sms. Общий код 100 относится к выполнению запроса. У конкретного получателя собственный успешный код 100 означает принятие сообщения для отправки, а не уже установленную доставку. В том же ответе для другого получателя может находиться ошибка. Одна верхняя отметка не описывает весь результат списка.

Поэтому разработчик должен читать нужный уровень ответа. Система не должна отмечать всех адресатов как успешно уведомлённых только по общему status="OK". Сохраните отдельную запись для каждого сообщения и его результат, привязанный к бизнес-событию. Для клиента это может быть один экран, но за ним остаются несколько различимых состояний, которые поддержка должна уметь объяснить.

Не определяйте состояние только по совпадению числа. В ответе метода получения статуса общий код успешного запроса также не является результатом доставки конкретного SMS. Важны метод, положение поля и идентификатор сообщения. Запись «провайдер вернул 100» без этого контекста недостаточна для диагностики. Попросите специалиста указать, к какому объекту относилось значение.

Какие результаты не следует смешивать

В документации метода статуса SMS.RU код 103 у отдельного сообщения относится к доставке, а 104 описывает завершение срока жизни без доставки. Это пример смыслов конкретного API, не универсальные обозначения для всех сервисов. Не показывайте «клиент прочитал» только по результату доставки: действие человека остаётся отдельным событием.

Полезный экран поддержки показывает не только код, но и его понятную интерпретацию вместе со временем. Если последнего результата пока нет, так и обозначьте неопределённость. Не заменяйте её словом «ошибка», если такого вывода нет в данных. Аналогично промежуточное принятие не должно превращаться в окончательный успех из-за одного общего зелёного значка.

Сохраните связь события и сообщения

Уведомление начинается с события вашей системы: подтверждена запись, изменён заказ или запрошен вход. У этого события должен быть безопасный внутренний идентификатор. Попытка передать уведомление и идентификатор провайдера связаны с ним, но не заменяют его. Если ответ потерялся, нельзя по отсутствию локального ID сразу заключить, что сообщения у сервиса нет. Зафиксируйте, что результат данной попытки пока неизвестен.

Для повторной попытки сохраните отдельную запись. Иначе новая отправка затрёт историю первой, а клиент получит несколько сообщений, которые поддержка будет считать одним. Показывайте время постановки, известный результат обращения и время последнего обновления. Не храните в общем журнале ключи API, действующие коды входа или полный текст, если для диагностики достаточно шаблона и технического ID. Расшифровка события должна быть доступна только нужным сотрудникам.

Последующее состояние должно попадать в вашу систему

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

Получение нового результата не должно обновлять случайное сообщение того же клиента. Один человек может ожидать несколько разных уведомлений. Сопоставляйте событие с конкретным идентификатором попытки и сообщения, а не только с номером телефона. Для поддержки полезен просмотр всей цепочки в хронологическом порядке. Если разные части системы показывают разные состояния, сначала проверьте их основания и время, а не меняйте статус вручную на самый удобный.

Текст интерфейса должен соответствовать известному факту

Определите, что сайт пишет сразу после действия. Формулировка о принятом запросе отличается от утверждения о доставке. Если система пока знает лишь начало отправки, экран должен отражать именно это. Выберите понятные слова, которые не заставляют клиента считать отсутствие сообщения доказанной ошибкой его телефона. Состояние нужно объяснять по фактам, а не назначать виновного заранее.

При этом не перегружайте публичный экран техническими кодами. Подробности нужны рабочему журналу и специалисту, а клиенту — понятный следующий шаг, предусмотренный процессом. Не показывайте чужие уведомления или лишние сведения об аккаунте в диагностическом ответе. Отдельно согласуйте, как пользователь сообщает о проблеме и какие безопасные данные связывают обращение с его событием. Полный снимок административного кабинета для этого не требуется.

Доставка кода и успешный вход являются разными событиями

Если сообщение содержит код, результат его доставки не подтверждает, что код ещё действителен в приложении или был правильно введён. Система входа имеет собственные состояния. Для разбора жалобы установите, относится она к получению сообщения, проверке введённого значения или продолжению сценария после проверки. Одна общая ошибка «SMS не работает» скрывает эти различия и направляет исправление не в тот компонент.

Здесь не назначаются сроки жизни кодов и правила безопасности входа: их нужно проектировать отдельно. Практически важно связать сообщение с нужным событием, сохранив секретное содержимое закрытым. Более позднее уведомление по другому запросу не объясняет судьбу предыдущего. Поддержка должна различать цепочки и не предлагать пользователю бессистемно запрашивать новые коды, пока разбирается состояние уже созданных попыток.

Проверяйте обработку ответов без настоящей рассылки

Для приёмки разработчик может использовать заранее подготовленные учебные ответы. Включите общий успех с разными результатами получателей, отдельную ошибку запроса, отсутствие ожидаемого идентификатора и последующее изменение состояния конкретного сообщения. Эти примеры должны соответствовать формату выбранного сервиса. Они проверяют обработку данных, но не являются доказательством реальной доставки в сеть и на устройство.

Документация отправки SMS.RU также описывает test=1 как имитацию отправки без передачи самого SMS. Если используется этот режим, отметьте его в протоколе. Успешный тест интеграции не следует выдавать за подтверждение фактического получения клиентом. Ограниченную реальную проверку, когда она нужна, планируют отдельно на контролируемых адресатах с понятным основанием. Для автоматического теста не берут чужие номера и не запускают серию платных повторов.

Как разобрать жалобу без лишней повторной отправки

Начните с конкретного события, времени и безопасного номера обращения. Найдите связанные попытки и провайдерские идентификаторы. Установите, что известно для каждой записи, и отделите отсутствие сведений от документированного конечного результата. Если проблема относится к поставщику, передайте ему предусмотренные технические ссылки через согласованный канал. Не публикуйте рабочие реквизиты интеграции в открытом обсуждении.

Решение о новой попытке должно соответствовать состоянию и ограничениям процесса. Оно не выводится из одной жалобы или общего зелёного значка. Если результат первой отправки неизвестен, обозначьте эту неопределённость и сначала предусмотренным способом выясните её судьбу. После исправления сохраните пример, на котором ошибка проявлялась, и проверьте его повторно в учебной среде. Приёмка должна показать правильные состояния, а не только отсутствие исключения в коде.