Платёжная стратегия маркетплейса: как не потерять деньги на старте

Почему платёжная архитектура — не технический вопрос

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

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

Маркетплейс vs. платформа: в чём разница для платежей

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

Разница принципиальна: она определяет, кто в глазах покупателя является продавцом, кто отвечает за возврат и доставку, кто несёт ответственность при невыполнении заказа. Это напрямую связано с понятием Merchant of Record (MoR) — юридического продавца в транзакции. От того, кто выступает MoR — платформа или сам продавец — зависит вся архитектура платёжного потока, онбординг и распределение рисков.

Как бизнес-модель определяет поток средств

В простой схеме деньги покупателя идут напрямую на счёт продавца, а платформа получает комиссию отдельно. Платформа не контролирует средства продавца — это снижает регуляторную нагрузку.

В более сложной модели средства сначала поступают на счёт платформы или её провайдера, а затем распределяются: часть — платформе в виде комиссии, часть — продавцу. Например: покупатель платит 10 000 рублей, платформа удерживает 1 000 в качестве комиссии, продавец получает 9 000. При этом платформа может держать резервы, вычитать возвраты, делить платёж между несколькими продавцами.

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

Онбординг продавцов: это не просто регистрация

Как только платформа позволяет независимым продавцам принимать платежи, возникает вопрос: кто и как их верифицирует? Тип юридического лица, страна регистрации, статус физлица или компании — всё это влияет на то, какие данные нужно собирать и как проходит KYC/KYB.

Есть два основных подхода:

• Провайдер ведёт онбординг — PSP сам собирает и верифицирует данные. Платформа снижает операционную нагрузку, но теряет контроль над UX.
• Платформа ведёт онбординг — больше контроля над опытом продавца, но больше ответственности за соблюдение требований.

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

Сплит, выплаты и чарджбеки: детали, которые решают всё

После того как платёж принят, платформа должна чётко определить:

• Когда и как продавец получает деньги — сразу после расчёта, по расписанию или с задержкой в зависимости от риск-профиля.
• Кто инициирует возвраты — платформа, продавец или оба.
• Как обрабатываются чарджбеки — централизованно через платформу или продавец разбирается напрямую с провайдером.
• Как распределяются комиссии за обработку — платформа берёт на себя, вычитает из выплат продавцу или перекладывает на покупателя.

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

Фрод: угроза не только со стороны покупателей

Антифрод на маркетплейсе — это не только проверка покупателей. Мошеннические продавцы могут генерировать возвраты и чарджбеки в промышленных масштабах, нанося репутационный и финансовый ущерб платформе. Поэтому скрининг должен работать на обоих уровнях: транзакционном (легитимен ли платёж) и мерчантском (легитимен ли сам продавец).

Как это работает в контексте рублёвых платежей через СБП

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

Платформы вроде MultiFlow решают именно эту задачу: маршрутизация каждого платежа через пул провайдеров с автоматическим переключением при отказе даёт стабильный приём и высокую конверсию. Баланс мерчанта доступен для вывода, в том числе в USDT — что критично для обменников и P2P-бизнесов.

Вывод: архитектуру нужно проектировать до первой транзакции

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

Начинайте с модели, а не с провайдера. Провайдер подбирается под архитектуру, а не наоборот.

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