Почему SMS-уведомление о заказе не дошло: диагностика от API до телефона

Если покупатель не получил SMS о заказе, проверяйте цепочку по порядку: событие в интернет-магазине, запрос к SMS API, ответ сервиса, статус доставки и телефон получателя. Такой разбор помогает найти конкретный сбой, а не отправлять сообщение повторно вслепую. Ниже — план проверки для магазина: какие записи посмотреть, как отличить ошибку интеграции от задержки доставки и что исправить перед следующей отправкой.

С чего начать диагностику недоставленного SMS?

Найдите заказ по его номеру и запишите время, когда покупатель оформил покупку. Затем проверьте, произошло ли событие, которое должно запускать уведомление. Если заказ появился в системе, но события для отправки нет, искать проблему в телефоне рано: сообщение ещё не передавали в SMS-сервис.

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

Сравните время события и время запроса. Если они не совпадают, проверьте очередь отправки и правила автоматизации: заказ мог перейти в нужный статус позже, а задача — остаться в очереди после ошибки.

Как проверить запрос к SMS API?

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

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

Разделите два случая: API отклонил запрос или принял его. В первом случае исправляйте данные и настройки запроса. Во втором найдите сообщение в отчёте сервиса по идентификатору. Сам факт принятия запроса ещё не означает, что SMS уже появилось на экране телефона.

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

Что означает статус доставки?

Статус помогает определить следующий участок для проверки. Сначала посмотрите, принял ли сервис запрос; затем выясните, передал ли он сообщение дальше и какой итоговый статус вернул. Значение статусов зависит от подключённого сервиса, поэтому ориентируйтесь на его описание, а не на одно слово в интерфейсе.

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

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

Какие ошибки чаще всего мешают доставке?

• Событие отправки привязано не к тому статусу заказа. Проверьте правило на тестовом заказе.
• Интеграция передаёт старый или неверно записанный номер. Сверьте данные в заказе и запросе API.
• Магазин не сохраняет ответ сервиса. Добавьте запись результата, чтобы видеть, принял ли API запрос.
• Сообщение отправляется повторно после тайм-аута без проверки результата первой попытки. Сначала найдите исходный запрос по его идентификатору.
• Статус в отчёте трактуют как подтверждение, что клиент прочитал SMS. Проверяйте только то, что именно сообщает подключённый сервис.

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

Начните с одного недоставленного заказа: проверьте событие, найдите ответ API и сопоставьте его со статусом сообщения. Так вы быстро определите, какой участок требует исправления, и сможете проверить результат на следующем тестовом заказе.