Интернет-эквайринг для сайта: выбор, подключение и запуск оплаты

Интернет-эквайринг для сайта принимает оплату картой, через СБП и другими подключенными способами, а затем передает сайту подтвержденный статус операции. Эта статья даст готовую схему из семи шагов: выбрать провайдера, безопасно принять webhook, связать оплату с заказом и кассой, протестировать возвраты и наладить сверку выплат.

Не включайте оплату, пока не пройдете тестовую цепочку: заказ → подтвержденный платеж → кассовый документ при необходимости → выдача товара или доступа → возврат. Статус заказа меняйте по серверному подтверждению провайдера, а не после перехода покупателя на страницу «Успешная оплата».

Когда интернет-эквайринг нужен сайту

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

Эквайринг и фискализация решают разные задачи. Провайдер обрабатывает платеж, а онлайн-касса формирует кассовый чек в случаях, когда этого требует законодательство о ККТ, и направляет фискальные данные через ОФД. Официальные разъяснения о применении ККТ и электронных чеках публикует сайт ФНС России.

До подключения зафиксируйте источник реквизитов чека: наименований, количества, суммы, ставки НДС при ее применении, признака способа расчета и контакта покупателя. Если платежная форма передает в кассу только сумму, передавайте состав заказа из CMS, CRM или серверной части сайта.

Сценарии бизнеса: какую схему выбрать

Интернет-магазин с корзиной

Для типовой CMS выбирайте готовый модуль, который поддерживает вашу версию движка и передает состав заказа. Для самописного сайта используйте API и серверные уведомления: заказ получает статус «оплачен» только после подтверждения от провайдера.

Продажи через менеджера, мессенджеры и лендинг

Используйте платежную ссылку или платежную страницу. Создавайте ссылку из CRM или другой учетной системы и привязывайте ее к номеру заказа, сумме и покупателю — тогда платеж, возврат и обращение клиента можно найти без ручного поиска по выписке.

Подписка и пополнение баланса

Подключайте рекуррентные списания — повторные платежи по сохраненной у провайдера привязке карты. Не храните карточные данные на сайте; сохраняйте только технический идентификатор привязки, если он нужен для запросов к API.

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

Предоплата с выдачей товара позже

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

Как выбрать банк или платежного провайдера

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

Дальше выберите нужные методы: карты, СБП, платежные ссылки, повторные списания. Каждый метод должен корректно создавать или обновлять заказ, передавать сведения в кассу при необходимости и попадать в отчетность. Для СБП отдельно проверьте подтверждение оплаты и выпуск чека; детали собраны в материале «Кассовый чек при оплате через СБП: правила пробития, отправка в ОФД и частые ошибки».

Наконец, запросите тестовую среду. Без тестовых операций нельзя проверить отказ, отмену, полный и частичный возврат, повторное уведомление и поведение сайта при задержке ответа.

Критерии выбора: что сравнить до договора

Критерий Что проверить Что выбрать или настроить
Интеграция Модуль CMS, виджет, платежная страница, API, webhook Для типового магазина — поддерживаемый модуль; для нестандартной логики — API с серверной обработкой статусов.
Методы оплаты Карты, СБП, ссылки, повторные списания, отмены и возвраты Подключайте только методы, которые проходят весь путь от оплаты до учета.
Webhook и API Проверка подписи, повторная доставка, запрос статуса операции Обрабатывайте уведомление один раз по ID события или операции; спорный статус уточняйте через API.
Фискализация Кто передает состав заказа, сумму, контакт и статус оплаты в ККТ Настройте автоматическую передачу данных вместо ручного пробития чеков.
Возвраты Отмена до списания, полный и частичный возврат Протестируйте операции и проверьте их отражение в заказе, кассе и учете.
Сверка и выплаты Реестры, ID платежа, комиссии, график выплат, выгрузки Сопоставляйте заказ, транзакцию, чек, комиссию, возврат и выплату по идентификаторам.
Поддержка Граница ответственности сайта, провайдера, кассового сервиса До запуска зафиксируйте контакты и порядок эскалации по платежным сбоям.

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

Безопасная обработка API и webhook

Webhook — это серверное уведомление от платежного провайдера о смене статуса операции. Браузерный редирект покупателя на success-страницу не подтверждает оплату: клиент мог закрыть страницу, вернуться позже или открыть ее повторно.

  1. Получите уведомление на сервере. Не меняйте статус заказа кодом на фронтенде.
  2. Проверьте подпись уведомления. Сверьте ее по секрету и алгоритму из документации провайдера. Уведомление с неверной подписью не обрабатывайте.
  3. Сохраните ID события и ID операции. Они понадобятся для поиска платежа, сверки и защиты от дублей.
  4. Обрабатывайте событие идемпотентно. Если то же уведомление пришло повторно, не выдавайте товар, доступ или чек второй раз.
  5. Запросите статус через API при споре. При тайм-ауте, неизвестном статусе, повторном callback или расхождении в данных получите финальный статус операции у провайдера.
  6. Только затем меняйте заказ. После подтвержденного успешного платежа запускайте выдачу, доступ или передачу данных в кассовую интеграцию.

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

Пошаговый запуск интернет-эквайринга на сайте

  1. Опишите путь денег. Зафиксируйте момент оплаты, момент выдачи, варианты отмены, полного и частичного возврата, а для подписки — правила продления и отключения.
  2. Подготовьте данные для подключения. Провайдер обычно запрашивает реквизиты компании, расчетный счет, описание товаров или услуг и публичные страницы сайта.
  3. Выберите интеграцию. Установите модуль CMS либо передайте разработчику API-ключи, документацию по webhook и список сценариев.
  4. Настройте кассу. Проверьте передачу позиций заказа, суммы, контакта покупателя и подтвержденного статуса платежа. Для интернет-магазина используйте инструкцию по выбору и подключению облачной онлайн-кассы.
  5. Настройте webhook. Добавьте проверку подписи, журналирование события, обработку дублей и запрос статуса через API при неясном результате.
  6. Пройдите тесты. Выполните успешную оплату, отказ, отмену до списания, полный возврат, частичный возврат, повторную оплату и повторную доставку webhook.
  7. Откройте оплату после сверки. Сопоставьте результаты тестов в заказах, личном кабинете провайдера, кассе и учетной системе.

Как сверять платежи, комиссии и выплаты

Сверяйте не только успешные оплаты. Ежедневно выгружайте реестр платежного провайдера и проверяйте все статусы: успешные операции, отказы, отмены, возвраты и платежи в обработке.

  • Платежи: номер заказа, ID транзакции, сумма, метод оплаты, дата и итоговый статус.
  • Возвраты: ID исходного платежа, сумма возврата, дата, статус и отражение в заказе и учете.
  • Комиссии: удержание провайдера по операциям и его соответствие условиям договора.
  • Выплаты: дата и сумма зачисления на расчетный счет, состав выплатного реестра и связанные операции.
  • Кассовые документы: наличие и корректная привязка к расчету там, где чек требуется.

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

Типичные ошибки при запуске

  • Заказ получает статус «оплачен» после редиректа. Исправление: меняйте статус только по подтвержденному webhook или после запроса статуса через API.
  • Webhook принимается без проверки подписи. Исправление: проверяйте подпись по секрету провайдера до любых действий с заказом.
  • Повторный callback создает повторную выдачу или чек. Исправление: храните ID события и операции, а повторные события обрабатывайте без повторного выполнения бизнес-действия.
  • В кассу уходит только общая сумма. Исправление: передавайте состав заказа и нужные реквизиты из CMS, CRM или бэкенда.
  • Возврат есть у провайдера, но отсутствует в учете. Исправление: сверяйте возврат одновременно в кабинете, заказе, кассовой и учетной системах.
  • Сайт хранит данные карты для подписки. Исправление: используйте привязку карты на стороне провайдера и храните у себя только технический идентификатор, необходимый для API.
  • Нет владельца сверки. Исправление: назначьте сотрудника и регламент ежедневной проверки платежей, возвратов, комиссий и выплат.

Что сделать перед стартом: короткий чеклист

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

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

Нужна ли онлайн-касса вместе с интернет-эквайрингом для сайта?

Да, если по вашему расчету требуется кассовый чек по 54-ФЗ. Платежный провайдер не заменяет ККТ: заранее настройте передачу данных о расчете в кассу и ОФД.

Можно ли подключить интернет-эквайринг без сайта на CMS?

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

Что важнее при выборе: комиссия или удобство интеграции?

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

Нужно ли тестировать возврат перед запуском?

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

Можно ли хранить данные карты клиента на своем сайте для подписки?

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

Почему дата оплаты не совпадает с датой поступления денег на расчетный счет?

Это нормально: платеж подтверждается в момент оплаты, а выплата приходит по графику провайдера. В сверке ведите отдельно дату и ID платежа, сумму комиссии, дату и сумму выплаты, а также связанные возвраты.

Нужен запуск интернет-эквайринга для интернет-магазина, сервиса или продаж по ссылке? Оставьте заявку в Интернет Касса. Подберем схему приема карт и СБП, проверим готовность сайта и кассы, определим состав работ по интеграции или аудиту действующей схемы и дадим список тестов. Для старта приложите адрес сайта, CMS или описание разработки, способы оплаты, наличие кассы и учетной системы, а также сценарии подписки, предоплаты и возвратов.