SMS после оплаты: как подтвердить платеж и сообщить следующий шаг

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

Чтобы уведомление действительно помогало, его нельзя отправлять просто по факту перехода пользователя на страницу «Спасибо». Источником должен быть подтверждённый статус платёжной системы или учётной системы компании. Тогда SMS становится частью бизнес-процесса: сообщает достоверный результат, не дублируется и ведёт к понятному следующему действию.

Что именно подтверждает SMS

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

Перед настройкой определите, какой статус получает клиент:

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

Для каждого статуса нужен отдельный текст и отдельное условие отправки. Фраза «Спасибо за оплату» не подходит, если система пока видит только созданную платёжную сессию.

Уведомление об оплате и электронный чек — не одно и то же

Сервисное SMS может сообщить сумму, номер заказа и дальнейший этап, но само по себе оно не становится кассовым чеком. Электронный чек формирует контрольно-кассовая техника: он содержит обязательные реквизиты или ссылку на документ. ФНС России отдельно разъясняет порядок направления электронного кассового чека.

На практике удобно разделить два события:

1. Сразу после подтверждения платежа отправить короткий статус заказа.
2. После ответа онлайн-кассы направить ссылку на электронный чек, если это предусмотрено процессом компании.

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

Какие события передавать в сценарий

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

У каждого события должны быть определены:

• источник достоверного статуса;
• уникальный идентификатор платежа;
• связанный заказ, счёт или договор;
• получатель сообщения;
• допустимое время отправки;
• стоп-условие;
• действие при задержке или повторном событии.

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

Как выглядит техническая цепочка

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

Рабочая последовательность выглядит так:

1. Платёжный провайдер присылает callback или webhook.
2. Система проверяет подпись запроса и сопоставляет платёж с заказом.
3. Новый статус записывается в базу.
4. Проверяется, не обрабатывалось ли это событие раньше.
5. Формируется текст с данными конкретного заказа.
6. Сообщение передаётся в QUICKTEL через HTTP API.
7. Идентификатор отправки сохраняется рядом с платежом.
8. Статус доставки возвращается в CRM или систему заказов.

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

Какие данные включить в сообщение

Клиент должен узнать свою операцию, но SMS не должно раскрывать лишнюю платёжную информацию. Как правило, достаточно четырёх элементов:

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

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

Сумма полезна, когда она помогает отличить одну операцию от другой. Но в некоторых сервисах её лучше не показывать на экране заблокированного телефона. Решение зависит от чувствительности данных и ожиданий аудитории.

Примеры SMS после оплаты

Для успешной покупки:

QUICKTEL SHOP: оплата заказа 9241 на 3 480 ₽ получена. Передаём заказ в сборку. Статус: example.ru/q/9241

Для платежа, который ещё обрабатывается:

Платёж по заказу 9241 обрабатывается. Повторно оплачивать не нужно. Сообщим результат отдельным SMS.

Для частичной оплаты:

По счёту 7815 получено 25 000 ₽. Остаток — 10 000 ₽. Детали и способ доплаты доступны в личном кабинете.

Для неуспешной операции:

Оплата заказа 9241 не завершена. Заказ сохранён. Попробуйте другой способ на защищённой странице: example.ru/q/9241

Для возврата:

Возврат по заказу 9241 оформлен на 3 480 ₽. Зачисление отобразится по правилам вашего банка.

Для электронного чека:

Чек по заказу 9241 сформирован: example.ru/receipt/9241

В каждом примере есть один статус и один ожидаемый следующий шаг. Рекламное предложение после подтверждения оплаты лучше не добавлять: оно мешает быстро найти главную информацию и смешивает сервисную коммуникацию с продвижением.

Как не перепутать подтверждение с OTP

OTP подтверждает действие пользователя до его завершения: вход, изменение данных или проведение операции. SMS после оплаты сообщает результат уже выполненного процесса. Это разные сценарии, даже если оба связаны с платежами.

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

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

Типичные ошибки запуска

Самая опасная ошибка — отправлять подтверждение раньше, чем получен окончательный статус. Но есть и другие проблемы:

• событие запускается при открытии страницы «Спасибо», а не по ответу платёжной системы;
• повторный webhook создаёт второе или третье SMS;
• номер заказа не совпадает с номером в личном кабинете;
• сообщение об ошибке не объясняет, сохранён ли заказ;
• ссылка ведёт на главную страницу вместо нужного платежа;
• напоминание продолжает отправляться после оплаты;
• сервисное уведомление содержит рекламный блок;
• компания не сохраняет идентификатор SMS и не видит результат доставки.

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

Что измерять после запуска

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

Полезно отслеживать:

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

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

Как запустить сценарий через QUICKTEL

Для разовой отправки можно использовать личный кабинет QUICKTEL. Автоматическое подтверждение оплаты лучше подключать по API из платёжного модуля, CRM, 1С или системы заказов.

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

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

Настройте SMS после оплаты в QUICKTEL. Подключите отправку из CRM, 1С, платёжного модуля или внутренней системы через HTTP API. Зарегистрироваться →