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