Как учитывать повторные и неуспешные платежи на сайте

Покупатель может открыть оплату дважды, закрыть окно или получить отказ банка. Если сайт создаёт новый заказ на каждое нажатие, команда видит несколько одинаковых покупок и не понимает, какую из них исполнять. Поэтому повторные и неуспешные платежи на сайте нужно учитывать отдельно от самого заказа. Если хотите проверить свой путь оплаты, начните с БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ.
В A3 Studio для платёжного сценария описывают, что остаётся одним заказом, что считается новой попыткой и при каком подтверждении начинается исполнение.

Повторные и неуспешные платежи: разделите заказ и попытки

Заказ описывает, что клиент хочет получить: состав, цену, контакт и условия. Платёжная попытка описывает отдельное действие по оплате этого заказа. У одного заказа может быть несколько попыток, но успешное исполнение не должно запускаться несколько раз из-за повторного уведомления или обновления страницы.
Храните связь каждой попытки с номером заказа, суммой и статусом платёжного сервиса. Службе поддержки нужно видеть не только итог «оплачен/не оплачен», но и последовательность попыток. Иначе невозможно объяснить, почему покупатель видел ошибку, а позднее получил подтверждение.
Вопрос к вам: может ли покупатель сегодня повторить оплату, не заполняя заказ заново? Если нет, велик риск потерять выбранные товары или создать дубли при второй попытке.
Не считайте неуспешную попытку отказом от покупки. Клиент мог закрыть вкладку, ошибиться в данных или столкнуться с временным сбоем. Письмо и интерфейс должны предлагать следующий шаг без давления и ложного утверждения, что деньги не списаны, пока статус ещё уточняется.

Что показать покупателю при отказе и ожидании

При подтверждённой отмене можно написать: «Оплата не завершена. Заказ сохранён, попробуйте ещё раз или выберите другой способ». При промежуточном состоянии лучше сообщить: «Проверяем статус. Не оплачивайте повторно до завершения проверки». При успешном платеже показывайте подтверждение и дальнейшие действия.
Подход «любая ошибка ведёт к новой оплате». Плюс: интерфейс прост для разработки. Главный риск: клиент повторяет операцию, которая ещё обрабатывается, и может получить два списания. Подход «сначала проверить статус». Плюс: снижает путаницу между заказом и попыткой. Главный риск: нужно продумать ожидание и поддержку, иначе человек останется без ответа.
Для каждого состояния определите доступность кнопки повтора. Если результат первой попытки неизвестен, повтор должен быть заблокирован или сопровождаться проверкой. Если платёж отменён окончательно, можно дать безопасный способ повторить попытку с тем же заказом.
Таблица показывает, как связывать исход платежа с заказом.
Статус попыткиСтатус заказаДействие на сайтеДействие команды
Ожидает подтвержденияОжидает оплатуПоказать проверку, без новой оплатыСледить за статусом
УспешнаОплаченПодтверждение и номер заказаНачать исполнение один раз
ОтмененаНе оплаченПредложить повтор или другой способНе исполнять заказ
Неизвестен из-за сбоя связиТребует сверкиДать контакт поддержкиПроверить статус у сервиса
Лайфхак: помечайте платёжные попытки порядковым номером внутри заказа и сохраняйте время каждой. Менеджеру будет проще отвечать на вопрос «какое из двух уведомлений относится к моей покупке».

Как не получить дубли из-за повторных событий

Платёжные сервисы могут повторно передавать уведомление, если первая доставка не была подтверждена. Приложение должно распознавать уже обработанное событие и не создавать вторую продажу, письмо или задачу на отгрузку. Такая защита проверяется тестом повторной доставки, а не только обычной покупкой.
Не удаляйте неуспешные попытки сразу после повтора. Их история помогает разбирать жалобы, искать ошибки и оценивать, на каком этапе люди останавливаются. При этом журнал не должен хранить лишние чувствительные платёжные данные. Достаточно идентификаторов, статусов, времени и технических сообщений, нужных для поддержки.
Сравните аналитику сайта и реальные статусы. Нажатие кнопки «Оплатить» показывает намерение, а подтверждённый платёж показывает результат. Если в отчёте их смешать, можно принять рост неуспешных попыток за рост продаж.
Вопрос к вам: сколько заказов за месяц имеют больше одной попытки оплаты и сколько из них завершаются успешно? Если данные не собираются, это повод добавить понятный журнал прежде, чем искать проблему в рекламе.

Проверьте учёт на тестовых сценариях

Шаг 1. Создайте один заказ

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

Шаг 2. Получите разные исходы

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

Шаг 3. Повторите уведомление

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

Шаг 4. Смоделируйте отсутствие ответа

Отключение связи или задержка уведомления не должны превращаться в ложное «успешно». Покупатель получает сообщение о проверке, а команда видит задачу на сверку с платёжным сервисом.
Пример расчёта (условные цифры): за месяц создано 300 заказов и зафиксировано 330 попыток оплаты. Разница в 30 попыток не означает 30 дополнительных покупок. Чтобы оценить результат, считайте уникальные оплаченные заказы, а отказы и повторы анализируйте отдельно. Это пример счёта, а не рыночная статистика.
В A3 Studio такую логику закладывают в требования к интеграции, чтобы в CRM, аналитике и уведомлениях один заказ не превращался в несколько продаж.
Платёжный путь связан с текстами интерфейса, дизайном, скоростью, аналитикой, CRM и поддержкой. Если система не различает заказ и попытку, ошибка распространяется по всем этим частям. A3 Studio проверяет общую цепочку, а не только работу платёжной формы.

Что ещё связано

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

Заметка эксперта

Один заказ может иметь несколько попыток оплаты, но только один подтверждённый итог для исполнения. Разделение этих сущностей помогает избежать дублей, объяснять ошибки клиенту и считать реальные продажи в аналитике.
Сможет ли ваша команда отличить повторную попытку от второго заказа?
Напишите, на каком этапе ваш сайт: A3 Studio
Обсудить сайт