Чат-бот для оплаты выставляет счёт или ссылку платёжного провайдера и сообщает статус после сверки с заказом. Покупатель вводит данные карты на защищённой странице провайдера. До подтверждения платежа бот показывает ожидание, а расхождения передаёт сотруднику.
Роль бота
Чат-бот для оплаты создаёт заказ, выдаёт счёт либо защищённую ссылку платёжного провайдера, получает подтверждённый статус и сообщает человеку о расхождении. Реквизиты карты остаются у провайдера.
Покупателю важно быстро понять сумму, назначение платежа и состояние заказа. Бот может собрать выбор услуги, подтвердить состав заказа и открыть страницу оплаты у платёжного провайдера. В переписке он показывает только ссылку и справочную информацию. Поля карты, защитный код и другие платёжные реквизиты вводятся на странице провайдера; запрос этих данных в чате недопустим.
После перехода по ссылке пользователь может закрыть окно, а платёж завершится позже. Поэтому сообщение «ссылка отправлена» означает только начало оплаты. Статус «оплачено» появляется после уведомления от провайдера и сверки с заказом. Если событие задержалось, бот сообщает о проверке статуса и сохраняет контакт для сотрудника. Обещание немедленной выдачи услуги до подтверждения создаст конфликт с клиентом.
Сценарий применим к разным услугам и заказам. Для отраслевого случая с квитанциями есть отдельный разбор оплаты коммунальных услуг. Базовый выбор канала и функций изложен в обзоре чат-ботов для бизнеса. Здесь центральная задача — провести заказ через счёт, проверку статуса и обработку ошибки.
Кнопка оплаты должна показывать ожидаемый переход на страницу провайдера. Покупателю полезно заранее видеть, кому поступят деньги и где появится итоговый чек.
Маршрут платежа
Перед запуском нарисуйте путь данных: диалог создаёт черновик заказа, учётная система выдаёт идентификатор, провайдер получает сумму и описание, затем отправляет событие о платеже. Бот читает подтверждённый результат из вашей системы. Сумму для платёжной страницы формирует сервер по заказу; значение из текста переписки нельзя принимать как единственный источник цены.
| Событие | Действие бота | Проверка системы |
|---|---|---|
| Заказ создан | Показывает состав и сумму | У заказа есть уникальный номер |
| Ссылка выдана | Открывает страницу провайдера | Сумма связана с номером |
| Платёж подтверждён | Сообщает об оплате | Совпадают заказ, сумма и статус |
| Ошибка или возврат | Передаёт вопрос сотруднику | История события сохранена |
Для счёта юридическому лицу маршрут может идти через учётную систему и ручное подтверждение бухгалтерии. Для онлайн-оплаты провайдер сообщает результат через техническое уведомление. В обоих случаях бот лишь показывает состояние, полученное из надёжного источника. События логируются с временем и идентификатором заказа, чтобы сотрудник восстановил последовательность без догадок.
Если связь с CRM прерывается, новая ссылка может создать дублирующий заказ. Поэтому повторное нажатие кнопки «Оплатить» проверяет наличие активного счёта. Клиенту показывают его текущую ссылку или предлагают обновить заказ после явного подтверждения. Такая логика особенно важна в доставке, где сумма меняется вместе с составом корзины.
Для каждого изменения суммы сохраняйте версию заказа. Тогда поступившее событие можно сопоставить с той суммой, которую клиент видел перед переходом к оплате.
Статус и ошибки
Подлинность уведомления проверяйте способом из документации выбранного провайдера, например повторным запросом статуса платежа по его идентификатору. Повторная доставка события должна исключать повторную выдачу товара или услуги. Сначала система отмечает уникальное событие, затем обновляет заказ и только после этого отправляет сообщение покупателю. Бот способен составить понятный текст ответа, но менять платёжный статус ему права давать нельзя.
- Сверяйте идентификатор заказа, сумму, валюту и подтверждённый статус.
- Разделяйте «ожидает оплаты», «оплачен», «отменён» и «нужна проверка».
- Повторные уведомления сохраняйте в журнале без повторного исполнения заказа.
- Расхождения передавайте сотруднику вместе с историей заказа и события.
Условный пример: клиент оплатил одну услугу, а бот получил подтверждение с другой суммой после изменения заказа. Автоматическая выдача здесь остановится. Сотрудник сравнит сумму на момент создания платёжной ссылки, текущий заказ и запись провайдера. Покупателю достаточно нейтрального сообщения о проверке; внутренние детали интеграции в переписке излишни.
При проектировании чат-бота для оплаты и поддержки клиента заранее определите, кто разбирает расхождения и где видит журнал. Когда есть ответственный, ошибка становится управляемым обращением, с ясным маршрутом к решению.
Сотруднику нужен понятный способ вручную проверить спорный заказ в кабинете провайдера. Бот сообщает клиенту только итог после этой сверки.
Интеграция систем
Для подключения обычно нужны бот в выбранном канале, система заказов и платёжный провайдер. В Битрикс24 или amoCRM можно хранить карточку сделки, а 1С использовать для счёта и учёта. Конкретная схема зависит от того, где у компании хранится истинная сумма заказа. Запишите эту систему владельцем данных и запретите независимое редактирование суммы в нескольких местах.
- Опишите заказ и статусы, которые видит покупатель и сотрудник.
- Настройте создание счёта или ссылки у платёжного провайдера по уникальному заказу.
- Проверьте уведомление провайдера и сопоставьте его с заказом.
- Протестируйте успешный платёж, отмену, повторное событие и расхождение суммы.
Тестируйте на разрешённой провайдером среде и по его актуальной документации. Подготовьте заказы с разной суммой и проверьте, что ссылка ведёт к нужному заказу. Откройте один и тот же диалог с разных устройств, повторите нажатие кнопки и просмотрите журнал. Для возврата или отмены отдельный статус должен отражаться и в учётной системе, и в сообщении клиенту.
Сведения о платеже относятся к чувствительному процессу. Ограничьте доступ сотрудников к журналу по рабочей роли, а в сообщении клиенту показывайте лишь понятный итог и номер заказа. Если человек прислал реквизиты карты в чат по собственной инициативе, настройте обработку таких сообщений по внутренним правилам безопасности и направьте его на защищённую страницу оплаты.
Если заказ меняется после выдачи ссылки, прежний платёжный сценарий следует закрыть по правилам провайдера. Новая ссылка должна отражать согласованный состав заказа.
Оператору важно видеть историю спорного платежа целиком. Его обычный способ проверки покажет, каких сведений ещё нет в карточке заказа.
Как сейчас ваша команда узнаёт о спорном платеже?
Проверка перед запуском
Приёмка начинается с истории заказа. Для каждого тестового диалога проследите, какая сумма была показана, какая ссылка создана, какое событие пришло и когда бот сообщил об оплате. Если событие пришло раньше обновления CRM, система должна дождаться сверки. Если уведомление провайдера отсутствует, бот сохраняет ожидание и предлагает клиенту проверить статус позже через безопасный канал.
Для оценки пилота фиксируйте долю заказов, где подтверждённый платёж автоматически связан с правильным заказом, и время разбора исключений сотрудником. Дополнительно считайте число ложных сообщений об оплате: цель здесь нулевая. Изменения сценария принимайте только после проверки на отмене, повторном уведомлении и расхождении суммы. Красивый диалог говорит лишь о части надёжности платёжного контура.
Возьмите один вид услуги с ясной суммой и проведите его от заказа до подтверждения у провайдера. Сначала разберите случаи задержанного события и повторного нажатия кнопки, затем подключайте другие сценарии.
Обучите операторов видеть отличие между выставленным счётом и поступившим платежом. В карточке обращения им нужны номер заказа, фактический статус и действие для клиента. Когда эти поля согласованы, бот снимает рутинные вопросы о состоянии оплаты, а спорные случаи быстро доходят до человека.
Проверку удобнее завершать вместе с оператором поддержки. Его вопросы выявляют места, где журнал событий понятен разработчику, но неудобен в рабочей смене.