Почему SMS о заказе не доставляются: диагностика в 2026 году

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

Почему интернет-магазин видит отправку, но клиент не получает SMS?

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

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

• Запрос принят API, но сообщение ещё стоит в очереди.
• Сообщение передано оператору, но телефон временно недоступен.
• Доставка подтверждена, однако клиент проверяет другой номер.
• Шлюз отклонил запрос из-за формата номера, текста или имени отправителя.
• Сайт не получил callback со статусом и показывает устаревшую информацию.

Транзакционные SMS важны именно в момент события: после заказа, перед доставкой, при изменении статуса или отмене. История с 68-летним минчанином показывает, какую практическую роль могут играть банковские уведомления: мужчина узнал о покупках, которых не совершал, и после этого обнаружил пропажу карты (источник: «Минчанин получил SMS об оплате покупок – но он их не совершал», Myfin.by). Для интернет-магазина похожая логика работает с заказом: сообщение должно помогать клиенту понять, что произошло.

С чего начать проверку SMS-интеграции?

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

1. Проверьте, создалось ли событие отправки после оформления заказа.
2. Убедитесь, что сайт передал правильный номер, а не телефон из старого профиля.
3. Сверьте время запроса и часовой пояс в журнале событий.
4. Посмотрите тело запроса и ответ API, удалив из открытых логов сам текст и номер.
5. Найдите финальный статус доставки в личном кабинете или отчёте SMS-сервиса.

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

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

Какие ошибки в номере мешают доставке?

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

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

Проверьте также такие сценарии:

• клиент указал номер с ошибкой при оформлении заказа;
• заказ импортировали из другой системы вместе с устаревшим телефоном;
• один номер записан в разных форматах в CRM и на сайте;
• тестовый заказ отправляет SMS на телефон сотрудника;
• номер содержит добавочный телефон или несколько значений в одном поле.

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

Как текст SMS влияет на доставку?

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

Проверьте готовый текст именно в том виде, в котором его получает API. Шаблон в административной панели и фактическая строка запроса могут отличаться. Для заказа полезно оставить только необходимые сведения: название магазина, номер заказа, текущий статус и понятное действие для клиента.

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

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

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

Что проверить в API и автоматизации магазина?

Сбой часто возникает на границе между сайтом и SMS-сервисом. Интернет-магазин может отправить запрос до того, как заказ получил окончательный статус, либо повторить его после задержки ответа. Поэтому у каждого события должна быть понятная схема: какое действие запускает SMS, какое поле содержит статус и что происходит при ошибке.

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

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

Для сообщений о доставке полезно связать SMS с реальным изменением статуса заказа. Отдельный разбор такой автоматизации есть в статье как настроить SMS о доставке интернет-магазина. Там проще увидеть, какие события стоит передавать в уведомления, а какие не требуют сообщения.

Какие типичные ошибки мешают найти причину?

• Проверяют только статус «отправлено» и не ищут финальный статус доставки.
• Тестируют один номер, хотя проблема возникает только с отдельным форматом.
• Меняют шаблон, ключ API и настройки триггера одновременно, поэтому причина теряется.
• Не записывают идентификатор сообщения и связывают SMS с заказом вручную.
• Отправляют повторное сообщение после тайм-аута, не проверив, принял ли запрос шлюз.
• Считают, что ошибка находится у оператора, не посмотрев ответ API и журнал сайта.

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