Чтобы отправлять покупателю SMS о выкупе и возврате товара Wildberries, интернет-магазину нужна связка из источника статусов, собственного обработчика событий и SMPP-шлюза. Сначала система получает изменение заказа из доступного интерфейса или внутреннего модуля, затем сопоставляет его с номером телефона, формирует текст и передаёт сообщение через SMPP. В статье разобраны схема интеграции, состав параметров, обработка DLR и типичные ошибки, из-за которых уведомления не доходят.
Как устроена схема SMS-уведомлений для заказа Wildberries?
Сам SMPP не подключает магазин к Wildberries. Это протокол обмена сообщениями между вашей системой и SMS-шлюзом. Источник статусов заказа находится отдельно: его предоставляет интеграционный модуль, личная система магазина или доступный для конкретного сценария интерфейс маркетплейса.
Рабочая схема выглядит так:
- Система магазина получает событие о заказе, выкупе, отмене или возврате.
- Обработчик проверяет статус и находит связанный номер телефона.
- Модуль уведомлений выбирает шаблон SMS.
- SMPP-клиент открывает соединение с шлюзом и отправляет PDU submit_sm.
- Шлюз возвращает submit_sm_resp с результатом приёма сообщения.
- Позже приходит DLR, по которому система фиксирует доставку или ошибку.
Для каждого события нужен отдельный внутренний идентификатор. Обычно это комбинация номера заказа, типа события и версии сообщения. Она не позволяет отправить два одинаковых уведомления, если источник повторно передал один и тот же статус.
Связку лучше разделить на два процесса. Первый принимает события и складывает их в очередь. Второй отправляет SMS через SMPP. Если шлюз временно недоступен, очередь сохранит задания, а основной модуль не остановит обработку заказов.
Какие статусы Wildberries стоит переводить в SMS?
Состав событий зависит от задачи магазина и того, какие статусы доступны в выбранном интерфейсе. Для уведомлений о выкупе и возврате достаточно начать с двух сценариев, затем добавить отмену или изменение заказа после проверки логики.
| Событие | Задача сообщения | Что передать в обработчик |
|---|---|---|
| Выкуп товара | Сообщить, что покупка завершена | Идентификатор заказа, дату события, номер телефона |
| Возврат товара | Уведомить об изменении результата заказа | Идентификатор заказа, тип возврата, время события |
| Отмена или изменение | Показать покупателю новый статус | Новый статус, заказ, причину при наличии |
Не отправляйте SMS на любое изменение записи. Сначала задайте список переходов, которые действительно требуют уведомления. Например, система может получить один и тот же статус несколько раз, а клиенту достаточно одного сообщения.
Для возврата полезно предусмотреть отдельный шаблон и отдельный код события. Материалы о настройке уведомлений о возврате помогают разобрать этот сценарий по шагам: SMS-уведомления о возврате.
Как подключить SMPP-шлюз к модулю магазина?
В конфигурации SMPP-клиента обычно нужны host, port, system_id, пароль, тип bind и параметры TON/NPI. Точные значения выдаёт поставщик шлюза. Их нельзя подставлять из примера: неправильный bind или порт приведёт к отказу ещё до отправки первой SMS.
Подключение удобно проверять по этапам:
- Открыть TCP-соединение с адресом и портом шлюза.
- Выполнить bind_transceiver, если система должна отправлять сообщения и принимать DLR.
- Проверить, что шлюз вернул bind_resp с успешным кодом.
- Отправить тестовую SMS на контрольный номер.
- Получить submit_sm_resp и сохранить message_id.
- Дождаться delivery receipt и связать его с исходным сообщением.
Клиенту нужен механизм enquire_link. Он поддерживает сессию и помогает заметить разрыв соединения. При потере связи приложение закрывает старую сессию, подключается заново и повторяет отправку только тех заданий, для которых нет подтверждённого результата.
Отдельно настройте ограничение скорости. Шлюз может принимать сообщения с определённой пропускной способностью, поэтому очередь должна выпускать SMS постепенно. Если отправлять все задания одновременно, приложение получит throttling, тайм-ауты или временные ошибки.
Для начала интеграции подготовьте небольшой тестовый контур: один тип события, один шаблон, несколько контрольных номеров и подробный журнал SMPP-команд. Такой подход быстрее показывает, где возник сбой: в статусе заказа, в обработчике или в транспортном соединении.
Как составить SMS о выкупе и возврате?
Текст должен объяснять событие без лишних деталей. В шаблон обычно включают название магазина, тип изменения, короткий идентификатор заказа и инструкцию, если покупателю нужно выполнить действие. Не вставляйте в SMS длинные технические идентификаторы или полный состав заказа.
| Элемент | Практическое правило |
|---|---|
| Отправитель | Используйте согласованное имя отправителя из настроек шлюза. |
| Идентификатор | Оставьте короткий номер заказа или его часть, если этого достаточно. |
| Кодировка | Заранее проверьте, как шлюз обрабатывает кириллицу и сегментацию длинных SMS. |
| Ссылка | Добавляйте её только при необходимости и проверяйте длину итогового сообщения. |
Для выкупа и возврата лучше хранить шаблоны в настройках, а не зашивать их в код. Тогда менеджер сможет изменить формулировку без выпуска новой версии интеграции. Перед отправкой система должна подставить значения и проверить, что обязательные поля заполнены.
Если SMS состоит из нескольких частей, приложение должно корректно передать параметры esm_class, data_coding и UDH, когда это требуется конкретным шлюзом. Ошибки в этих полях приводят к повреждённому тексту или разделению сообщения на части. Поэтому тестируйте короткий текст и длинный текст отдельно.
Как контролировать доставку SMS через DLR?
Ответ submit_sm_resp означает, что шлюз принял запрос. Он не подтверждает, что телефон получил SMS. Для контроля нужен delivery receipt, который приходит отдельным сообщением SMPP и содержит идентификатор, статус доставки и иногда код ошибки.
Система должна сохранять как минимум:
- внутренний идентификатор уведомления;
- message_id, который вернул шлюз;
- тип события заказа;
- время отправки;
- статус submit_sm_resp;
- последний статус DLR и текст ошибки.
Если SMS не дошла, сначала сравните message_id в журнале отправки и в DLR. Затем проверьте код ошибки, формат номера, кодировку и состояние SMPP-сессии. При повторной отправке используйте ограниченное число попыток: бесконечный retry создаёт дубли и усложняет разбор заказов.
Практическая диагностика DLR подробно разобрана в материале почему SMS не доходит до клиента. Для самого статуса доставки важно различать принятие сообщения шлюзом, передачу оператору и финальный результат на телефоне.
Какие ошибки чаще всего ломают интеграцию?
- Повторная отправка одного события. Источник статусов повторяет уведомление, а приложение не проверяет уникальность заказа и события.
- Неверная связь message_id. Система принимает DLR, но не может найти исходную SMS, потому что идентификатор шлюза не сохранён.
- Отправка до появления номера. Обработчик запускает SMS сразу после события, хотя телефон ещё не загрузился в локальную запись заказа.
- Неправильная кодировка. Русский текст проходит тест на коротком сообщении, но ломается на длинном.
- Игнорирование очереди. Модуль отправляет пачку сообщений напрямую в SMPP и получает временные отказы.
- Одинаковый шаблон для всех статусов. Покупатель не понимает, что произошло: выкуп, отмена или возврат требуют разных формулировок.
Отдельно проверьте журнал повторных подключений. В нём должны быть время разрыва, причина закрытия bind-сессии, результат reconnect и количество сообщений, оставшихся в очереди. Без этих записей техническая поддержка видит только жалобу «SMS не пришла», но не путь сообщения.
Для интернет-магазина с небольшим потоком достаточно простого обработчика событий и очереди в базе. При большом объёме лучше вынести отправку в отдельный сервис, который поддерживает SMPP-сессию, принимает DLR и ограничивает скорость. Схема автоматизации SMS-статусов интернет-магазина описана в материале как автоматизировать SMS-статусы доставки.
3 шага, которые можно сделать на этой неделе:
- Составить карту событий Wildberries и выбрать для теста выкуп и возврат.
- Проверить SMPP bind, кодировку, submit_sm_resp и приём DLR на контрольных номерах.
- Добавить очередь, защиту от дублей и журнал с message_id для каждого уведомления.
