Онлайн-оплата на сайте: эквайринг, СБП, чеки и возвраты

Кнопка «Оплатить» выглядит как маленькая деталь интерфейса, но за ней стоит договор с банком или агрегатором, требования к онлайн-чекам, обработка возвратов, статусы платежей и десяток сценариев, когда что-то идёт не так. Большинство проблем с оплатой появляются не в момент подключения, а через месяц: деньги списались, а заказ остался неоплаченным; клиент вернул товар, а возврат завис; налоговая спрашивает, почему по части платежей нет чеков. Разберём, как устроен приём платежей и что продумать до запуска.

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

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

Интернет-эквайринг банка

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

Платёжный агрегатор

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

Система быстрых платежей

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

Конкретные тарифы меняются, поэтому сравнивайте актуальные условия нескольких провайдеров на свой оборот и средний чек.

Чеки: о чём нужно подумать заранее

При приёме оплаты онлайн в большинстве случаев нужно формировать кассовый чек и отправлять его покупателю в электронном виде. Требования установлены законом о применении контрольно-кассовой техники (54-ФЗ), а исключения зависят от вида деятельности и системы налогообложения. Уточните у бухгалтера, распространяются ли они на вас; ниже — технические варианты.

• Облачная касса у агрегатора. Агрегатор сам формирует чек и отправляет его покупателю. Самый простой вариант.
• Собственная онлайн-касса с подключением к сайту. Сайт после оплаты передаёт данные в кассу. Нужна интеграция.
• Касса в аренду у сервиса фискализации. Промежуточный вариант: сервис предоставляет кассу и API.

Технически важно, чтобы в чек попадали правильные данные: наименование товара или услуги, цена, количество, ставка НДС, признак способа расчёта (полная оплата, предоплата, аванс). Ошибки здесь выясняются не сразу, а при проверке, поэтому шаблоны чеков стоит согласовать с бухгалтером до запуска.

Статусы платежа и почему заказы «зависают»

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

Правильная схема:

1. Сайт создаёт платёж у провайдера и сохраняет его идентификатор в заказе.
2. Клиент оплачивает на стороне провайдера.
3. Провайдер отправляет уведомление (webhook) на сервер сайта о смене статуса.
4. Сервер проверяет подлинность уведомления — подпись или повторный запрос статуса через API.
5. Только после этого заказ помечается оплаченным.
6. Дополнительно сервер периодически опрашивает статус платежей, по которым уведомление не пришло.

Пятый и шестой пункты часто пропускают. Без проверки подлинности злоумышленник может отправить поддельное уведомление «оплачено». Без периодической сверки заказы, по которым уведомление потерялось, так и остаются неоплаченными.

Возвраты

Возврат — это отдельный сценарий, который нужно спроектировать, а не оставить «на потом».

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

Если возвраты оформляются вручную в кабинете провайдера, а в CRM об этом ничего нет, через несколько месяцев финансовые отчёты перестают сходиться.

Безопасность

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

Что остаётся на вашей стороне:

• Проверка подписи всех уведомлений от провайдера.
• Хранение ключей API в защищённой конфигурации, а не в коде.
• Защита от повторной обработки одного и того же уведомления.
• Проверка суммы: сумма оплаты должна совпадать с суммой заказа.
• Журнал всех платёжных событий.

Подробнее о защите интернет-магазина — в статье о безопасности онлайн-продаж.

Оплата в личном кабинете и подписки

Отдельный случай — регулярные платежи: подписка на сервис, ежемесячная оплата обслуживания, автоматическое продление тарифа. Здесь появляются дополнительные вопросы.

• Сохранение способа оплаты. Провайдер хранит привязку карты и выдаёт вам токен. Сами данные карты на вашей стороне не хранятся.
• Согласие на автоматические списания. Покупатель должен явно согласиться на регулярные платежи и понимать, как от них отказаться. Отказ должен быть простым — кнопка в кабинете, а не письмо в поддержку.
• Неудачное списание. Карта истекла, на счёте нет денег. Нужен сценарий: повторные попытки, уведомление клиенту, льготный период, отключение услуги.
• Уведомление перед списанием. Напоминание за несколько дней до продления снижает число споров и возвратов.
• Изменение тарифа посреди периода. Как считается доплата или перерасчёт.

Каждый из этих сценариев нужно не только реализовать, но и отразить в оферте. Если поведение системы расходится с текстом оферты, в споре с клиентом это обернётся против вас.

Как сверять платежи с учётом

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

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

Что проверить до запуска

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

Что выбрать

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

Мы подключаем оплату в рамках разработки сайтов и личных кабинетов и всегда закладываем проверку уведомлений, сверку статусов и возвраты. Если оплата у вас уже есть, но заказы периодически зависают, напишите нам — обычно проблема находится за день.