Ссылка на оплату отправлена. Что делать, если подтверждение не пришло

Сначала определите, откуда известна оплата

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

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

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

Как автоматически проверить, что клиент оплатил

Квалли должен получить подтверждённый статус заказа из платёжной системы или CRM. Сообщение клиента «Я оплатил» и отсутствие уведомления не доказывают ни оплату, ни долг.

1. Свяжите заказ с платежом: сохраните у себя ID заказа и ID платежа. Для примера заказ DEMO-104, сумма 1 500 ₽.
2. Настройте обработчик уведомлений платёжной системы. Например, при уведомлении ЮKassa сервер запрашивает текущий статус платежа и сверяет заказ, сумму и валюту. Это работа интеграции, а не текст инструкции бота.
3. Только после подтверждения успешной оплаты отправьте в ловушку Квалли событие с ID заказа и статусом paid. Повтор одного уведомления не должен повторно запускать подтверждение.
4. В ловушке откройте «Шаг 3: Отправка первого сообщения → Действия при получении вторичных вебхуков». Сопоставьте «ID записи в заявке» и «ID записи в событии». Добавьте событие с условием по подтверждённому статусу.
5. Выберите «Инструкция ИИ-сотруднику» и задайте действие: оплату подтвердить, повторно платить не просить, сообщить порядок подготовки к визиту.

Документация ЮKassa объясняет проверку подлинности и получение актуального статуса. Если CRM уже передаёт проверенную оплату, используйте её событие; прямое подключение к банку не требуется.

{"order_id":"DEMO-104","payment_status":"paid","amount":"1500.00","currency":"RUB"}

Свяжите ожидание с конкретным заказом

1. Откройте сохранённую webhook-ловушку: «Ловушки заявок → ваша ловушка → Шаг 3: Отправка первого сообщения».
2. В блоке «Если ожидаемый вебхук не пришёл» нажмите «Добавить правило ожидания». Назовите правило «Нет подтверждения оплаты».
3. В «Первый вебхук (A)» задайте условие status = created, в «Ожидаемый вебхук (B)» — payment_status = paid. Это поля нашего учебного примера; возьмите свои из передаваемых событий.
4. В «Ключ сопоставления» заполните «Путь в A» и «Путь в B»: order_id в обоих. Для «Ждать B» в нашем примере выбираем «1 ч». Телефон не заменяет номер заказа.
5. В «Сообщение клиенту» напишите нейтральный текст ниже. В «Проверка на примере» вставьте A и B в соответствующие поля JSON, нажмите «Проверить». После успешной сверки сохраните само правило кнопкой «Сохранить» внутри его блока.

{"order_id":"DEMO-104","status":"created"}

{"order_id":"DEMO-104","payment_status":"paid"}

Эти короткие образцы показывают условие и ключ. В рабочем событии также должны быть данные для связи с нужным диалогом. Сначала проверьте передачу события оплаты, описанную ниже, затем включайте напоминание.

Сообщение, которое не заставляет платить дважды

Подойдёт такая формулировка: «Подскажите, получилось завершить оплату заказа? Если уже оплатили, повторять платёж не нужно. Если возникла ошибка, помогу передать вопрос администратору».

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

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

Испытайте четыре последовательности событий

Сначала отправьте учебное A, затем B того же заказа до окончания ожидания: напоминание не должно появиться. Во втором тесте отправьте только A и проверьте сообщение после выбранного срока.

В третьем тесте используйте два заказа одного клиента: оплата второго не должна закрыть ожидание первого. В четвёртом проверьте неправильный ID — система не должна считать его подтверждением нужной оплаты.

Отдельно учитывайте порядок событий: полученное раньше A событие B не отменяет будущее ожидание. Проверьте реальный порядок доставки в вашей интеграции до запуска. В макете показана схема настройки, реальные платежи здесь не проводятся.

Что происходит с ожиданием

Вопросы перед запуском