Способы оплаты и провайдеры
TL;DR: способ оплаты — продуктовое решение для checkout, провайдер — инфраструктурное решение для магазина, и их нельзя подменять друг другом. B2B-расчёты — не «ещё один способ оплаты», а процесс с документами, а split-платежи маркетплейса требуют отдельной схемы взаиморасчётов.
Назначение страницы
Заголовок раздела «Назначение страницы»Страница помогает выбрать состав способов и провайдера под модель проекта (обзор моделей). Правило двух вопросов перед любым выбором: «что платит покупатель» (способ) и «кто и как принимает» (провайдер и схема расчётов). Общая рамка контура — в обзоре платежей.
B2C-способы
Заголовок раздела «B2C-способы»- Карты и «Мир» — базовый способ; требует эквайринга, для онлайн-оплаты — поддержки 3-D Secure (см. жизненный цикл платежа). Работает у всех провайдеров, но комиссии и правила диспутов различаются.
- СБП и универсальный платёжный код (УПК) — важно различать термины: QR-код — это носитель реквизитов, СБП — платёжная схема со своими правилами и реестрами. Один и тот же QR может использоваться в разных схемах, поэтому «оплата по QR» сама по себе не описывает схему расчётов и не равна СБП.
- Pay-сервисы банков — фирменные кнопки оплаты (SberPay, T-Pay и аналоги): сокращают checkout на мобильных, доступны через провайдеров, а не напрямую от банка.
- Платёжные ссылки и QR — оплата вне checkout: в письме, мессенджере, счёте. Полезны для B2B-доплат, дозаказов и оплаты по счёту. Ссылка — способ привязать оплату к заказу, а не отдельная схема расчётов: расчётным способом остаётся тот, которым реально пришёл платёж.
- Рекуррентные платежи — списания по сохранённому токену: подписки, регулярные поставки. Требуют отдельного согласия покупателя и поддержки у провайдера.
- Кредит, рассрочка, BNPL — заёмщик разбивает платёж; продавец получает сумму целиком от BNPL-партнёра, а взаиморасчёты с ним идут по своим реестрам (см. жизненный цикл платежа).
- Оплата при получении — наличные или карта на точке выдачи: деньги принимает логистический оператор, и кассовые события зависят от договора с ним (роль агента — требует проверки бухгалтером/юристом; см. фискализацию и доставку).
Как выбирать способ
Заголовок раздела «Как выбирать способ»Критерии добавления каждого способа: доля мобильного трафика (Pay-кнопки и СБП), наличие подписок (рекурренты), средний чек и цель (BNPL повышает конверсию на дорогих товарах), география выдачи (оплата при получении), готовность к сверке нового реестра. Добавление — не только кнопка в checkout, но и: статус, уведомление, чек по признаку расчёта, реестр и сверка. Чем меньше способов, тем проще сверка; расширять состав стоит под измеренный спрос аудитории.
Порядок внедрения
Заголовок раздела «Порядок внедрения»- Минимальный состав: карты + один «мобильный» способ под трафик.
- Проверить работу статусов и чеков по каждому способу на реальных заказах.
- Добавить BNPL/рассрочку, если средний чек и аудитория этому соответствуют.
- Добавлять нишевые способы только под измеренный спрос, а не «на всякий случай».
B2B-расчёты
Заголовок раздела «B2B-расчёты»Счёт, платёжное поручение, безналичная оплата, отсрочка платежа, кредитный лимит, дебиторка — это процесс, а не способ оплаты:
- Счёт — документ с реквизитами и составом; в ЭДО или как PDF. PDF здесь — представление, юридическая значимость зависит от способа подписания (см. фискализацию и ЭДО).
- Платёжное поручение — контрагент платит сам со своего счёта; магазин узнаёт о платеже из выписки, а не из браузера покупателя.
- Отсрочка и лимит — решение о кредитном риске: лимит на контрагента, контроль просроченной дебиторки, блокировка новых заказов при превышении.
- Сверка дебиторки — сопоставление счетов, платежей и отгрузок; расхождения — норма процесса, а не авария.
| Элемент B2B-процесса | Кто инициирует | Что маршрутизирует | Что даёт магазину |
|---|---|---|---|
| Счёт | Магазин | Ваши банковские реквизиты | Основание платежа |
| Платёжное поручение | Покупатель | Банковские реквизиты магазина | Подтверждение оплаты в выписке |
| Отсрочка | Договор | Условия договора | Управление риском |
| Лимит | Политика магазина | Бюджет контрагента | Контроль кредиторской нагрузки |
| Дебиторка | Оба | Взаиморасчёты | Прогноз поступлений |
Гибрид «счёт с онлайн-оплатой» (платёжная ссылка в счёте) закрывает часть ручной работы, но не отменяет документы: счёт и подтверждение оплаты остаются разными сущностями. Общая логика B2B-модели — в B2B-портале и опте.
Маркетплейс: split-платежи
Заголовок раздела «Маркетплейс: split-платежи»Когда платят сразу нескольким продавцам, нужен split: платёж покупателя делится между продавцами и платформой (комиссия), выплаты идут отдельно. Требования: поддержка провайдером платформенной схемы, распределение сумм и возвратов по продавцам, реестры по каждому продавцу. Схема и юридические роли — в модели маркетплейса; сверка реестров — в жизненном цикле платежа.
Сравнение провайдеров
Заголовок раздела «Сравнение провайдеров»Сравнение по возможностям и ограничениям, без цен: конкретные условия, комиссии и лимиты проверяются у провайдера на момент проекта.
| Провайдер | Типичные сценарии | Форма интеграции | Чеки | Возвраты | Реестры/расчёты |
|---|---|---|---|---|---|
| YooKassa | B2C-магазины, подписки, платформенные решения | API, hosted-форма, виджеты | Фискализация через провайдера или внешнюю ККТ | Полные и частичные, через API и кабинет | Split-платежи для платформ |
| CloudPayments | B2C, карты, Pay-кнопки, мобильные SDK | API, SDK (web/мобильные), hosted-форма | Передача данных для чеков; интеграция с ККТ | Полные и частичные через API | Мультирасчёты между участниками |
| Robokassa | B2C-магазины малого и среднего размера | Hosted-форма, API | Встроенная фискализация | Возвраты через API | Зависит от конфигурации |
| Т-Банк | B2C в экосистеме банка, СБП, рассрочки | API, hosted-форма | Интеграция с кассовыми сервисами | Полные и частичные через API | Схемы расчётов в экосистеме банка |
| Сбер | СБП и QR-оплата (Плати QR), эквайринг | API, QR/ссылки | Через кассовые сервисы эквайринга | По правилам эквайринга | Реестры по эквайрингу |
Ограничения, которые стоит проверять в каждом проекте: какие способы реально доступны для вашего типа бизнеса и договора, поддержка двухстадийных платежей (hold/capture), рекуррентов, возвратов API-методом, фискализации средствами провайдера и готовности к split-схеме. Никакой провайдер не является «лучшим» универсально — выбор фиксируется под сценарии проекта в обзоре контура.
Сопоставление осей B2C и B2B — напутствие перед списком провайдеров: провайдер чаще всего закрывает левую колонку, остальное строит магазин.
| Ось | B2C | B2B |
|---|---|---|
| Что платит покупатель | Карта, СБП, BNPL, Pay-кнопки | Платёжное поручение, онлайн-оплата по ссылке |
| Кто подтверждает оплату | Провайдер (серверное уведомление) | Выписка банка + сверка |
| Главный документ | Чек | Счёт, закрывающие документы, УПД/УКД |
| Риск, которым управляют | Отказы и диспуты эмитентов | Дебиторка и лимит контрагента |
| Сверка | Реестры провайдера и BNPL-партнёра | Сверка со своей ERP и ЭДО-статусами |
Исключения и риски
Заголовок раздела «Исключения и риски»- Способ заявлен в checkout, но не включён у провайдера для вашего договора — заказ падает на оплате; проверять состав способов на живом тестовом заказе по каждому способу.
- BNPL-партнёр выплатил сумму, а спор по товару ушёл в возврат — взаиморасчёт со своим реестром, а не через платёж провайдера; сверка BNPL-реестров обязательна.
- QR-оплата пришла по схеме, не совпадающей с ожидаемой (например, не СБП), — сверка реестров расходится; способ и схема фиксируются по каждому платежу.
- Оплата при получении: чек выписывает логистический оператор или магазин — решается договором, а не кодом.
- Рекуррентный платёж по токену, который покупатель отозвал — попытка падает, а не «списываем без спроса».
- Ссылку на оплату переслали другому покупателю — платёж пришёл без клиентского контекста; связь «платёж → заказ» строится на идентификаторе, а не на интерпретации источника почты.
Критерии выбора
Заголовок раздела «Критерии выбора»- Состав способов под ваш трафик и модели: B2C/B2B/marketplace (см. обзор моделей).
- Нужны ли hold/capture, рекурренты, частичные возвраты API.
- Кто фискализирует: провайдер, ваша ККТ, гибрид.
- Платформенные схемы: split, выплаты, отчётность по продавцам.
- Качество уведомлений и реестров для сверки (см. жизненный цикл платежа).
- Условия договора и комиссии — фиксируются на момент проекта, а не по таблице выше.
Связанные страницы
Заголовок раздела «Связанные страницы»- Платежи, фискализация и финансовые документы — карта платёжного контура и три оси решений.
- Жизненный цикл платежа — статусы, уведомления и сверка по каждому способу.
- Фискализация и финансовые документы — чеки, счёт, УПД/УКД, ЭДО.
- Маркетплейс-агрегатор — модель, под которую нужны split-платежи.
Материалы и источники
Заголовок раздела «Материалы и источники»- Банк России о СБП — схема и правила СБП.
- 161-ФЗ «О национальной платёжной системе» — правовая рамка платёжных операций.
- YooKassa: способы оплаты — состав способов у агрегатора.
- YooKassa: split-платежи — платформенная схема расчётов.
- CloudPayments: API — интеграционные возможности провайдера.
- CloudPayments: Мультирасчёты — расчёты между участниками.
- Robokassa: фискализация — встроенная фискализация.
- Robokassa: возвраты — возвраты через API.
- Т-Банк: интеграции онлайн-платежей — сценарии интеграции.
- Сбер Плати QR — QR-оплата Сбера.