Как подключить оплату на сайте: провайдеры, 54-ФЗ и порядок действий

В России сайт принимает оплату через провайдера — ЮKassa, Т-Кассу, Робокассу или CloudPayments. Провайдер берёт комиссию с каждого платежа и передаёт данные онлайн-кассе для чека по 54-ФЗ. Выбор определяют три вещи: комиссия, способ оплаты (карта или СБП) и готовая интеграция с вашей CMS. Ниже — сравнение тарифов, требования закона и интеграция сайта с платёжными системами и 1С под ключ, если настраивать самостоятельно нет ресурса.

Какой провайдер выбрать: сравнение комиссий

Точную ставку без заявки не даст никто. У трёх провайдеров из четырёх комиссия зависит от оборота и категории бизнеса. Ниже — публичные тарифы с сайтов провайдеров на дату проверки. Итоговую цифру для конкретного сайта провайдер называет уже после подачи заявки.

Разница между «Стартовым» и «VIP»-тарифом у одного провайдера доходит до полутора процентных пунктов. Для магазина с оборотом в несколько миллионов рублей в месяц это ощутимая сумма. На старте разумно запросить у провайдера расчёт под свой оборот, а не ориентироваться на минимальную цифру с сайта.

Есть ещё деталь по НДС. С 1 января 2026 года на комиссию за эквайринг начисляется НДС 22 %, кроме платежей через СБП и сервисы вроде T-Pay. Эту разницу нужно закладывать в расчёт, если сравниваете провайдеров по факту, а не по объявленному проценту (источник: pay.yandex.ru/blog/articles/ekvajring-2026, 29.09.2026).

Модули для приёма платежей есть у всех четырёх провайдеров под основные CMS — 1С-Битрикс, WordPress и WooCommerce, OpenCart, Tilda; для самописного сайта интеграция идёт через REST API и виджет оплаты на странице.

Что нужно от юрлица до подключения

Провайдер запросит стандартный пакет документов. Реквизиты компании или ИП. Расчётный счёт. ИНН, ОГРН или ОГРНИП. Устав или свидетельство о регистрации, иногда — договор с банком-эквайером напрямую. Для физлиц без регистрации бизнеса приём платежей на сайте не работает: нужен минимум статус самозанятого.

Если через форму оплаты собираются персональные данные покупателя — имя, телефон, адрес доставки, — на сайте должна быть опубликована политика обработки персональных данных и согласие на её обработку до отправки формы. Что 152-ФЗ требует от формы оплаты и что делать при утечке платёжных данных, разобрано в отдельном материале о 152-ФЗ для сайта.

54-ФЗ: онлайн-касса и чек

Обязанность применять контрольно-кассовую технику при расчётах распространяется на все организации и ИП, кроме случаев, прямо перечисленных в законе (ст. 1.2 54-ФЗ; текст: consultant.ru, проверено 29.09.2026). Бумажный чек при дистанционной продаже не печатают. Чек формируется автоматически и уходит покупателю на email или телефон, указанные при оплате.

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

Порядок подключения: 10 шагов

1. Выбрать провайдера по таблице выше и по набору нужных способов оплаты.
2. Зарегистрировать личный кабинет и подать заявку с реквизитами компании.
3. Загрузить учредительные документы и данные расчётного счёта.
4. Дождаться проверки — модерация занимает от нескольких часов до нескольких рабочих дней.
5. Получить тестовые ключи API (shopId, секретный ключ или токен — по документации провайдера).
6. Установить готовый модуль для вашей CMS или подключить API вручную.
7. Настроить приём чеков по 54-ФЗ: включить онлайн-кассу провайдера в личном кабинете.
8. Настроить webhook — адрес на вашем сервере, куда провайдер присылает уведомление об оплате.
9. Провести тестовые платежи в песочнице на все способы оплаты, включая отмену и возврат.
10. Переключиться на боевой режим и провести первый реальный платёж на минимальную сумму.

Тестовый режим и типичные ошибки

У каждого провайдера — отдельные ключи API для теста и для боя. Тестовые платежи не долетают до боевого счёта. Боевые платежи через тестовые ключи не проходят вовсе. Перепутанные ключи — частая причина, по которой «оплата не работает» на только что запущенном сайте. Проверьте это первым делом: не остался ли на боевой странице тестовый shopId.

Вторая по частоте ошибка — необработанный webhook. Если сервер не отвечает провайдеру статусом 200 на уведомление об оплате, заказ может остаться «неоплаченным» в базе сайта. Деньги при этом уже списаны с карты покупателя. Проверяйте не только сам факт получения webhook, но и то, что обработчик доходит до конца без ошибки на каждой оплате, а не только на первой тестовой.

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

Где чаще всего теряют деньги: типичные ошибки

Кроме технических сбоев, деньги теряют на пиковых нагрузках. Форма оплаты, которая нормально работает при десяти заказах в час, может не выдержать резкий скачок трафика в высокий сезон: очередь запросов к API провайдера растёт, часть платежей срывается по таймауту, покупатель уходит без покупки. Как нагрузку на оплату в Чёрную пятницу проверить заранее и не потерять заказы в пиковый день, разобрано в отдельном материале про подготовку интернет-магазина к распродажам.

Если у вас маркетплейс: выплаты продавцам

У маркетплейса схема сложнее. Деньги от покупателя нужно разделить между площадкой и продавцом, а не просто принять на свой счёт. Часть провайдеров поддерживает сплит-платежи: суммы автоматически делятся на комиссию площадки и остаток продавцу прямо в момент оплаты, без ручных переводов. Как устроены выплаты продавцам на маркетплейсе и какую модель выбрать на старте, разобрано в отдельной статье о запуске маркетплейса с нуля.

Оплата и 1С: что происходит после платежа

Платёжный шлюз редко живёт сам по себе: после оплаты заказ должен попасть в учётную систему, сменить статус и запустить отгрузку. Ручная сверка платежей раз в день работает, пока заказов немного, и перестаёт работать, как только их количество вырастает в разы. Как устроена передача заказов и оплат в 1С и почему обмен иногда не срабатывает после обновления CMS, разбирает отдельная статья про обмен сайта с 1С.