Покупатель прошёл весь путь: выбрал товар, заполнил данные, нажал «Оплатить» — и застрял на экране «Платёж не прошёл». В большинстве случаев это не значит, что человек передумал или у него нет денег. Он хотел купить, но что-то оборвало сценарий: банк потребовал подтверждение, истёк таймаут, слетело 3-D Secure. И вот здесь магазины теряют деньги на пустом месте — просто потому, что не помогают вернуться к оплате.
В этой статье разберём, как в магазине на 1С-Битрикс мягко возвращать покупателя после неудачной оплаты: как устроен обрыв платежа технически, что показать на экране ошибки, как дать повторную оплату того же заказа, настроить догоняющие письма и не наделать ошибок с чеком по 54-ФЗ. Многое из этого — тонкая работа с логикой заказа и интеграциями, и её мы закрываем услугой автоматизации продаж и склада на 1С.
Коротко
- Сорванный платёж — чаще всего обрыв сценария (3-D Secure, таймаут, лимит банка), а не отказ покупателя от покупки.
- Заказ должен сохраняться, а экран ошибки — сразу предлагать повторить оплату или выбрать другой способ.
- Дайте прямую ссылку на повторную оплату того же заказа и одно-два спокойных напоминания.
- Чек по 54-ФЗ пробивается только при фактической оплате — на сорванном платеже чека быть не должно.
Почему неудачная оплата — это не потерянный клиент
Заказ, оформленный до этапа оплаты, — это покупатель с максимально горячим намерением. Он уже прошёл весь путь, выбрал доставку, ввёл данные. Если на последнем шаге платёж срывается, было бы ошибкой считать этого человека «ушедшим». В отличие от брошенной корзины, где покупатель ещё сомневался, здесь он принял решение и попытался за него заплатить.
Именно поэтому возврат после неудачной оплаты обычно даёт более высокую конверсию, чем работа с корзиной. Человек не передумал — ему просто помешал технический или банковский сбой. Задача магазина — не «дожать» продажей, а убрать препятствие: сохранить заказ, показать понятный экран и дать простой способ доплатить. Это отдельный сценарий работы с брошенным намерением — рядом с ним стоит история про безопасные REST-вебхуки в Битрикс, через которые платёжные сервисы сообщают магазину результат операции.
Из-за чего платёж срывается на самом деле
Чтобы возвращать покупателя, надо понимать, где именно рвётся оплата. Причины делятся на несколько групп, и деньги на карте — далеко не главная.
| Причина | Что произошло | Возвращаем? |
|---|---|---|
| 3-D Secure | Клиент не ввёл код банка, закрыл вкладку | Почти всегда |
| Таймаут / обрыв | Потеря связи, долгий ответ шлюза | Да |
| Лимит банка | Ограничение на онлайн-операции | Часто, другим способом |
| Антифрод шлюза | Платёж отклонён по правилам риска | Иногда |
| Недостаток средств | На карте не хватает денег | Позже или иначе |
Как видно, подавляющее большинство отказов — это обрыв сценария, а не осознанный отказ от покупки. Значит, у магазина есть реальный рычаг: вернуть человека к той же оплате или предложить обходной путь. Поэтому первое, что нужно сделать, — научиться отличать эти ситуации и не хоронить заказ после первой же ошибки.
Что происходит в 1С-Битрикс при обрыве оплаты
В модуле «Интернет-магазин» жизненный цикл платежа устроен так: покупатель оформляет заказ, тот получает статус и флаг оплаты PAID = N, затем покупатель уходит на страницу платёжной системы. Дальше возможны три исхода: успех (шлюз присылает подтверждение, заказ помечается оплаченным), явный отказ или тишина — покупатель просто не вернулся.
Проблема в том, что «по умолчанию» все неоплаченные заказы выглядят одинаково. Чтобы работать с возвратом, брошенный платёж нужно отделять: например, отдельным свойством заказа или статусом «ожидает повторной оплаты», который выставляется, когда покупатель был на шлюзе, но подтверждения не пришло. Результат оплаты приходит от платёжного сервиса на служебный URL магазина, и тут важна надёжность обработки — как её строить, мы разбираем в материале про вебхуки и их безопасность.
Экран ошибки, который возвращает к попытке
Стандартный экран «Ваш платёж не прошёл» — тупик. Он сообщает о проблеме, но не предлагает выхода, и покупатель уходит. Правильный экран ошибки оплаты решает обратную задачу: он спокойно объясняет, что заказ сохранён, и сразу даёт действия.
- Заказ сохранён. Первая мысль покупателя — «мне теперь всё заново оформлять?». Снимите её сразу: заказ на месте, ничего не потеряно.
- Кнопка повторить оплату. Главное действие — вернуться к той же оплате того же заказа, а не создавать новый.
- Альтернативный способ. Рядом — «оплатить через СБП» или «оплата при получении», если карта не проходит.
- Понятная причина без паники. Без технических кодов: «банк не подтвердил операцию, попробуйте ещё раз или другой картой».
Тон здесь важнее оформления. Экран не должен обвинять покупателя или пугать. Его задача — убрать растерянность и дать один очевидный следующий шаг.
Повторная оплата того же заказа по прямой ссылке
Ключевая механика возврата — возможность доплатить существующий заказ, не оформляя его заново. В 1С-Битрикс у каждого заказа есть страница оплаты, куда можно вернуться по прямой ссылке. Эту ссылку и нужно давать покупателю: на экране ошибки, в письме, в SMS.
Как это должно работать:
- Заказ живёт. После сорванной оплаты заказ не отменяется автоматически, а ждёт повторной попытки заданное время.
- Прямая ссылка на оплату. Покупатель по ссылке попадает сразу на выбор способа оплаты своего заказа.
- Актуальная сумма и состав. Ссылка ведёт на тот же заказ с той же корзиной, ценой и скидками.
- Ограничение по времени. Резерв товара и ссылка живут разумный срок, после чего заказ уходит в отмену.
Резервирование товара под неоплаченный заказ и его снятие по таймауту — это уже логика склада, которая тесно связана с 1С. Чтобы остатки не «подвисали» под брошенными платежами, эту механику настраивают вместе с обменом — задача из области автоматизации на 1С.
Альтернативные способы оплаты после отказа
Если карта не прошла дважды, упорно предлагать её в третий раз бессмысленно. Гораздо эффективнее дать покупателю другой путь. Часто человек готов заплатить, просто не этим способом.
- СБП. Оплата по QR или ссылке через приложение банка обходит часть проблем с 3-D Secure и лимитами по карте.
- Другая карта. Прямое предложение «попробуйте другую карту» — если проблема в конкретном банке.
- Оплата при получении. Для тех, кто не хочет платить онлайн после сбоя, — наложенный платёж или оплата курьеру.
- Счёт для юрлица. В B2B — выставление счёта на оплату по реквизитам вместо карты.
Догоняющие письма и SMS без давления
Не все возвращаются к оплате сразу. Кто-то отвлёкся, у кого-то сел телефон на шаге 3-D Secure. Таких покупателей возвращает цепочка напоминаний — но спокойная, а не в стиле «осталось 10 минут!».
Рабочая схема касаний выглядит так:
- Первое письмо — быстро. Через 10–30 минут: «Заказ №… сохранён, оплатить можно по ссылке». Прямая ссылка на оплату.
- Второе — на следующий день. Напоминание с предложением альтернативного способа оплаты, если первое осталось без реакции.
- Третье — по желанию. Через день-два, последнее касание, дальше — отмена заказа и снятие резерва.
Технически такие цепочки строят на событиях заказа: смена статуса запускает отправку письма или SMS. Надёжная доставка этих уведомлений зависит от инфраструктуры почты и очередей — тема, которую мы затрагивали в статье про хостинг и инфраструктуру BitrixVM. И главное — всегда честный текст без манипулятивной срочности.
Кассовый чек и 54-ФЗ: когда пробивать
Здесь магазины часто ошибаются. По 54-ФЗ кассовый чек формируется в момент фактического расчёта. Нет оплаты — нет расчёта — нет чека. Поэтому онлайн-касса (модуль «Кассовые чеки» или чекование на стороне платёжного сервиса) должна реагировать на подтверждённую оплату, а не на факт создания заказа.
Что важно не перепутать:
- Сорванный платёж — без чека. Если оплата не состоялась, чек пробивать не нужно и нельзя.
- Чек по факту оплаты. Триггер чека — успешное подтверждение от платёжной системы, а не оформление заказа.
- Повторная оплата — один чек. Сколько бы попыток ни было, чек пробивается один раз на реально прошедшую оплату.
- Возврат — отдельный чек. Если деньги вернули, это отдельная фискальная операция.
Правильная привязка чека к статусу оплаты — часть корректной интеграции кассы, учёта и 1С. Ошибки тут приводят к лишним или недостающим чекам, что уже вопрос к бухгалтерии, а не только к сайту.
Статусы заказа и автоматизация возврата
Чтобы всё это работало без ручного труда, нужна аккуратная модель статусов. Брошенный платёж должен быть отдельным, машинно-различимым состоянием заказа, к которому привязана автоматика: письма, снятие резерва, задачи менеджеру.
Базовая логика:
- Статус «ожидает оплаты». Заказ создан, покупатель ушёл на шлюз, подтверждения нет.
- Автоматические касания. На этот статус повешена цепочка напоминаний по расписанию.
- Таймаут и отмена. По истечении срока заказ переходит в отмену, резерв снимается, остаток возвращается.
- Эскалация в CRM. Крупные заказы уходят менеджеру, чтобы он связался лично.
Такие сценарии удобно строить на бизнес-процессах и агентах Битрикса, а тяжёлую логику — на D7-обработчиках событий заказа. Про грамотную работу с ORM и событиями мы писали в материале про D7 ORM в Битрикс.
Аналитика отказов: где именно теряете деньги
Возврат покупателя — это хорошо, но ещё важнее уменьшать число самих отказов. Для этого нужна статистика: какие коды ошибок приходят от платёжной системы, какие банки чаще отказывают, где рвётся сценарий.
Собирайте по каждому платежу: способ оплаты, код результата от шлюза, шаг обрыва, успех повторной попытки. Накопив данные, вы увидите закономерности — например, что половина отказов приходится на один банк или один способ оплаты, который стоит перенастроить или убрать. Это уже работа с данными и логами, и качество такой аналитики напрямую зависит от того, как выстроен деплой и мониторинг — тему мы разбирали в статье про CI/CD и деплой в Битрикс. Системно навести порядок в платежах и обмене помогает аудит и оптимизация 1С.
Частые ошибки в работе с неоплатами
- Заказ отменяется сразу после сбоя. Покупатель хотел повторить оплату, а заказа уже нет — приходится оформлять всё заново.
- Экран ошибки — тупик. «Платёж не прошёл» без кнопки повторить и без альтернатив.
- Нет прямой ссылки на оплату. В письме предлагают «оформить заказ снова» вместо доплаты существующего.
- Чек пробивается на создании заказа. Появляются чеки по неоплаченным заказам — нарушение 54-ФЗ.
- Спам вместо заботы. Пять писем с обратным отсчётом раздражают и роняют репутацию.
- Резерв висит вечно. Товар заблокирован под брошенными платежами, реальные покупатели видят «нет в наличии».
- Нет аналитики отказов. Магазин не знает, какой банк или способ оплаты сжигает выручку.
Чек-лист внедрения
- Брошенный платёж различим. Заказ с неудачной оплатой имеет отдельный статус или свойство.
- Заказ сохраняется. После сбоя заказ не отменяется мгновенно, а ждёт повторной оплаты.
- Экран ошибки помогает. Есть кнопка повторить оплату и хотя бы один альтернативный способ.
- Прямая ссылка на оплату. Покупатель доплачивает тот же заказ из письма и SMS.
- Цепочка касаний. Два-три спокойных напоминания по событию статуса, без искусственной срочности.
- Чек по факту оплаты. Онлайн-касса срабатывает только на подтверждённый платёж.
- Таймаут и резерв. По истечении срока заказ отменяется, остаток возвращается на склад.
- Аналитика отказов. Собираются коды ошибок и способы оплаты для снижения числа сбоев.
Вывод
Неудачная оплата почти никогда не означает «клиент передумал». В большинстве случаев это оборванный сценарий, который можно восстановить одним понятным экраном и прямой ссылкой на повторную оплату. Магазины теряют здесь деньги не потому, что покупатели не хотят платить, а потому, что после сбоя их бросают наедине с тупиковой страницей.
Наведите порядок в статусах заказа, дайте повторную оплату и альтернативные способы, добавьте пару спокойных напоминаний и правильно свяжите чек по 54-ФЗ с фактом оплаты. Это относительно небольшая работа с логикой заказа и интеграциями, которая возвращает самых горячих покупателей — тех, кто уже был готов заплатить.
