---
title: Способы оплаты и провайдеры
description: B2C-способы оплаты, B2B-расчёты и split-платежи маркетплейса; сравнение провайдеров по возможностям и ограничениям.
---

TL;DR: способ оплаты — продуктовое решение для checkout, провайдер — инфраструктурное решение для магазина, и их нельзя подменять друг другом. B2B-расчёты — не «ещё один способ оплаты», а процесс с документами, а split-платежи маркетплейса требуют отдельной схемы взаиморасчётов.

## Назначение страницы

Страница помогает выбрать состав способов и провайдера под модель проекта ([обзор моделей](https://wpcraft.ru/kb/practices/ecommerce/models.md)). Правило двух вопросов перед любым выбором: «что платит покупатель» (способ) и «кто и как принимает» (провайдер и схема расчётов). Общая рамка контура — в [обзоре платежей](https://wpcraft.ru/kb/practices/ecommerce/payments.md).

## B2C-способы

- **Карты и «Мир»** — базовый способ; требует эквайринга, для онлайн-оплаты — поддержки 3-D Secure (см. [жизненный цикл платежа](https://wpcraft.ru/kb/practices/ecommerce/payments/payment-lifecycle.md)). Работает у всех провайдеров, но комиссии и правила диспутов различаются.
- **СБП и универсальный платёжный код (УПК)** — важно различать термины: QR-код — это носитель реквизитов, СБП — платёжная схема со своими правилами и реестрами. Один и тот же QR может использоваться в разных схемах, поэтому «оплата по QR» сама по себе не описывает схему расчётов и не равна СБП.
- **Pay-сервисы банков** — фирменные кнопки оплаты (SberPay, T-Pay и аналоги): сокращают checkout на мобильных, доступны через провайдеров, а не напрямую от банка.
- **Платёжные ссылки и QR** — оплата вне checkout: в письме, мессенджере, счёте. Полезны для B2B-доплат, дозаказов и оплаты по счёту. Ссылка — способ привязать оплату к заказу, а не отдельная схема расчётов: расчётным способом остаётся тот, которым реально пришёл платёж.
- **Рекуррентные платежи** — списания по сохранённому токену: подписки, регулярные поставки. Требуют отдельного согласия покупателя и поддержки у провайдера.
- **Кредит, рассрочка, BNPL** — заёмщик разбивает платёж; продавец получает сумму целиком от BNPL-партнёра, а взаиморасчёты с ним идут по своим реестрам (см. [жизненный цикл платежа](https://wpcraft.ru/kb/practices/ecommerce/payments/payment-lifecycle.md)).
- **Оплата при получении** — наличные или карта на точке выдачи: деньги принимает логистический оператор, и кассовые события зависят от договора с ним (роль агента — требует проверки бухгалтером/юристом; см. [фискализацию](https://wpcraft.ru/kb/practices/ecommerce/payments/fiscalization-and-documents.md) и [доставку](https://wpcraft.ru/kb/practices/ecommerce/logistics/delivery-integration.md)).

### Как выбирать способ

Критерии добавления каждого способа: доля мобильного трафика (Pay-кнопки и СБП), наличие подписок (рекурренты), средний чек и цель (BNPL повышает конверсию на дорогих товарах), география выдачи (оплата при получении), готовность к сверке нового реестра. Добавление — не только кнопка в checkout, но и: статус, уведомление, чек по признаку расчёта, реестр и сверка. Чем меньше способов, тем проще сверка; расширять состав стоит под измеренный спрос аудитории.

### Порядок внедрения

1. Минимальный состав: карты + один «мобильный» способ под трафик.
2. Проверить работу статусов и чеков по каждому способу на реальных заказах.
3. Добавить BNPL/рассрочку, если средний чек и аудитория этому соответствуют.
4. Добавлять нишевые способы только под измеренный спрос, а не «на всякий случай».

## B2B-расчёты

Счёт, платёжное поручение, безналичная оплата, отсрочка платежа, кредитный лимит, дебиторка — это процесс, а не способ оплаты:

1. **Счёт** — документ с реквизитами и составом; в ЭДО или как PDF. PDF здесь — представление, юридическая значимость зависит от способа подписания (см. [фискализацию и ЭДО](https://wpcraft.ru/kb/practices/ecommerce/payments/fiscalization-and-documents.md)).
2. **Платёжное поручение** — контрагент платит сам со своего счёта; магазин узнаёт о платеже из выписки, а не из браузера покупателя.
3. **Отсрочка и лимит** — решение о кредитном риске: лимит на контрагента, контроль просроченной дебиторки, блокировка новых заказов при превышении.
4. **Сверка дебиторки** — сопоставление счетов, платежей и отгрузок; расхождения — норма процесса, а не авария.

| Элемент B2B-процесса | Кто инициирует | Что маршрутизирует | Что даёт магазину |
| --- | --- | --- | --- |
| Счёт | Магазин | Ваши банковские реквизиты | Основание платежа |
| Платёжное поручение | Покупатель | Банковские реквизиты магазина | Подтверждение оплаты в выписке |
| Отсрочка | Договор | Условия договора | Управление риском |
| Лимит | Политика магазина | Бюджет контрагента | Контроль кредиторской нагрузки |
| Дебиторка | Оба | Взаиморасчёты | Прогноз поступлений |

Гибрид «счёт с онлайн-оплатой» (платёжная ссылка в счёте) закрывает часть ручной работы, но не отменяет документы: счёт и подтверждение оплаты остаются разными сущностями. Общая логика B2B-модели — в [B2B-портале и опте](https://wpcraft.ru/kb/practices/ecommerce/models/b2b-portal-wholesale.md).

## Маркетплейс: split-платежи

Когда платят сразу нескольким продавцам, нужен split: платёж покупателя делится между продавцами и платформой (комиссия), выплаты идут отдельно. Требования: поддержка провайдером платформенной схемы, распределение сумм и возвратов по продавцам, реестры по каждому продавцу. Схема и юридические роли — в [модели маркетплейса](https://wpcraft.ru/kb/practices/ecommerce/models/marketplace-aggregator.md); сверка реестров — в [жизненном цикле платежа](https://wpcraft.ru/kb/practices/ecommerce/payments/payment-lifecycle.md).

## Сравнение провайдеров

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

| Провайдер | Типичные сценарии | Форма интеграции | Чеки | Возвраты | Реестры/расчёты |
| --- | --- | --- | --- | --- | --- |
| 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-схеме. Никакой провайдер не является «лучшим» универсально — выбор фиксируется под сценарии проекта в [обзоре контура](https://wpcraft.ru/kb/practices/ecommerce/payments.md).

Сопоставление осей B2C и B2B — напутствие перед списком провайдеров: провайдер чаще всего закрывает левую колонку, остальное строит магазин.

| Ось | B2C | B2B |
| --- | --- | --- |
| Что платит покупатель | Карта, СБП, BNPL, Pay-кнопки | Платёжное поручение, онлайн-оплата по ссылке |
| Кто подтверждает оплату | Провайдер (серверное уведомление) | Выписка банка + сверка |
| Главный документ | Чек | Счёт, закрывающие документы, УПД/УКД |
| Риск, которым управляют | Отказы и диспуты эмитентов | Дебиторка и лимит контрагента |
| Сверка | Реестры провайдера и BNPL-партнёра | Сверка со своей ERP и ЭДО-статусами |


## Исключения и риски

- Способ заявлен в checkout, но не включён у провайдера для вашего договора — заказ падает на оплате; проверять состав способов на живом тестовом заказе по каждому способу.
- BNPL-партнёр выплатил сумму, а спор по товару ушёл в возврат — взаиморасчёт со своим реестром, а не через платёж провайдера; сверка BNPL-реестров обязательна.
- QR-оплата пришла по схеме, не совпадающей с ожидаемой (например, не СБП), — сверка реестров расходится; способ и схема фиксируются по каждому платежу.
- Оплата при получении: чек выписывает логистический оператор или магазин — решается договором, а не кодом.
- Рекуррентный платёж по токену, который покупатель отозвал — попытка падает, а не «списываем без спроса».
- Ссылку на оплату переслали другому покупателю — платёж пришёл без клиентского контекста; связь «платёж → заказ» строится на идентификаторе, а не на интерпретации источника почты.

## Критерии выбора

1. Состав способов под ваш трафик и модели: B2C/B2B/marketplace (см. [обзор моделей](https://wpcraft.ru/kb/practices/ecommerce/models.md)).
2. Нужны ли hold/capture, рекурренты, частичные возвраты API.
3. Кто фискализирует: провайдер, ваша ККТ, гибрид.
4. Платформенные схемы: split, выплаты, отчётность по продавцам.
5. Качество уведомлений и реестров для сверки (см. [жизненный цикл платежа](https://wpcraft.ru/kb/practices/ecommerce/payments/payment-lifecycle.md)).
6. Условия договора и комиссии — фиксируются на момент проекта, а не по таблице выше.

## Связанные страницы

- [Платежи, фискализация и финансовые документы](https://wpcraft.ru/kb/practices/ecommerce/payments.md) — карта платёжного контура и три оси решений.
- [Жизненный цикл платежа](https://wpcraft.ru/kb/practices/ecommerce/payments/payment-lifecycle.md) — статусы, уведомления и сверка по каждому способу.
- [Фискализация и финансовые документы](https://wpcraft.ru/kb/practices/ecommerce/payments/fiscalization-and-documents.md) — чеки, счёт, УПД/УКД, ЭДО.
- [Маркетплейс-агрегатор](https://wpcraft.ru/kb/practices/ecommerce/models/marketplace-aggregator.md) — модель, под которую нужны split-платежи.

## Материалы и источники

- [Банк России о СБП](https://www.cbr.ru/PSystem/sfp/) — схема и правила СБП.
- [161-ФЗ «О национальной платёжной системе»](https://www.cbr.ru/PSystem/acts/161-fz/) — правовая рамка платёжных операций.
- [YooKassa: способы оплаты](https://yookassa.ru/developers/payment-acceptance/getting-started/payment-methods) — состав способов у агрегатора.
- [YooKassa: split-платежи](https://yookassa.ru/developers/solutions-for-platforms/split-payments/basics) — платформенная схема расчётов.
- [CloudPayments: API](https://developers.cloudpayments.ru/) — интеграционные возможности провайдера.
- [CloudPayments: Мультирасчёты](https://cloudpayments.ru/payments/multi-calculation-service/) — расчёты между участниками.
- [Robokassa: фискализация](https://docs.robokassa.ru/ru/fiscalization) — встроенная фискализация.
- [Robokassa: возвраты](https://docs.robokassa.ru/ru/refund-api) — возвраты через API.
- [Т-Банк: интеграции онлайн-платежей](https://www.tbank.ru/business/online-payments/develop/) — сценарии интеграции.
- [Сбер Плати QR](https://developers.sber.ru/docs/ru/sber-api/specifications/qr/plati-qr/overview) — QR-оплата Сбера.