как выбрать платежный агрегатор для сайта — Платежный агрегатор для сайта выбирают по цепочке «заказ → оплата → подтвержденный статус → чек → возврат → сверка». Сначала проверьте эту цепочку на тестовой операции, а уже потом сравнивайте комиссию. Если статус заказа, операция и чек не связываются автоматически, команда будет вручную разбирать расхождения.
До переговоров опишите свой сценарий: что продаете, когда покупатель платит, когда получает товар или доступ, как оформляет возврат и кто формирует чек. Если одновременно выбираете формат сайта, используйте материал «Сайт с онлайн-оплатой и кассой: лендинг, каталог или интернет-магазин».
Не выбирайте по названию услуги. Интернет-эквайринг — это прием карточных платежей. Агрегатор или платежный провайдер — это модель договора и интеграции, которая может объединять несколько методов оплаты и расчетных процессов. Карты, СБП, платежные ссылки и рекуррентные списания доступны не «по типу сервиса», а в конкретном предложении поставщика.
Берите решение с одной простой интеграцией, если вам нужны только карты или карты с СБП, есть готовый модуль для CMS и не требуется сложная логика подписок. Сравнивайте нескольких провайдеров, если вам нужны платежные ссылки, рекурренты, несколько сайтов, частичные возвраты, API для собственной разработки или единая сверка каналов продаж.
До подписания договора запросите письменные ответы: кто указан получателем денег; какие методы включаются в ваш тариф; когда поступают выплаты; есть ли лимиты, резерв или удержания; как оспариваются операции; можно ли вернуть деньги после выплаты. Базовую схему карточных платежей разбирает статья «Что такое онлайн-эквайринг и как принимать оплату на сайте».
Платежная страница подтверждает перевод денег, но не заменяет кассовый чек. Требования к применению ККТ и сведения о кассовой технике публикует сайт ФНС России. Ваша задача до запуска — закрепить кассовую схему: кто передает данные, кто формирует документ и как контролируется его доставка.
Проверьте передачу позиций корзины, скидок и доставки, серверные уведомления, полный и частичный возврат. При предоплате с последующей отгрузкой отдельно настройте кассовые документы для этапов расчета. Не подключайте оплату, пока тестовый заказ не изменит статус после подтверждения на стороне сервера.
Выберите поставщика, который поддерживает рекуррентные списания для вашей модели. Проверьте получение согласия на списания, отмену подписки, неуспешное списание и повторную попытку, если она предусмотрена правилами сервиса. Доступ не продлевайте, пока не получите подтвержденный статус платежа.
Используйте платежную ссылку, если менеджер создает заказ вручную. В операции должны сохраняться номер заказа, сумма и клиентский идентификатор. Тогда после оплаты менеджер увидит результат в CRM или личном кабинете, а не будет искать перевод по сумме.
Подключайтесь только к провайдеру, который работает с самозанятыми. Чек покупателю формируйте через «Мой налог»; облачную ККТ для этого режима не подключают автоматически. После тестовой покупки проверьте чек по инструкции «Как проверить чек самозанятого на подлинность».
| Критерий | Что запросить и проверить | Стоп-фактор |
|---|---|---|
| Методы оплаты | Карты, СБП, ссылка, рекурренты; условия подключения каждого метода. | Нет метода, которым уже пользуются ваши клиенты. |
| Интеграция | Модуль CMS, API, вебхуки, документация, тестовая среда, журнал событий. | Нет серверных уведомлений или тестового контура. |
| Подтверждение оплаты | Проверка подписи, повторные уведомления, запрос статуса по API. | Заказ можно подтвердить только по редиректу покупателя. |
| Фискализация | Кто передает состав заказа, контакты, признак расчета; какой документ создается при возврате. | Не определен ответственный за чек. |
| Возвраты | Полный и частичный возврат, возврат после выплаты, сроки и статусы по каждому методу. | Нет регламента возврата или его можно провести только неформальным переводом. |
| Выплаты и удержания | График выплат, лимиты, резерв, основания и срок удержаний, реестры операций. | Условия блокировок и удержаний не описаны в договоре. |
| Спорные операции | Порядок оспаривания, chargeback для карточных платежей, документы и сроки ответа. | Нет понятного канала и срока для оспаривания. |
| Сверка и поддержка | Выгрузка реестров, идентификатор заказа, контакты поддержки, порядок эскалации. | Нельзя сопоставить заказ, платеж, выплату и возврат. |
Сделайте копию таблицы и поставьте каждому поставщику оценку: 0 — функции нет, 1 — есть с ручной работой, 2 — закрывает сценарий автоматически. Не допускайте поставщика к финальному сравнению, если он получил ноль по вебхукам, возвратам, выплатам или кассовой схеме.
| Сценарий | Обязательные критерии | Что считать решающим |
|---|---|---|
| Магазин с доставкой | Карты и СБП, корзина, частичный возврат, чек, реестры. | Связка заказа, оплаты, возврата и кассового документа. |
| Подписка | Рекурренты, согласие, отмена, уведомления, обработка отказа. | Безопасное прекращение доступа при неуспешном списании. |
| Лендинг | Ссылка на оплату, API или CRM-интеграция, чек, возврат. | Автоматическая привязка оплаты к номеру заявки. |
Заказ отмечают оплаченным после возврата покупателя из банка. Меняйте статус только по проверенному серверному уведомлению или после сверки статуса через API. Redirect URL нельзя считать доказательством оплаты.
Повторный webhook запускает выдачу товара второй раз. Сохраняйте уникальный идентификатор операции и события, а повторное уведомление завершайте без повторной выдачи, чека или изменения баланса.
В кассу передают только итоговую сумму. Передавайте позиции из корзины, цену, количество и нужные реквизиты. Отдельно тестируйте скидку, доставку, предоплату и возврат.
Возврат делают переводом «вручную» без проверки схемы. Оформляйте возврат по правилам договора и конкретного платежного метода. До запуска проверьте, кто инициирует возврат после выплаты, какой статус получает покупатель и какой кассовый документ формируется.
Сравнивают только комиссию. Сопоставляйте полную стоимость процесса: ставку, сроки выплат, возможный резерв, трудозатраты на сверку, возвраты и поддержку при сбое.
Да, если ваш расчет требует применения ККТ по 54-ФЗ. До запуска определите в договоре и настройках, кто формирует чек, какие данные передаются в кассу и как проверяется отправка чека покупателю.
Да, подключайте оба метода, если их поддерживает выбранный поставщик. В тестовом контуре отдельно проверьте успешную оплату, отказ, возврат на сайт, серверное уведомление и возврат по каждому методу.
Сначала проверьте интеграцию, выплаты, возвраты и фискализацию, затем сравнивайте комиссию. Экономия на ставке не компенсирует ручную обработку заказов, если сервис не передает подтвержденные статусы и не дает провести частичный возврат.
Да, если провайдер подключает самозанятых по своей договорной схеме. Чек покупателю самозанятый формирует через «Мой налог», а порядок выплат и интеграции нужно согласовать до подключения.
Нужна готовая схема приема оплат для вашего сайта? Оставьте заявку в Интернет Касса. На разборе проверим ваш путь «заказ — платеж — чек — возврат», составим матрицу критериев, определим кассовую схему и выдадим список технических работ для разработчика.