Покупатель дошёл до оплаты, увидел QR-код, отсканировал приложением банка — и через пару секунд заказ оплачен, а магазин заплатил комиссию в разы меньше, чем за эквайринг. Оплата по QR через СБП стала привычным способом, и для интернет-магазина это и экономия на комиссии, и удобство для клиента. Но за простотой для покупателя стоит аккуратная техническая реализация: статусы, уведомления, чеки, возвраты.
Разберём подключение СБП на 1С-Битрикс по-инженерному: как устроен платёжный обработчик, почему статус заказа должен опираться на callback банка, как выполнить требования 54-ФЗ по чекам и как сделать удобный экран оплаты. Настройку платежей, статусов и обмена с учётной системой закрывает автоматизация продаж и склада на 1С.
Коротко
- СБП по QR — отдельный способ оплаты с комиссией заметно ниже эквайринга и быстрым зачислением.
- Статус «оплачено» ставится по серверному callback от банка, а не по действию пользователя.
- Оплата по СБП требует фискального чека по 54-ФЗ — касса и чек привязываются к оплате заказа.
- UX критичен: крупный QR на десктопе, кнопка-ссылка в приложение банка на мобильном, индикатор ожидания.
Что такое оплата по QR через СБП
Система быстрых платежей позволяет переводить деньги между счетами по простому идентификатору, и один из её сценариев — оплата покупок по QR-коду. Магазин формирует QR, содержащий реквизиты и сумму платежа, покупатель сканирует его приложением своего банка и подтверждает перевод. Деньги поступают продавцу почти мгновенно.
Для интернет-магазина СБП — это отдельный способ оплаты, который встаёт рядом с оплатой картой. Подключается он либо напрямую через банк-эквайер с поддержкой СБП, либо через платёжного агрегатора. С точки зрения платформы это ещё одна платёжная система со своей логикой формирования QR и обработки результата.
Зачем магазину СБП
У СБП есть конкретные бизнес-преимущества, из-за которых его подключают:
- Низкая комиссия. Тарифы СБП для бизнеса заметно ниже классического интернет-эквайринга — на больших оборотах это ощутимая экономия.
- Быстрое зачисление. Деньги приходят почти сразу, что улучшает оборачиваемость.
- Простота для покупателя. Не нужно вводить данные карты — достаточно подтвердить платёж в приложении банка.
- Ещё один канал. Часть аудитории предпочитает СБП картам, и его наличие снижает отказы на оплате.
При этом СБП не заменяет карты полностью: оплата требует смартфона с установленным банковским приложением. Поэтому его подключают как дополнительный способ, расширяя выбор, а не как единственный вариант.
| Критерий | Оплата по QR (СБП) | Классический эквайринг |
|---|---|---|
| Комиссия для бизнеса | Заметно ниже | Выше |
| Скорость зачисления | Почти мгновенно | Обычно на следующий день |
| Ввод данных покупателем | Подтверждение в приложении банка | Ввод данных карты |
| Требование к покупателю | Смартфон с приложением банка | Любая карта |
| Чек по 54-ФЗ | Обязателен | Обязателен |
Как это работает технически
За кулисами оплата по QR проходит по чёткой последовательности. Понимание её нужно, чтобы правильно связать всё с заказом:
- Покупатель выбирает СБП. На шаге оплаты заказа выбран способ «оплата по QR через СБП».
- Магазин формирует QR. Обработчик запрашивает у банка или агрегатора платёжную ссылку и QR с суммой заказа.
- Покупатель сканирует и подтверждает. В приложении банка он видит сумму и получателя, подтверждает перевод.
- Банк уведомляет магазин. На сервер приходит callback об успешной оплате.
- Заказ помечается оплаченным. Обработчик переводит статус, формируется чек, покупатель видит страницу успеха.
Ключевой момент — шаг 4: именно серверное уведомление от банка является источником истины об оплате, а не то, что покупатель нажал кнопку или увидел экран. На этом строится вся надёжность.
Платёжный обработчик в 1С-Битрикс
В 1С-Битрикс каждый способ оплаты реализуется как платёжная система с обработчиком. Для СБП обработчик отвечает за три вещи: запросить у провайдера QR по сумме заказа, показать его покупателю и принять callback с результатом. Настройки (ключи доступа, идентификатор мерчанта, адрес уведомлений) задаются в параметрах платёжной системы.
Многие агрегаторы поставляют готовые модули, но на практике связку почти всегда доводят под конкретный магазин: сопоставление статусов, момент пробития чека, поведение при просрочке QR, обмен данными об оплате с учётной системой. Эта интеграционная часть — типовая задача разработки платёжных обработчиков. Как безопасно принимать серверные уведомления от внешних сервисов, мы подробно разбираем в статье про безопасность REST и вебхуков в 1С-Битрикс.
Callback и статусы заказа
Самая частая ошибка при подключении любой онлайн-оплаты — ставить статус «оплачено» по действию пользователя. Покупатель может закрыть вкладку сразу после подтверждения, потерять связь или вернуться позже — а деньги при этом уже ушли. Поэтому источник истины один: серверный callback от банка.
Правильная логика такая: после формирования QR заказ находится в статусе ожидания оплаты; когда приходит callback об успешном платеже, обработчик проверяет его подлинность и сумму и только тогда переводит заказ в оплаченный. Уведомление нужно обрабатывать идемпотентно — банк может прислать его повторно, и повторная обработка не должна дважды пробивать чек или задваивать оплату. Эта дисциплина и делает приём платежей надёжным.
Чеки по 54-ФЗ
Оплата по QR через СБП — это безналичный расчёт с физическим лицом, а значит, по 54-ФЗ магазин обязан выдать фискальный чек. Игнорировать это нельзя: отсутствие чека — нарушение с реальными штрафами.
Механика: чек пробивает онлайн-касса — собственная или облачная через оператора фискальных данных, — и электронный чек направляется покупателю. В 1С-Битрикс это работает через модуль касс: чек привязывается к оплате заказа и формируется в нужный момент (при оплате или при отгрузке — в зависимости от вашей схемы работы). Важно синхронизировать пробитие чека с фактом оплаты по callback, чтобы чек уходил ровно тогда, когда деньги подтверждены, и содержал корректный состав заказа и признак способа расчёта.
UX экрана оплаты
Техническая корректность бесполезна, если покупатель не понимает, что делать на экране оплаты. Хороший экран оплаты по QR на десктопе содержит:
- Крупный QR-код. Достаточного размера, чтобы легко отсканировать с телефона.
- Короткую инструкцию. «Отсканируйте код приложением вашего банка и подтвердите оплату».
- Сумму и назначение. Покупатель видит, сколько и за что платит, до сканирования.
- Таймер актуальности. Понятно, сколько ещё действует код.
- Индикатор ожидания. Страница сама реагирует на оплату и переводит на успех.
Особенно важен последний пункт: после оплаты страница должна автоматически перейти на подтверждение, не заставляя пользователя что-то нажимать. Это достигается опросом статуса или уведомлением с сервера. Плохой экран без обратной связи оставляет покупателя в неведении — оплатил он или нет.
Мобильный сценарий
На мобильном устройстве QR-код работает хуже: покупатель не может отсканировать код на том же экране, с которого платит. Поэтому мобильный сценарий отличается. Основной путь — кнопка-ссылка, которая открывает приложение банка напрямую с уже подставленными реквизитами платежа, минуя сканирование. QR при этом оставляют как запасной вариант для тех, кто платит с другого устройства.
Так покупатель на смартфоне нажимает кнопку, подтверждает платёж в открывшемся приложении банка и возвращается в магазин. Это резко снижает трение мобильной оплаты. Учитывая, что значительная доля заказов оформляется с телефонов, продуманный мобильный сценарий оплаты по СБП напрямую влияет на конверсию чекаута.
Просроченные QR и ошибки
QR-код действует ограниченное время, и нормальный сценарий — что покупатель не успел или передумал в моменте. Магазин должен обработать это красиво, а не бросать клиента с истёкшим кодом:
- Истёкший код. Показать сообщение и кнопку «сгенерировать новый код» или выбрать другой способ оплаты.
- Сохранение заказа. Заказ остаётся в ожидании оплаты, а не отменяется мгновенно — клиент может вернуться и доплатить.
- Ошибки провайдера. Если банк недоступен, показать понятное сообщение и альтернативу, а не техническую ошибку.
- Двойная оплата. Идемпотентная обработка callback защищает от повторного списания и задвоения.
Эти сценарии часто забывают, а именно они определяют, потеряете вы заказ или доведёте его до оплаты. Продуманная обработка ошибок — признак зрелой интеграции.
Возвраты по СБП
СБП поддерживает возвраты, и это нужно закладывать сразу. Когда заказ отменяется или оформляется возврат, магазин инициирует возврат средств через банк или агрегатор, и деньги возвращаются покупателю на счёт. Технически это делается через API платёжного провайдера, поэтому обработчик должен поддерживать операцию возврата, а не только приём оплаты.
Вместе с возвратом денег оформляется возвратный фискальный чек по 54-ФЗ — это такое же обязательное требование, как и при оплате. В 1С-Битrix возврат обычно привязывают к статусу отмены или возврата заказа, чтобы возврат средств и возвратный чек шли согласованно. Продуманный возврат экономит время поддержки и снимает риски по фискальным требованиям.
Частые ошибки
- Статус по действию пользователя. Заказ помечают оплаченным по редиректу, а не по callback банка — теряются реальные оплаты и появляются ложные.
- Нет чека по 54-ФЗ. Оплату приняли, а фискальный чек не пробили — прямое нарушение закона.
- Неидемпотентный callback. Повторное уведомление задваивает оплату или чек.
- QR без мобильного сценария. На смартфоне нечего сканировать, покупатель не может оплатить.
- Нет обработки просрочки. Истёкший код оставляет клиента в тупике без нового кода и альтернатив.
- Возврат не предусмотрен. При отмене заказа деньги приходится возвращать вручную, без возвратного чека.
Чек-лист внедрения
- Провайдер выбран. Подключение СБП через банк или агрегатор, получены ключи доступа.
- Обработчик настроен. Платёжная система формирует QR по сумме заказа и принимает callback.
- Статусы по callback. Заказ помечается оплаченным только по подтверждённому серверному уведомлению.
- Идемпотентность. Повторные уведомления не задваивают оплату и чек.
- Чеки по 54-ФЗ. Касса пробивает чек при оплате, состав и признак расчёта корректны.
- UX оплаты готов. Крупный QR и индикатор ожидания на десктопе, кнопка в приложение банка на мобильном.
- Просрочка обработана. Истёкший код даёт новый или альтернативу, заказ не теряется.
- Возвраты работают. Возврат средств и возвратный чек привязаны к отмене заказа.
Вывод
Оплата по QR через СБП — выгодный для магазина и удобный для покупателя способ, но его ценность раскрывается только при аккуратной реализации. Комиссия ниже эквайринга и быстрое зачисление привлекают, а надёжность обеспечивают правильные статусы по callback, фискальные чеки по 54-ФЗ и продуманный UX оплаты.
Стройте логику вокруг серверного подтверждения платежа, не забывайте про чеки и возвраты и сделайте отдельный мобильный сценарий с кнопкой в приложение банка. Тогда СБП станет способом оплаты, который экономит на комиссии и одновременно снижает отказы на чекауте, — а не источником потерянных заказов и претензий по фискальным требованиям.
