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