КАК ПОДКЛЮЧИТЬ ОНЛАЙН-ОПЛАТУ НА САЙТЕ: ЭКВАЙРИНГ, СБП ИЛИ АГРЕГАТОР

Кнопка «Оплатить» выглядит как одна из самых простых функций сайта. Пользователь нажал, ввёл данные карты или отсканировал QR-код, деньги пришли на счёт. Но за этой кнопкой стоят сразу несколько процессов: платёжный провайдер, статус операции, чек, возврат, связка с заказом или договором и передача результата в CRM, 1С или внутреннюю систему.

Если подключить оплату «сбоку», бизнес быстро получает ручную сверку: деньги пришли, а заказ остался неоплаченным; клиент оплатил продление, а срок в системе не изменился; платёж вернули, но менеджер об этом не знает. Поэтому выбирать нужно не только по комиссии. Важнее понять, как оплата встроится в сам процесс.

Разберём три основных варианта — интернет-эквайринг банка, СБП и платёжный агрегатор, — сравним комиссии и ограничения и покажем пошагово, что нужно сделать до запуска.

Три способа принимать оплату на сайте

Для большинства российских сайтов выбор сводится к трём схемам. Они не взаимоисключающие: часто лучший вариант — дать клиенту и карту, и СБП через одного платёжного партнёра.

Способ Как работает Главный плюс Главный минус Когда выбирать
Интернет-эквайринг банка Клиент платит картой через платёжную форму банка Прямая работа с банком, привычный способ оплаты Тариф и интеграция зависят от банка Есть расчётный счёт, понятный оборот, нужна стандартная оплата картой
СБП Клиент оплачивает через приложение банка по QR или платёжной ссылке Комиссия обычно заметно ниже карточного эквайринга Не каждый клиент выбирает QR, карту всё равно лучше оставить Важна экономия на комиссии, много повторных платежей
Платёжный агрегатор Один договор даёт сразу несколько способов оплаты Быстрое подключение, много методов, единый API Комиссия по картам часто выше прямого эквайринга Нужен быстрый старт и несколько способов оплаты без отдельных интеграций

Главная ошибка — считать, что «СБП дешевле, значит оставляем только СБП». Комиссия действительно ниже, но конверсия оплаты зависит ещё и от привычки клиента. Если человеку удобнее карта, лишний шаг может стоить дороже сэкономленных десятых долей процента. Поэтому в большинстве коммерческих проектов разумная база — карты + СБП.

Сколько стоит принимать оплату в 2026 году

Комиссия зависит от банка, оборота и вида деятельности, поэтому единой ставки «для всех сайтов» не существует. Но ориентиры позволяют понять порядок цифр.

Вариант Ориентир по комиссии Что важно знать
Интернет-эквайринг Ставка определяется банком и договором; в отдельных публичных тарифах 2026 года встречается диапазон примерно 1,7–2,6% до дополнительных условий Чем выше оборот, тем чаще можно договориться об индивидуальной ставке
СБП Для многих категорий бизнеса около 0,4% за товары и 0,7% за услуги; для отдельных льготных категорий ставка ниже Обычно существенно дешевле карточного платежа
Агрегатор Например, базовый тариф ЮKassa для банковских карт при обороте до 3 млн ₽ в месяц — 3,5% Зато один договор и одна интеграция дают несколько методов оплаты

С 2026 года при сравнении тарифов важно смотреть не только на крупную цифру в рекламе, но и на НДС на комиссию по конкретному способу платежа. Условия отличаются: например, у ряда провайдеров комиссия по карточному эквайрингу облагается НДС, а платежи через СБП идут по другой схеме. Финальную ставку всегда смотрят в вашем договоре, а не в статье или баннере банка.

Простой пример. При обороте онлайн-платежей 2 млн ₽ в месяц разница между 2,5% по картам и 0,7% через СБП — 36 000 ₽ в месяц. Но если попытка насильно перевести всех клиентов на СБП просадит конверсию хотя бы на несколько заказов, экономия может исчезнуть. Поэтому правильный вопрос звучит не «что дешевле», а «какая комбинация способов даёт лучший итог по комиссии и конверсии».

Интернет-эквайринг: когда он удобнее

Эквайринг — самый привычный сценарий. Клиент вводит данные карты или использует сохранённый платёжный способ, банк подтверждает операцию, а сайт получает статус «успешно» или «ошибка».

Что важно при выборе банка:

• ставка по вашей категории бизнеса и обороту;
• есть ли готовый модуль для вашей CMS;
• есть ли API для собственного сайта или приложения;
• поддерживаются ли рекуррентные платежи и привязка карты, если они нужны;
• как делаются полный и частичный возврат;
• насколько удобно получать реестр платежей;
• есть ли готовая связка с онлайн-кассой;
• как быстро техподдержка решает проблемы с платежами.

Если у вас обычный интернет-магазин на распространённой CMS, подключение часто сводится к установке готового модуля и настройке ключей. Если сайт кастомный, платёж становится частью разработки: нужно создать платёж на сервере, безопасно получить ответ, обработать webhook и только после подтверждения менять статус заказа.

СБП: почему почти всегда стоит добавить

СБП особенно интересна там, где оборот большой, а маржа невысокая. На каждом отдельном платеже разница кажется небольшой, но на месячном объёме она превращается в заметную сумму.

Для клиента сценарий простой: он выбирает СБП, открывает приложение банка и подтверждает платёж. Карточные реквизиты вводить не нужно. Для бизнеса плюс не только в комиссии — деньги зачисляются быстро, а статус операции можно так же автоматически передать в сайт и учётную систему.

СБП хорошо работает как второй способ оплаты:

• интернет-магазины;
• доставка еды и товаров;
• личные кабинеты с регулярными платежами;
• оплата счетов и услуг;
• продления, подписки и повторные покупки.

Но QR-код сам по себе ещё не автоматизация. Если после платежа менеджер вручную ищет перевод и меняет статус заказа, вы просто заменили один способ оплаты другим. Сайт должен получить подтверждение от платёжного сервиса и сам выполнить нужное действие.

Платёжный агрегатор: когда переплата оправдана

Агрегатор полезен, когда бизнесу важнее скорость и простота, чем минимальная комиссия по одному конкретному способу. Вместо отдельных договоров и интеграций вы подключаете одну систему и получаете карты, СБП и другие методы через единый API.

Это особенно удобно:

• на старте нового проекта;
• когда способов оплаты должно быть несколько;
• если нет желания поддерживать несколько банковских интеграций;
• когда нужен готовый модуль для CMS;
• когда важны единая статистика, возвраты и управление платежами из одного кабинета.

Например, у ЮKassa нет отдельной абонентской платы: комиссия удерживается с успешных платежей. Удобство вы покупаете более высокой ставкой по части способов оплаты. Для небольшого бизнеса это часто рациональнее, чем сэкономить несколько десятых процента и потратить больше на разработку и поддержку собственной связки.

Что нужно подготовить до подключения

Платёжный сервис проверяет не только реквизиты компании, но и сам сайт. До подачи заявки стоит привести в порядок базовые вещи:

• понятное описание товаров или услуг и цены;
• реквизиты продавца;
• контакты;
• условия оплаты;
• правила возврата и отмены;
• политика обработки персональных данных;
• оферта или договор, если формат продаж этого требует;
• HTTPS и нормальная работа сайта без критических ошибок.

Для регулируемых сфер требований может быть больше. Их лучше проверить до разработки, а не после того, как платёжный модуль уже готов.

Как подключить оплату: пошагово

1. Определить сценарий оплаты

Сначала описывают не «нужна кнопка», а что происходит до и после неё. Что оплачивает клиент: товар, услугу, счёт, подписку, продление договора? Можно ли платить частями? Нужен ли повторный платёж? Что меняется в системе после успешной операции?

2. Выбрать способы оплаты

Для большинства проектов базовый набор — банковская карта + СБП. Остальные способы добавляют, если они действительно нужны аудитории. Не стоит подключать десять вариантов «на всякий случай».

3. Выбрать провайдера

Сравнивают комиссию, поддержку СБП, API, готовые модули, возвраты, рекуррентные платежи, кассу и качество документации. Для нестандартного проекта разработчику особенно важны API и webhook — без них красивый личный кабинет быстро превращается в ручную сверку.

4. Настроить техническую интеграцию

Правильная схема выглядит так:

заказ или начисление → создание платежа → переход клиента на оплату → подтверждение провайдером → webhook на сервер → изменение статуса → запись операции в учёт → уведомление клиента

Критический момент — менять статус не по тому, что пользователь вернулся на страницу «Спасибо», а по подтверждению от платёжной системы. Страницу можно закрыть, обновить или подделать; серверное подтверждение — источник истины.

5. Подключить фискализацию

Если ваш бизнес обязан применять ККТ по 54-ФЗ, чек должен формироваться корректно и в нужный момент. Это может быть своя онлайн-касса, облачная касса или готовая связка платёжного сервиса. Налоговую логику лучше проверить с бухгалтером под конкретную схему продаж.

6. Продумать возвраты

Возврат — не исключение, а штатный сценарий. Нужно заранее решить, кто может его провести, можно ли вернуть часть суммы, какой статус получает заказ и как информация попадает в учёт.

7. Протестировать не только успешную оплату

Минимальный набор тестов:

• успешный платёж;
• отказ банка;
• пользователь закрыл страницу;
• повторный webhook;
• двойное нажатие «Оплатить»;
• частичный возврат;
• полный возврат;
• задержка ответа провайдера;
• платёж прошёл, пока пользователь был не на сайте.

Именно на этих сценариях чаще всего ломается «простая интеграция».

Разбор: онлайн-оплата в Orion Finance

В проекте Orion Finance для ломбарда мы в NorthCode делали не отдельную платёжную кнопку, а личный кабинет, в котором оплата встроена в логику займа. Клиент видит информацию по своему договору, может внести платёж или продлить его онлайн, а результат операции связан с конкретным обязательством.

Это важная разница. Если просто поставить эквайринг на страницу, деньги вы примете. Но дальше сотруднику придётся вручную понимать, к какому договору относится платёж, что нужно продлить и какой статус поставить. Когда оплата встроена в систему, это происходит автоматически.

Поэтому в проектах с личным кабинетом основная работа часто не в платёжной форме как таковой, а в связке «клиент → договор/заказ → платёж → учёт → новый статус → документ/уведомление».

Частые ошибки

• Выбирать только по минимальной комиссии. Дешёвый тариф ничего не стоит, если интеграция неудобна или падает конверсия.
• Менять статус заказа после возврата клиента на сайт, а не после серверного подтверждения.
• Не связывать платёж с CRM, 1С или внутренней системой. Деньги есть, автоматизации нет.
• Забывать про возвраты и частичные возвраты.
• Подключать кассу в самом конце. Фискализация влияет на архитектуру процесса.
• Оставлять только один способ оплаты без причины.
• Не вести логи. Если платёж «потерялся», без истории запросов разбираться намного сложнее.

Частые вопросы

Что дешевле — эквайринг или СБП? Обычно СБП заметно дешевле. Для многих категорий бизнеса комиссия находится около 0,4–0,7%, тогда как карточный эквайринг чаще стоит несколько процентов или около двух процентов на индивидуальных банковских тарифах. Но выбирать только по комиссии нельзя — учитывайте конверсию и удобство клиента.

Можно ли оставить на сайте только СБП? Технически можно, но для массового B2C-сайта чаще разумнее оставить и карты. Вы не заставляете клиента менять привычный способ оплаты ради вашей экономии.

Что выбрать небольшому бизнесу? Если нужен быстрый запуск, обычно проще начать с агрегатора или готового эквайринга банка с модулем для вашей CMS. Когда обороты растут, можно пересчитать экономику и переходить на более выгодную схему.

Нужна ли программистская интеграция? На Tilda, популярных CMS и конструкторах часто есть готовые модули. Для кастомного сайта, приложения или личного кабинета обычно нужен API и серверная разработка.

Можно ли принимать оплату и на сайте, и в приложении через одного провайдера? Да. Часто это лучший вариант: платёжная логика и учёт едины, меняются только интерфейсы клиента.

Нужна ли онлайн-касса? Зависит от вашей деятельности и применимых исключений. Если на бизнес распространяется 54-ФЗ, нужно обеспечить корректную фискализацию. Конкретную схему лучше подтвердить с бухгалтером.

Что в итоге

Онлайн-оплата — это не кнопка, а часть бизнес-процесса. Интернет-эквайринг даёт привычную оплату картой, СБП снижает комиссию, агрегатор упрощает запуск и объединяет способы оплаты. В большинстве проектов не приходится выбирать что-то одно: оптимальная связка — карты + СБП, а провайдера выбирают по комиссии, API, кассе и удобству поддержки.

Если вам нужен не просто платёжный виджет, а сайт или личный кабинет, где оплата автоматически связана с заказом, договором, CRM или 1С, — разберём процесс и заложим платёжную логику в архитектуру. Смежное: личный кабинет для клиентов, цифровизация ломбарда и МФО, интеграция 1С с сайтом.