У нас был e-commerce проект, где банк подключил интернет-эквайринг за 5 дней. Клиент уже готовил рекламу, но продажи стартовали только еще через 2 недели. Задержал не банк - сломалось все вокруг: чеки, возвраты, статусы заказа и повторные webhooks.
Я много раз видел один и тот же сценарий. Бизнес выбирает страницу оплаты, а рабочая схема приема денег остается недособранной. Если смотреть только на кнопку «Оплатить», потом поддержка, бухгалтерия и продажи начинают жить в разных кабинетах.
Кнопка оплаты - это только верхний слой
В рабочем проекте онлайн-оплата почти всегда состоит из четырех частей: checkout, платежный провайдер, логика статусов в backend и фискализация. Банк может быстро выдать hosted payment page, но это только видимая часть схемы. Если платеж не связан с заказом на уровне backend, проблемы обычно начинаются не в день запуска, а на первой волне возвратов.
На одном проекте заказ уходил в CRM, платеж - в кабинет банка, чек - в сервис кассы. Когда покупатель спрашивал про возврат, менеджер вручную искал три записи. После 80+ оплат в день это уже не процесс, а постоянная сверка.
сайт / приложение -> backend -> платежный провайдер -> webhook -> CRM / OMS -> сервис фискализации / облачная касса
Перед первым платежом я бы проверил вот что:
- где хранится финальный статус заказа
- кто и когда формирует чек
- есть ли полный и частичный возврат
- что происходит при повторном webhook
- как обрабатываются неуспешные оплаты
Формально оплата может работать, а деньги для бизнеса все равно будут «застревать» между системами.
Выбор схемы зависит от сценария продаж
Для простого старта банк часто подходит нормально. Карты, знакомый бренд, базовые методы вроде SberPay, понятный договор. Для запуска в короткий срок агрегатор почти всегда быстрее.
У сети онлайн-курсов мы запускали оплату через готовый модуль на WordPress с amoCRM и облачной кассой. Уложились в 7 дней, потому что не делали свой checkout и не трогали сложную логику статусов. Для такого сценария это был здравый выбор.
Но был и обратный пример. B2B-сервис с личным кабинетом сначала пошел через агрегатор, чтобы ускориться. Через 6 недель стало ясно, что схема не тянет: частичные возвраты работали криво, оплату нескольких счетов собирать было неудобно, аналитика по статусам оставалась бедной. Мы перевели проект на прямую интеграцию с банком и кассой и по сути сделали второй платежный проект внутри первого. Я сам пару раз переоценивал агрегаторы: на демо все выглядело проще, чем в ежедневной работе.
Самая дорогая часть - не комиссия, а все вокруг денег
Когда сравнивают эквайринг, обычно смотрят на ставку. Разница в 0,3-0,5% выглядит заметно, но для малого и среднего бизнеса это редко главный расход в первый год. Цифры говорят: экономия на комиссии легко теряется, если потом появляются доработки на 300-500 тыс. ₽ под чеки, кассу, возвраты и сверку расхождений.
Если вы принимаете оплату от физлиц, эквайринг и онлайн-касса - это две разные части схемы. Мы пробовали тянуть офлайн-кассу в онлайн-проект, и это не сработало: ночные списания, удаленные возвраты и автоматическая отправка чеков быстро уперлись в ручные действия. Для сайта с подписками и удаленными платежами облачная касса почти всегда практичнее.
В одном проекте на Laravel 11, PostgreSQL 16 и Redis мы связали заказ, оплату и чек через API кассового сервиса и подход с Receipts API Sberbank. Бухгалтерия перестала дублировать операции руками, а по каждому заказу появилась нормальная трассировка. Переделка такой схемы после запуска обычно обходится в 2-3 раза дороже.
Три схемы, которые реально используют компании
Я бы выбирал не по бренду банка, а по тому, как деньги проходят через ваш продукт. Если платеж - часть продукта, ограничения быстро становятся дорогими.
| Схема | Скорость запуска | Возвраты | Рекурренты | Источник правды по заказу | Нагрузка на разработку |
|---|---|---|---|---|---|
| Банк-эквайринг | 1-3 недели | базовые, зависит от API | иногда | обычно свой backend | средняя |
| Агрегатор | 3-7 дней | часто есть, но логика ограничена | часто есть | часть данных у провайдера | низкая |
| Своя интеграция | 4-8 недель | полный контроль | удобнее для подписок | у вас в системе | высокая |
Грубо по экономике это выглядит так: до 300-500 платежей в месяц важнее скорость запуска и низкая цена внедрения. После 500+ платежей автоматизация чеков, статусов и возвратов окупается быстро, потому что снимает ручной труд и снижает потери на ошибках.
Выручка теряется в статусах, а не в форме оплаты
На мобильном трафике тот же SberPay иногда сокращает путь до оплаты на пару шагов, и это приятно видно в конверсии. Но выручка чаще уходит в другом месте - там, где backend плохо обрабатывает события от банка.
У одного клиента банк подтверждал платеж, а CRM оставалась в ожидании. Причина была довольно прозаичной: повторная доставка webhook после таймаута, а обработчик не был идемпотентным. Мы добавили отдельную таблицу payment_events, проверку по idempotency key и явную статусную модель. После этого доля «потерянных» заказов ушла с нескольких процентов до единичных случаев в месяц.
До и после это выглядело так:
- До: менеджер сверяет кабинет банка и CRM вручную
- После: заказ обновляется автоматически по webhook
- До: возврат идет через поддержку и бухгалтерию
- После: частичный возврат запускается из backend по API
- До: чек отправляют с задержкой
- После: кассовый сервис делает это сам
Если банк обещает подключение за 5 дней, попросите подрядчика в тот же день нарисовать полную карту движения заказа, денег и чека. Иначе те самые 2 недели после «готовой оплаты» уйдут не на продажи, а на поиск пропавших статусов.
