- «Нам нужен интернет-эквайринг подешевле. Где ниже комиссия?»
- «А чеки кто отправит, возвраты кто обработает, оплату в приложении кто удержит?»
- «Мы же банк выбираем, почему тут столько всего?»
На этом месте разговор обычно и становится предметным. Интернет-эквайринг - это не строка с процентом, а рабочая связка из банка, кассы, API, возвратов и срока запуска. Если смотреть только на ставку, легко сэкономить 0,3 п.п. и потерять 2 недели, 140 тыс. ₽ и часть конверсии.
Комиссия видна сразу, полная цена - нет
Обычно сравнивают 2,3% и 2,7%, но деньги уходят не только в банк. Есть касса, ОФД, внедрение, поддержка, ручная сверка, ошибки в чеках и форма оплаты, которая тоже влияет на продажи.
У магазина с оборотом 3 млн ₽ в месяц разница между 2,3% и 2,7% - это около 12 000 ₽ в месяц. Сумма заметная, но ее вес быстро снижается, если один вариант требует кастомную интеграцию на 120-180 тыс. ₽, а второй запускается готовым модулем за 1-2 дня.
У нас был D2C-магазин на WordPress. Клиент выбрал банк с минимальной ставкой, а потом выяснилось, что модуль не поддерживает частичные возвраты и нормально не передает состав заказа в кассу. В итоге интеграцию допиливали 3 недели и потратили еще 140 тыс. ₽. Экономия на тарифе закончилась в момент первого возврата.
Сравнивать стоит всю связку: комиссия + касса + чеки + интеграция + поддержка + конверсия.
У банков нет победителя вообще - есть попадание в сценарий
Сбер часто берут, когда важны узнаваемость, привычный путь оплаты и SberPay. Тинькофф обычно удобен, если нужен быстрый старт, понятный кабинет и зрелые модули для CMS. Альфа нередко подходит там, где уже есть расчетный счет, казначейство и внутренние процедуры завязаны на один банк.
| Критерий | Сбер | Тинькофф | Альфа |
|---|---|---|---|
| Комиссия | 2,3-3% | 2,49-3,5% | 2,5-3,5% |
| Подключение | 3-7 дней | 1-3 дня | зависит от сегмента |
| CMS-модули | есть | обычно сильнее | надо проверять |
| API и sandbox | нормальные | удобны для digital-команд | смотреть на тесте |
| Возвраты и холд | есть | обычно проще в работе | есть, но детали надо проверять |
Если у вас магазин на WooCommerce, OpenCart или 1C-Битрикс, я бы сначала смотрел на модуль, возвраты и связку с 1С. Если у вас приложение на Laravel 11 или Node.js 20 + NestJS, важнее API, webhooks, холдирование и модель статусов.
Частая ошибка - выбирать «самый известный» банк. Правильнее взять свой сценарий оплаты и прогнать каждый банк по одному и тому же списку вопросов.
Банк берет деньги, но чек делает не он
Бизнес покупает «интернет-эквайринг», а получает только часть процесса. Платеж прошел - хорошо. Чек покупателю должен уйти из кассы, с корректным составом заказа, НДС и статусом возврата.
В прошлом году мы запускали оплату для сервиса услуг. Эквайринг подключили за 3 дня, ссылки работали, деньги приходили. Потом выяснилось, что автоматическая фискализация падает по части заказов: бухгалтерия добивала чеки руками, а менеджеры путались в возвратах. Формально запуск состоялся, но по сути мы еще 2 недели чинили связку банка, облачной ККТ и CRM.
Если вы принимаете оплату от физлиц, на первом созвоне надо закрыть три вопроса:
- какая касса будет стоять - облачная или физическая
- кто передает состав чека и НДС
- что происходит при возврате, отмене и частичной оплате
Если эти вопросы не разобраны заранее, 54-ФЗ приходит не штрафом «из ниоткуда», а ежедневной ручной рутиной.
Лендинг обещает день, а проект живет на API
Для типового сайта хватает модуля. Для личного кабинета, подписки, мобильного приложения или нестандартной корзины все решает не лендинг банка, а документация и поведение API в реальных сценариях.
На одном B2B-проекте клиент продавал доступы в личном кабинете. Платеж проходил, но статус в CRM обновлялся вручную, потому что интеграцию сделали по минимуму. После перехода на webhooks и автоматическую сверку ручная работа сократилась на 20-30 часов в месяц, а спорных платежей стало заметно меньше.
Схема обычно выглядит так:
банк -> webhook/callback -> CRM или ERP -> касса -> чек покупателю
Тут я сам ошибался: на одном проекте мы выбрали банк по хорошим условиям для холдинга, а потом уткнулись в слабый модуль и обходной сценарий через API. Потеряли 2 недели просто потому, что не прогнали тестовый платежный контур до договора.
Что спросить у банка до подписания
Я бы не просил «лучший тариф». Я бы просил ответы на конкретные вопросы:
- есть ли sandbox и можно ли быстро прогнать тестовые платежи
- как работают частичные возвраты и холдирование
- куда и как передаются данные для чека
- какие статусы приходят в CRM или ERP
- сколько реально занимает запуск до первой стабильной оплаты
Мини-диалог, который экономит время:
- «Ставка у нас от 2,4%»
- «Хорошо. Частичный возврат есть?»
- «Да»
- «Покажите в тесте и скажите, кто отправляет чек после возврата»
Я не раз видел, как команды обсуждали комиссию час, а самый дорогой вопрос - кто чинит сломанные чеки и спорные статусы - всплывал в последний день. С тех пор мы всегда идем от контура оплаты, а тариф смотрим уже после этого. Самый дорогой эквайринг - тот, который выглядит дешевым до первого сбоя.
