Чтобы отправить покупателю SMS после заказа на Ozon, продавцу нужен связующий сервис: он получает событие о заказе через вебхук, проверяет данные и передаёт сообщение в SMS-шлюз по SMPP. В статье разберём практическую схему для бизнеса в Беларуси: какие компоненты подготовить, как обработать повторные события, где использовать статусы доставки и что проверить до запуска. Техническое описание SMPP доступно в инструкции по мониторингу SMPP через DLR.
Как выглядит цепочка от заказа до SMS?
Схема состоит из четырёх частей: площадка с заказом, ваш сервер, SMPP-шлюз и сеть оператора. Площадка передаёт вашему серверу событие через вебхук. Сервер извлекает номер телефона и нужный статус заказа, формирует текст, затем открывает SMPP-сессию и отправляет сообщение.
Для небольшого магазина удобно начать с одного сценария: уведомлять клиента после подтверждения заказа. Позже к нему можно добавить сообщения о передаче отправления, готовности к выдаче или задержке. Каждый сценарий лучше связывать с отдельным событием, чтобы покупатель не получил два одинаковых SMS.
| Этап | Что происходит | Что проверяет разработчик |
|---|---|---|
| Событие заказа | Площадка сообщает об изменении заказа | Тип события и его идентификатор |
| Обработка вебхука | Ваш сервер принимает запрос | Формат данных, подпись или другой способ проверки запроса |
| Подготовка SMS | Сервер выбирает текст и номер получателя | Наличие телефона, длину и код страны |
| Отправка по SMPP | Сервис передаёт сообщение шлюзу | Соединение, лимит скорости и ответ шлюза |
| Статус доставки | Шлюз возвращает результат доставки | Связь статуса с конкретным сообщением и заказом |
Какие данные передавать из вебхука?
Внутри системы достаточно хранить технический идентификатор заказа, его статус, номер телефона, текст сообщения и идентификатор SMS. Идентификатор заказа нужен для защиты от повторной отправки. Идентификатор SMS связывает ответ шлюза с записью в вашей системе.
Вебхук не стоит обрабатывать прямо в том же запросе, в котором вы отправляете SMS. Сначала сервер принимает событие и быстро отвечает площадке, затем кладёт задачу в очередь. Отдельный обработчик берёт задачу из очереди и работает со SMPP. Если шлюз временно занят, заказ не теряется, а задача остаётся в очереди.
Полезное правило для разработчика: одно событие заказа должно иметь один ключ идемпотентности. Например, ключ можно собрать из идентификатора заказа и типа статуса. При повторной доставке вебхука сервер увидит уже обработанный ключ и не создаст второе SMS.
Как настроить SMPP-соединение для уведомлений?
Шлюз обычно предоставляет параметры подключения: адрес, порт, логин, пароль, системный тип, режим передачи и допустимую скорость. Эти значения задаёт провайдер SMS-шлюза. Их переносят в конфигурацию приложения, а не записывают в исходный код.
Приложение устанавливает SMPP-сессию, проходит bind и отправляет сообщения через submit_sm. После отправки шлюз возвращает идентификатор сообщения. Его нужно сохранить рядом с заказом, иначе последующий статус доставки будет трудно сопоставить с конкретным клиентом.
Соединение проверяют через Enquire Link. Если сервер перестал отвечать, приложение закрывает старую сессию и создаёт новую по правилам, заданным шлюзом. Практические настройки этого механизма разобраны в материале про Enquire Link на SMPP-шлюзе.
Очередь также защищает от слишком быстрой отправки. Если шлюз возвращает Throttling или Message Queue Full, приложение не должно бесконечно повторять запросы сразу же. Задачу переводят в состояние ожидания и повторяют по возрастающему интервалу. Отдельно фиксируют число попыток и последний ответ шлюза. Пример такой логики описан в статье о повторной отправке при ошибках Throttling и Message Queue Full.
Как связать DLR со статусом заказа?
Ответ о принятии сообщения шлюзом ещё не означает, что SMS дошло до телефона. Для контроля нужен DLR, то есть отчёт о доставке. Сервис получает такой отчёт и обновляет запись SMS: сообщение доставлено, отклонено, просрочено или получен другой статус, предусмотренный шлюзом.
В карточке заказа полезно хранить два разных результата: «SMS принято шлюзом» и «SMS доставлено». Это помогает отделить ошибку приложения от проблемы доставки. Если сообщение не принято сразу, разработчик проверяет код ответа SMPP. Если сообщение принято, но DLR сообщает об ошибке, анализируют номер, маршрут и итоговый статус.
Для уведомлений о заказах важна также повторная отправка вебхука со стороны площадки. Система должна повторно вернуть успешный ответ после того, как событие сохранено, но не создавать новую SMS-задачу при каждом повторе. Проверку делают по ключу события, а не по времени получения запроса.
Что проверить перед запуском?
Тестирование лучше проводить на отдельном тестовом заказе и на номере, доступном разработчику. Сначала проверяют приём вебхука, затем постановку задачи в очередь, отправку через SMPP и получение DLR. После этого отдельно моделируют повторное событие и временную недоступность шлюза.
Типичные ошибки
- Система отправляет SMS при каждом повторе одного и того же вебхука.
- Разработчик считает ответ submit_sm подтверждением доставки.
- Идентификатор сообщения шлюза не сохраняется в базе.
- При обрыве соединения приложение продолжает использовать старую SMPP-сессию.
- Ошибки Throttling и Message Queue Full повторяются без паузы.
- Текст сообщения формируется из отсутствующего поля, поэтому клиент получает пустое или неполное уведомление.
Для малого бизнеса в Беларуси рабочая схема выглядит так: вебхук сообщает о событии, очередь защищает от повторов и перегрузки, SMPP-шлюз принимает SMS, а DLR показывает результат доставки. Начать можно с одного статуса заказа и одного шаблона, затем добавить остальные этапы после проверки логов. Перед подключением подготовьте карту событий, таблицу сопоставления статусов и тестовый сценарий с повторной доставкой вебхука.
