подключить сбп на сайт — Подключайте СБП на сайт как дополнительный способ оплаты рядом с банковскими картами. Для типовой корзины подойдет готовый модуль или платежный виджет, для заявок — отдельная платежная ссылка, для нестандартной страницы оплаты — интеграция по API. До запуска зафиксируйте четыре точки: подтверждение платежа, связь платежа с заказом, возврат и формирование кассового чека, если вы применяете ККТ.
Добавьте СБП, если принимаете оплату от физлиц в интернет-магазине, сервисе или личном кабинете. Покупатель подтверждает платеж в приложении банка, а вы получаете статус операции от платежного провайдера.
Не отключайте оплату картой ради СБП. На странице оплаты оставьте оба способа: так покупатель выбирает привычный вариант, а бизнес не теряет заказы из-за одного недоступного или неудобного сценария.
Интернет-магазину нужна СБП на странице оплаты после корзины: заказ уже создан, сумма и состав покупки зафиксированы. Сервису с заявками удобнее отправлять персональную ссылку, привязанную к номеру заявки. Онлайн-сервису стоит использовать виджет или API, если после оплаты нужно автоматически открыть доступ в личном кабинете.
Для подписок не закладывайте автоматическое продление только потому, что на сайте есть СБП. До подключения запросите у провайдера конкретный доступный механизм: регулярный платеж, повторный счет или новую ссылку. Если такого механизма нет, отправляйте клиенту новую ссылку на очередной период и продлевайте доступ после подтвержденной оплаты.
Статус «оплачен» меняйте только после сообщения от провайдера на сервер сайта. Такое сообщение часто называют webhook — это автоматическое уведомление о событии платежа. Возврат покупателя на сайт после банковского приложения ничего не доказывает: пользователь мог закрыть страницу после успешной оплаты или вернуться без оплаты.
Если для продажи требуется ККТ, оплата через СБП не освобождает от кассового чека. Требования к применению кассы устанавливает сайт ФНС России; практический порядок настройки смотрите в материале как оформить кассовый чек при оплате через СБП в интернет-магазине.
Выберите этот вариант для типовой CMS и готовой корзины. Модуль или виджет выводит способ оплаты без разработки платежной формы с нуля. До подключения убедитесь, что решение передает номер заказа, принимает серверные уведомления, поддерживает возвраты и может передать данные в кассу.
Используйте ссылку для счетов, заявок, консультаций и услуг без корзины. Создавайте отдельную ссылку на конкретный заказ: передавайте номер заявки, сумму и срок действия. Тогда менеджер не сверяет поступления вручную, а CRM — система учета заявок и клиентов — получает понятную связь между оплатой и продажей.
Не отправляйте всем покупателям одну постоянную ссылку. При нескольких одинаковых платежах команда не сможет надежно определить, кто и за какой заказ заплатил.
Выбирайте API, то есть программный интерфейс для обмена данными между сайтом и провайдером, если у вас собственный checkout, личный кабинет, несколько витрин или нестандартная логика заказа. Этот путь требует разработчика, зато позволяет управлять созданием платежа, статусами, возвратами и выдачей товара или доступа.
До разработки нарисуйте маршрут данных: сайт создает заказ → провайдер создает платеж → провайдер отправляет подтверждение → сайт меняет статус → касса получает данные расчета → покупатель получает чек. Для дистанционных расчетов часто используют облачную кассу; порядок ее подключения разобран в статье как подключить облачную онлайн-кассу к сайту и сервису.
Разместите СБП на странице оплаты после выбора доставки и подтверждения состава заказа. Передавайте номер заказа, сумму, позиции и контакт покупателя, если он нужен для электронного чека. Передавайте заказ в сборку только после подтвержденного статуса от провайдера.
Сначала создайте заявку в CRM, затем сформируйте ссылку с ее идентификатором и суммой. После оплаты CRM должна перевести заявку на следующий этап или поставить задачу менеджеру. Проверьте отдельно истекшую ссылку, вторую попытку оплаты и возврат: одна заявка не должна попадать в работу дважды.
Сначала создайте заказ на услугу, затем откройте платежный виджет или страницу оплаты. Доступ к курсу, консультации или функции в сервисе выдавайте после подтвержденной оплаты. При возврате синхронизируйте ограничение доступа, статус заказа и кассовый документ по правилам вашей услуги.
| Критерий | Что зафиксировать до договора | Что спросить у провайдера |
|---|---|---|
| Интеграция | Модуль для CMS, виджет, ссылки или API; передача номера заказа | Есть ли готовое решение для нашей CMS и какие доработки потребуются для API? |
| Комиссия и расчеты | Тариф, минимальные условия, порядок зачисления и отображение удержаний в отчетах | Назовите комиссию для нашего оборота и сценария, все дополнительные платежи и порядок сверки. |
| Срок запуска | Этапы: договор, доступы, тестирование, боевое включение; ответственный с каждой стороны | Какой срок указан для каждого этапа и что может задержать запуск? |
| Тестовый контур | Тестовые доступы, документация, сценарии успешного и неуспешного платежа | Есть ли тестовая среда и можно ли проверить возврат, повторное уведомление и ошибку до боевого запуска? |
| Статусы и уведомления | Webhook, проверка подлинности уведомления, повторная доставка, журнал событий и запрос статуса | Как подписываются уведомления, сколько раз и как долго они повторяются, как запросить статус платежа вручную или по API? |
| Возвраты | Полный и частичный возврат, сроки обработки, статус возврата в кабинете и API | Кто оформляет возврат, допускается ли частичный возврат и как его статус передается на сайт и в кассу? |
| Фискализация | Передача позиций, суммы, контакта покупателя и данных расчета, если ККТ обязательна | Как связываются платеж, касса, ОФД и отправка электронного чека? |
| Поддержка | Канал связи, часы работы, порядок эскалации и помощь в тестировании | Кто разберет потерянное уведомление или расхождение статусов и в какой срок? |
| Подписки | Доступный сценарий повторной оплаты и правила продления доступа | Поддерживаются ли нужные нам регулярные платежи, либо нужно формировать новый счет или ссылку на каждый период? |
Для интернет-магазина обязательны уведомления о статусах, возвраты, связь платежа с заказом и передача данных в кассу. Для сервиса со ссылками добавьте срок действия ссылки и запрет повторной оплаты уже закрытого заказа. Не выбирайте провайдера только по комиссии: отсутствие тестового контура или понятной поддержки обойдется дороже на запуске и при разборе ошибок.
Перед запуском отдельно проверьте чек при оплате через СБП: сумму, позиции, реквизиты и отражение возврата. Используйте чек-лист из статьи «Онлайн-касса при оплате СБП: порядок работы, чек и ошибки».
Ошибка: убрать оплату картой. Оставьте карты и СБП на одной странице. После запуска сравнивайте успешные и неуспешные платежи по способам, а не сокращайте выбор покупателя заранее.
Ошибка: считать редирект на сайт подтверждением оплаты. Принимайте решение о выдаче товара только по серверному уведомлению и сверке ID платежа с заказом. Редирект используйте для показа результата покупателю, но не для изменения статуса.
Ошибка: обработать повторное уведомление как новый платеж. Храните ID события и платежа, а повторные сообщения обрабатывайте идемпотентно — без повторной выдачи заказа, чека или доступа.
Ошибка: не сверять зависшие статусы. Настройте регулярный запрос статуса незавершенных платежей у провайдера. Это восстановит заказы, по которым уведомление было потеряно, и выявит расхождения до обращения клиента.
Ошибка: запускать без возвратов и фискализации. До публикации кнопки назначьте сотрудника, который оформляет возвраты, и проверьте статусы в CRM, кассе и у покупателя. Иначе команда будет вручную искать платежи, а ошибки в заказах и чеках придется исправлять после запуска.
Да, можно. Начните с готового модуля, платежного виджета или уникальных ссылок; API понадобится для нестандартной корзины, личного кабинета или собственной логики статусов.
Подключите оба способа. СБП дает покупателю оплату через банковское приложение, а карты сохраняют привычный вариант для клиентов, которые не хотят переходить в приложение банка.
Да, если ваша продажа требует применения ККТ по 54-ФЗ. Настройте передачу результата оплаты и состава заказа в кассовый сервис, чтобы чек и возврат отражались в одной цепочке с заказом.
Да, можно. Создавайте отдельную ссылку с номером заказа или заявки, чтобы CRM, касса и менеджер однозначно сопоставили поступление с продажей.
Не рассчитывайте на СБП как на безусловную замену автосписаний с карты. Если продаете подписку, уточните у провайдера доступный сценарий регулярной оплаты, повторного счета или ссылки и выдавайте продление только после новой подтвержденной оплаты.
Нужна готовая схема под ваш сайт? Обратитесь в Интернет Касса. На консультации разберем вашу корзину или заявки, подберем способ интеграции и провайдера, проверим связку СБП с облачной кассой и дадим чек-лист тестирования статусов, возвратов и чеков перед запуском.