Как принимать оплату через СБП в интернет-магазине

Чтобы принимать оплату через СБП, подключите магазин к банку или платёжному провайдеру, включите совместимый модуль и проверьте весь путь от заказа до подтверждённого платежа и возврата. Разместить QR-код недостаточно: система должна понимать, какой заказ оплачен, и корректно обрабатывать незавершённую попытку.

СБП — Система быстрых платежей. Ниже речь о торговой оплате интернет-магазину, а не о переводе на личный номер сотрудника. Названия пунктов кабинета и возможности тестирования зависят от партнёра и платформы.

Выберите способ подключения

Подключение для бизнеса начинается через банк или провайдера, поддерживающего СБП для интернет-магазинов. Сравнивайте предложения по своему договору и товарной категории, а не по рекламному обещанию минимальной комиссии.

Вопрос партнёру	Что получить до начала работ
Поддерживается ли моя платформа?	Название и версия модуля, инструкция, ответственный за обновления
Как клиент платит с телефона?	Описанный переход в банковское приложение и возврат в магазин
Как магазин узнаёт результат?	Документация уведомлений и запроса статуса
Какие возвраты доступны?	Полный/частичный возврат, статусы, ограничения и сроки
Как проводить приёмку?	Поддерживаемый тестовый маршрут и перечень непроверяемых в нём действий
Во что обойдётся обслуживание?	Комиссия, дополнительные платежи, расчёты и условия договора

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

Выбор метода по расходам и поведению покупателя разобран отдельно: СБП или банковская карта.

Подготовьте магазин и включите метод

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

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

Проверьте связку оплаты с кассовыми чеками по своей схеме расчётов. Банковское подтверждение и кассовый чек выполняют разные задачи: само включение СБП не доказывает, что фискализация настроена.

Проверьте сценарий на одном телефоне

На компьютере покупатель может отсканировать QR-код телефоном. На телефоне нужен понятный маршрут в банковское приложение, поддерживаемый конкретной интеграцией. Нельзя рассчитывать, что человек отсканирует камерой QR-код с экрана того же устройства.

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

После возвращения покажите актуальный статус заказа и возможность обновить его. Если уведомление задержалось, корректный текст — «Проверяем оплату», а не преждевременное «Оплачено». Не предлагайте сразу платить повторно, пока состояние первой попытки не выяснено.

Подтверждайте оплату по доверенным данным

Переход на страницу успеха, нажатие кнопки и скриншот клиента не подтверждают поступление денег. Модуль должен использовать доверенный серверный статус: уведомление с проверками, предусмотренными документацией, и/или запрос к API провайдера.

Для каждого платежа храните идентификатор, связанный заказ, сумму, валюту и состояние. Сверяйте эти значения перед изменением заказа. Обрабатывайте уведомления повторяемо: повтор того же события не должен повторно выдавать товар, списывать остаток или запускать чек. О способе проверки подлинности уведомления нельзя судить по общему примеру — используйте документацию своего партнёра.

Минимальная таблица состояний для согласования с разработчиком:

Полученный результат	Действие магазина
Платёж создан, подтверждения нет	Ожидание, ограниченный по правилам магазина резерв
Доверенное подтверждение успеха	Однократный переход в оплаченный заказ
Отмена или истечение срока	Снятие ожидания и резерва по согласованной процедуре
Неизвестный результат/сбой связи	Запрос статуса и сверка; не считать автоматически отказом
Возврат подтверждён	Запись возврата, суммы и связи с исходной оплатой

Настройте возврат и сверку

Возвращайте средства через поддерживаемый банком или провайдером механизм к исходной операции. Проверьте доступность частичного возврата, необходимые реквизиты и ограничения. Запишите идентификатор запроса и дождитесь конечного статуса: «запрос принят» ещё не означает, что деньги зачислены покупателю.

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

Разберите учебную приёмку без реальных денег

Учебный заказ №101 на 2 400 ₽ сначала имеет статус «ожидает оплаты». В тесте обработчика разработчик подаёт имитацию успешного события с правильным идентификатором и суммой. Заказ становится оплаченным один раз. Повтор того же сообщения не создаёт второе исполнение. Сообщение с чужим идентификатором или иной суммой не подтверждает этот заказ и попадает в разбор ошибки.

Далее проверяются отмена, задержка уведомления, открытие страницы успеха без оплаты и имитация возврата 600 ₽. После подтверждения последнего в журнале должны остаться исходная оплата 2 400 ₽ и связанный возврат 600 ₽, а не новый заказ на 1 800 ₽. Это проверка логики на условных данных, а не проведённый перевод.

Согласуйте границы теста заранее. Например, документация тестового магазина ЮKassa на дату проверки 21 октября 2026 года не предоставляет обычный тестовый сценарий СБП. Имитация события проверяет собственный обработчик, но не доказывает работу банковского приложения и реальный перевод через СБП. У другого партнёра возможности могут отличаться.

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

Чек-лист перед включением для покупателей

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