Для автоматического SMS о поступлении оплаты через ЕРИП бизнесу нужны три компонента: источник события об оплате, промежуточный обработчик и SMPP-шлюз. Система получает подтверждение платежа, проверяет его и передаёт в шлюз команду на отправку сообщения. В статье разберём схему интеграции для малого бизнеса Беларуси, формат данных, статусы доставки и тестирование. Такой подход подходит интернет-магазину, сервису с регулярными платежами и компании, которая хочет уведомлять клиента сразу после оплаты.
Как связать оплату через ЕРИП и SMPP?
SMPP не подключается к ЕРИП напрямую по умолчанию. Протокол отвечает за обмен SMS между вашей программой и SMS-шлюзом, а сведения об оплате поступают из платёжной системы или программного интерфейса, который предоставляет ваш банк либо платёжный партнёр. Между ними нужен небольшой интеграционный слой.
Логика выглядит так:
- Покупатель оплачивает счёт через ЕРИП.
- Платёжная сторона передаёт системе уведомление об успешной оплате.
- Обработчик проверяет идентификатор заказа, сумму и состояние операции.
- Система формирует текст SMS.
- SMPP-клиент отправляет сообщение в SMS-шлюз.
- Шлюз возвращает идентификатор сообщения и передаёт отчёт о доставке через DLR.
Внутренний обработчик лучше отделить от сайта или кассовой программы. Тогда временная ошибка в одном компоненте не остановит весь процесс. Для каждого события сохраните внутренний идентификатор заказа и идентификатор SMS, который вернул SMPP-шлюз. Это позволит сопоставить оплату, команду на отправку и результат доставки.
Если требуется разобраться именно с подключением уведомлений об оплате через ЕРИП к нескольким каналам, полезно изучить материал о подключении уведомлений об оплате через ЕРИП к SMS и Viber. Для проекта, где нужен только SMPP, из этой схемы оставляют источник платежного события и SMS-часть.
Какие данные передавать в SMS после оплаты?
Сообщение должно подтверждать конкретное действие и помогать клиенту понять, к чему относится платёж. В минимальном варианте достаточно статуса, номера заказа и суммы в BYN. Если бизнес не хочет показывать сумму в SMS, можно оставить только номер заказа и факт зачисления.
Пример шаблона:
«Оплата по заказу №4815 получена. Сумма: 42 BYN. Статус заказа: в обработке».
Номер заказа берите из собственной системы, а не из произвольного текста уведомления. Сумму приводите к тому формату, который использует бухгалтерская или торговая программа. Отдельно обработайте ситуацию, когда платёж пришёл повторно: повторное событие не должно создавать второе одинаковое SMS.
| Событие | Действие обработчика | Пример сообщения |
|---|---|---|
| Оплата подтверждена | Создать одну задачу на отправку | «Заказ №4815 оплачен. Сумма: 42 BYN» |
| Платёж ожидает подтверждения | Не отправлять сообщение об успешной оплате | «Платёж по заказу №4815 проверяется» |
| Повторное уведомление о той же оплате | Проверить уникальность события и пропустить дубль | Повторное SMS не создаётся |
| Ошибка при отправке в SMPP | Записать ошибку и повторить попытку по правилам очереди | Клиенту не отправляется неподтверждённый статус |
Как настроить SMPP-клиент для уведомлений?
Для работы по SMPP нужен клиент, который поддерживает постоянное соединение с SMS-шлюзом. В настройках указывают адрес и порт шлюза, логин, пароль, системный идентификатор, параметры bind и ограничения скорости. Точные значения выдаёт поставщик SMS-сервиса.
Приложение должно уметь выполнять несколько операций:
- устанавливать соединение и повторно подключаться после разрыва;
- передавать текст и номер получателя в submit_sm;
- сохранять message_id из ответа шлюза;
- принимать delivery receipt;
- ограничивать число параллельных отправок;
- писать в журнал технические ошибки и время операции.
При кириллическом тексте отдельно проверьте кодировку и длину сообщения. В документации некоторых SMPP-шлюзов указано, что UTF-8 при отправке SMS не используется, поэтому параметр data_coding и способ передачи Unicode нужно согласовать с провайдером. Неверная настройка превращает текст в набор символов или приводит к отклонению сообщения.
Для небольшого проекта достаточно отдельного фонового процесса: он забирает задания из очереди и передаёт их в SMPP. Сайт при этом только создаёт задачу после подтверждения платежа. Такой вариант проще тестировать и контролировать, чем отправку SMS прямо внутри запроса, который принимает платёжное уведомление.
Как проверять оплату, отправку и доставку?
Тестирование разделите на три независимых этапа. Сначала проверьте, что система получает событие от платёжного источника и правильно связывает его с заказом. Затем отправьте тестовое SMS через SMPP и убедитесь, что шлюз вернул message_id. После этого проверьте DLR: один статус показывает принятие сообщения шлюзом, другой отражает результат доставки оператором.
Не считайте SMS доставленным только потому, что SMPP-клиент получил положительный ответ на submit_sm. Это подтверждает приём команды, но не факт появления сообщения на телефоне. Для разбора статусов пригодится материал о причинах недоставки SMS и разборе DLR в SMPP.
В журнале интеграции храните техническую цепочку:
- идентификатор заказа;
- идентификатор платёжного события;
- время получения подтверждения;
- время постановки SMS в очередь;
- ответ SMPP-шлюза;
- message_id;
- последний полученный статус доставки.
Для проверки сценария подготовьте отдельные случаи: успешная оплата, повторное уведомление, неизвестный заказ, временно недоступный шлюз и некорректный номер. Отправляйте тестовые сообщения на номера, которыми вы вправе пользоваться для проверки, и фиксируйте результат каждого шага.
Какие ошибки чаще всего ломают сценарий «оплата получена»?
- SMS отправляется до подтверждения платежа. Система реагирует на создание счёта, хотя ЕРИП ещё не подтвердил оплату. Отправляйте сообщение только после события об успешном зачислении.
- Повторная обработка одного события. При повторной доставке уведомления создаются дубли. Добавьте проверку уникального идентификатора платежа или заказа.
- Отсутствует очередь. Если SMPP-шлюз временно недоступен, сайт теряет задачу. Сохраняйте сообщение до получения результата отправки.
- Нет контроля DLR. Статус submit_sm принимают за доставку. Отдельно принимайте и анализируйте delivery receipt.
- Неправильная кодировка. Кириллица отображается некорректно из-за неверного data_coding или неподходящего формата поля.
- Слишком тесная связь с сайтом. Платёжная страница ждёт ответа SMS-шлюза. Отправку лучше выполнять отдельным процессом после записи события в очередь.
Перед подключением уточните у поставщика SMPP технические параметры, поддержку DLR, правила повторной отправки и ограничения скорости. Если готового клиента нет, интеграцию можно построить через HTTP-сервис или библиотеку, но при большом объёме сообщений постоянное SMPP-соединение обычно требует отдельного контроля состояния и очереди.
3 шага, которые можно сделать на этой неделе:
- Описать, откуда система получает подтверждение оплаты через ЕРИП и какое поле связывает его с заказом.
- Собрать тестовый SMPP-клиент с журналом соединения, message_id и DLR.
- Проверить четыре сценария: успешная оплата, дубль, ошибка шлюза и недоставленное SMS.
