Самая дорогая ошибка в онлайн-оплате - не ставка банка. Намного чаще проблема в другом: деньги списались, заказ создан, а дальше начинается ручная работа. Чек не ушел, возврат делает менеджер, статус оплаты на сайте обновляется с задержкой. Формально эквайринг есть, но продажа собрана только наполовину.
В прошлом году мы переделывали такую схему для магазина на WooCommerce. Банк подключили за 5 дней, кнопка оплаты уже стояла, но через неделю бухгалтер нашел пропуски по чекам. Проблема всплыла не в день запуска, а через 2-6 недель, когда пришли первые возвраты и началась сверка.
Кнопка оплаты закрывает только один кусок процесса
Если сайт продает физлицам, обычно нужны не только банк и форма оплаты. Нужна вся цепочка: прием денег, статусы заказа, онлайн-касса, ОФД, чеки, возвраты.
Рабочая схема простая:
Сайт -> платежная страница -> банк или провайдер -> статус оплаты -> онлайн-касса -> ОФД -> чек клиенту
Роли здесь часто путают. Эквайринг принимает деньги. Агрегатор помогает быстро добавить способы оплаты. Облачная касса выбивает чек. SberPay может ускорить оплату на части устройств, но сам по себе задачу не решает.
У нас был проект на Laravel 11 + PostgreSQL 16 для сервиса обучения. Платежи проходили, но сайт не обрабатывал webhook, и заказ становился оплаченным только после ручной проверки. После нормальной обработки статусов подтверждение заказа сократилось с 7 минут до менее 30 секунд.
{
"event": "payment_succeeded",
"order_id": "A-1542",
"amount": 4000,
"status": "paid"
}
Считать надо всю стоимость схемы, а не только комиссию
Магазин с оборотом 1,5 млн ₽ в месяц и средним чеком 4 000 ₽ проводит около 375 заказов. Разница между ставками 2,2% и 2,7% - это примерно 7 500 ₽ в месяц. Сумма заметная, но редко решающая.
На практике больше денег уходит в других местах:
- мобильная форма оплаты снижает завершение заказа
- чеки уходят с ошибками или задержкой
- возвраты делаются вручную в кабинете банка
- бухгалтерия тратит часы на сверку платежей
- CMS требует доработок, которые не учли в начале
У одного клиента checkout на мобильных открывался тяжело и запрашивал лишние поля. После смены сценария оплаты завершение платежа выросло на 11%. Эта прибавка перекрыла выгоду от более низкой комиссии уже в первый месяц.
Низкая ставка выгодна только тогда, когда вся цепочка после оплаты работает без ручного вмешательства.
Путь запуска зависит от стадии бизнеса
Для MVP и небольшого магазина я обычно смотрю в сторону модуля CMS или агрегатора. Если сайт на 1С-Битрикс или WooCommerce, запуск через модуль занимает 1-3 дня. Прямая интеграция по API банка с webhook, возвратами и чеками - это уже 2-4 недели, а иногда и дольше.
| Путь | Срок | Гибкость | Что по чекам |
|---|---|---|---|
| Модуль CMS | 1-3 дня | Средняя | Часто уже есть |
| Агрегатор | 3-7 дней | Выше средней | Обычно есть |
| API банка | 2-4 недели | Высокая | Надо проверять |
Здесь есть простой, но полезный расчет. Коробочное решение с комиссией выше на 0,3-0,5 п.п. часто выгоднее, чем кастомная интеграция за 120-250 тыс. ₽. Если оборот пока небольшой, такая разработка просто не успеет окупиться.
Когда стоит идти в API банка сразу?
Когда уже есть стабильный поток платежей, нужны подписки, холдирование, частичные возвраты или своя логика аналитики. Для раннего запуска это часто лишняя сложность.
Касса ломается тише всего, но чинить ее дороже
С оплатой все обычно видно сразу: деньги пришли или нет. С кассой сложнее. Ошибки по 54-ФЗ всплывают позже, когда нужно проверить состав заказа, НДС, контакт клиента или оформить частичный возврат.
Для pure online-проектов облачная касса чаще удобнее обычной. Ее проще встроить в поток заказов и не думать про железо. Но и здесь легко ошибиться в деталях. У нас был случай, где первый чек по подписке уходил нормально, а корректировочный на частичный возврат не создавался. Эту историю операций мы разбирали за 3 месяца, и часть проблемы сначала сами недооценили.
До/после
- До - возвраты вручную, чеки с пропусками, сверка в конце месяца занимала полдня
- После - автоматические статусы, касса в одной цепочке с сайтом, ручных действий стало меньше примерно на 70%, бухгалтерия вернула около 10 часов в месяц
Что проверить до запуска, а не после первой жалобы
Я бы проверял не кнопку «Оплатить», а полный сценарий. Клиент платит с телефона вечером, потом просит частичный возврат. Заказ меняет статус, чек уходит, деньги возвращаются, в сверке нет расхождения.
Если хотите быстро понять состояние своей схемы, задайте команде один вопрос: что произойдет, если сегодня ночью пройдет в 3 раза больше платежей? Если ответ упирается в ручную проверку утром, у вас еще не платежный контур. Стоит заранее понять, что сломается первым, когда продажи действительно пойдут в объеме.
