В прошлом году к нам пришел сервис доставки: подключили QR за 10 дней, комиссия стала ниже, а поддержка сразу получила новый вид боли. Около 7% оплаченных заказов висели в статусе «не оплачено», потому что бэкенд ждал redirect, а финальное подтверждение приходило только через webhook. Деньги уже у банка, клиент уже ушел, оператор руками сверяет выписку и CRM.
Я такое вижу регулярно: ломается не QR, а контур вокруг него - путь пользователя, статусы, чек, возврат в приложение, сверка. Если собрать это заранее, QR работает нормально. Если прикрутить его как еще одну кнопку, ручной работы станет больше, а заказов - меньше.
Выигрыш дает не тариф, а сценарий оплаты
Сначала почти все смотрят на комиссию. Я бы смотрел на то, где у вас проходит оплата и с какого устройства. На смартфоне QR и SberPay часто удобнее карты: не надо вбивать номер, срок и код. На десктопе картина обратная - человеку нужно взять телефон, открыть банковское приложение, отсканировать код, и на этом шаге часть оплат теряется.
У нас был проект с записью в клиники. На мобильном трафике QR дал рост завершения оплаты на 11%, на десктопе - просадку почти на 8%. Мы не убрали карты, а просто подняли QR выше на mobile, а классический интернет-эквайринг оставили первым на desktop. Через 2 недели общая конверсия checkout вернулась в плюс.
На обычном desktop-магазине QR как единственный способ оплаты я бы не ставил.
Для малого бизнеса почти всегда лучше гибрид
Если задача - не терять заказы, карты лучше оставить и добавить QR рядом. Если у вас 60-70% mobile, продажи идут через Telegram, WebView или приложение, QR можно поднимать выше. Мы обычно собираем один checkout через провайдера, где есть карты, QR, оплата по ссылке и SberPay - так меньше кастомной логики и меньше сюрпризов на запуске.
| Критерий | Карты | QR | SberPay |
|---|---|---|---|
| Mobile-конверсия | высокая | часто выше карт | высокая |
| Desktop-конверсия | высокая | ниже без ясного сценария | средняя |
| Возврат после оплаты | привычный | зависит от webhook | зависит от app-to-app |
| Интеграция | стандартная | средняя | средняя |
| Чувствительность к UX | средняя | высокая | высокая |
Можно ли вообще обойтись без карт? Можно, если продукт почти целиком живет в смартфоне и вы уже видите, что пользователи спокойно платят app-to-app. Для большинства SMB карты остаются страховкой от потери конверсии.
Самое дорогое место - чек и связка идентификаторов
Платеж без фискализации - это незакрытый процесс. Деньги подтверждает провайдер, а чек часто уходит через отдельный узел: облачную кассу, API банка или внешний сервис. Если эту цепочку не собрать, бухгалтерия и поддержка очень быстро начинают жить в Excel.
У клиента из e-commerce с оборотом около 12 млн ₽ в месяц заказ создавался в Laravel 11, учет сидел в amoCRM, касса была отдельно. Чек отправляли в момент создания платежа. В результате на незавершенные оплаты уже улетали чеки, а по части успешных заказов чек не формировался вообще.
Чек надо отправлять после подтвержденного успешного статуса, а не после создания платежа.
Частая ошибка - хранить только order_id и рассчитывать, что этого достаточно. Нормальная схема - связать payment_id, order_id и идентификатор чека, добавить идемпотентность и запускать фискализацию только после confirmed-статуса. Если у провайдера отдельный контур чеков, вроде receipts API у банка, без этой связки все начинает сыпаться на возвратах и сверках.
Сбой почти всегда сидит в статусах
Полная интеграция состоит минимум из четырех слоев: экран оплаты, банк или агрегатор, обработка статусов, потом касса и учет. Слабое место обычно одно и то же - команда верит возврату пользователя сильнее, чем серверному подтверждению.
Мы сами когда-то сделали это быстро и неудачно. В приложении на Flutter пользователь уходил в банк по deep link, платил, возвращался обратно, а бронь оставалась «в обработке». Деньги были получены, но заказ обновлялся только после ручного обновления экрана. Исправили это без большой переделки, но время поддержки потеряли и жалобы от пользователей получили.
Рабочая схема у меня всегда одна:
1. Создали payment_id и order_id
2. Показали QR или перевели в банковое приложение
3. Получили webhook от провайдера
4. Проверили подпись и статус paid
5. Обновили заказ в PostgreSQL 16
6. Отправили данные в онлайн-кассу
7. Показали клиенту финальный статус оплаты
Если фронтенд живет только на redirect, зависшие заказы почти гарантированы.
Провайдера выбирают по поведению в бою
Красивый тариф редко что-то решает. Я смотрю на три вещи: как приходят подтверждения, как устроены чеки и что происходит после оплаты в приложении без ручного обновления. Для бизнеса это важнее, чем разница в 0,2% комиссии.
Если своей сильной команды под платежи нет, агрегатор часто выгоднее прямого банка. Запуск быстрее, мест для ошибок меньше, аналитику и возвраты собрать проще. Если команда сильная и нужен контроль, можно идти напрямую, но я бы сразу закладывал 3-5 недель на тесты нестандартных статусов, чеков и возвратов.
В ближайшие 6-12 месяцев выиграют те, кто считает полную стоимость платежного контура: интеграцию, чеки, возвраты, поддержку и аналитику. QR дешевле на бумаге, но деньги остаются у тех, у кого путь от кнопки «Оплатить» до фискального чека помещается на одной схеме.
