Как настроить резервный SMS-шлюз для интернет-магазина?

Резервный SMS-шлюз помогает интернет-магазину продолжить отправку кодов и уведомлений, если основной сервис перестал отвечать. Для этого мало открыть аккаунт у второго провайдера: CRM или другая система отправки должна распознать сбой, выбрать резервный маршрут и не отправить клиенту два одинаковых сообщения. Ниже — схема для небольшого бизнеса в Беларуси: какие сообщения включить в резерв, что поручить специалисту по интеграции и как проверить работу до реальной аварии.

Дата публикации: 11.11.2026.

Какие сообщения стоит отправлять через резерв?

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

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

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

Как устроить переключение между основным и резервным шлюзами?

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

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

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

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

Как не отправить клиенту два одинаковых сообщения?

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

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

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

Как проверить резерв до сбоя?

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

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

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

Какие ошибки чаще всего мешают резервной отправке?

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

Первый шаг на сегодня: откройте настройки уведомлений и запишите одно событие, для которого магазину нужен резервный маршрут, например подтверждение нового заказа.