Эквайринг для маркетплейса: почему стандартное решение здесь не работает

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

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

Если схема расчётов вашего маркетплейса собрана из ручных выгрузок, трёх разных сервисов и договорённостей «на честном слове» — проблема не в людях. Вы изначально взяли инструмент не для той задачи.

Маркетплейс — это не интернет-магазин с большим каталогом

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

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

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

Сплит-платежи — это не опция, а обязательное условие

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

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

Правильный эквайринг поддерживает автоматическое распределение на уровне API: площадка передаёт параметры сплита вместе с запросом на оплату, система сама разносит деньги по получателям.

Онбординг продавцов: где тормозит весь рынок

Если площадка работает с физическими продавцами, самозанятыми или небольшими ИП, возникает ещё одна проблема. Крупные банковские эквайринги ориентированы на юрлица с историей и оборотами. Самозанятому там либо откажут, либо предложат заполнить двадцать форм и ждать две недели.

Для маркетплейса это критично. Если каждый новый продавец проходит тяжёлый банковский онбординг, платформа теряет продавцов ещё до старта.

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

Возвраты на маркетплейсе работают иначе, чем в магазине

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

На маркетплейсе покупатель вернул товар одного продавца из заказа, где было трое. Площадка возвращает деньги покупателю, одновременно списывает их у конкретного продавца и пересчитывает свою комиссию. Если сплит уже прошёл и деньги разошлись по счетам, нужно либо забирать их у продавца обратно, либо покрывать возврат из резервного фонда площадки.

Стандартный эквайринг об этом не знает. Он видит транзакцию и делает возврат суммы. Что происходит дальше с распределением — не его задача. Результат: площадка вручную разбирает каждый возврат, копит операционные расходы и ошибки.

Эквайринг для маркетплейса должен поддерживать частичные возвраты с пересчётом сплита на уровне платёжного API. Без этого масштабирование упирается в операционный потолок.

Комиссионная модель: площадка зарабатывает на марже, а не на обороте

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

Это важно по двум причинам. Финансовая: если площадка сначала перечисляет продавцу полную сумму, а потом пытается получить свою комиссию, возникают кассовые разрывы и риск невозврата. Техническая: ручное удержание комиссий не масштабируется.

Нормальная схема: в запросе на выплату продавцу передаётся параметр комиссии, система автоматически удерживает её в пользу площадки и переводит продавцу чистую сумму. Эта логика должна быть встроена в эквайринг на уровне API, а не реализовываться отдельным скриптом на стороне площадки.

Антифрод на маркетплейсе — двухуровневая задача

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

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

URLPAY включает антифрод-мониторинг с автоматической блокировкой подозрительных транзакций. Без этого платёжная система рискует получить претензии от банков-эквайеров и потерять возможность проводить платежи. Требования к безопасности здесь не опциональны: PCI DSS, 3-D Secure и токенизация карт — минимум, без которого подключение к серьёзным каналам оплаты закрыто.

Массовые выплаты: функция, которую часто упускают при выборе

Когда продавцов больше 30–50, ручные переводы становятся еженедельным кошмаром. Финансовый отдел делает 200 транзакций вручную, ошибается, продавцы пишут в поддержку.

Массовые выплаты — это API-метод, который отправляет одним запросом выплаты сразу нескольким получателям с нужными суммами, реквизитами и метками. Площадка формирует реестр, передаёт в систему, система обрабатывает.

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

Что проверить до подключения

Перед выбором эквайринга для маркетплейса ответьте на четыре вопроса. Поддерживает ли решение сплит-платежи на уровне API или это придётся строить самостоятельно. Как устроен онбординг продавцов и работает ли он с самозанятыми. Есть ли встроенная логика возвратов с пересчётом комиссии. Доступны ли массовые выплаты в реестровом режиме.

Если хоть один пункт требует ручной работы или дополнительной разработки — это не решение для маркетплейса. Это решение для магазина, которое кто-то применил не по назначению.

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

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

URLPAY закрывает карты, СБП, QR и платёжные ссылки через одну интеграцию. Мерчант подключается от одного дня. Документация и песочница доступны сразу, без звонков и переговоров.

Если архитектура платежей вашего маркетплейса ещё не закрыта — начните с документации: urlpay.io/docs/api. Там же можно оставить заявку на подключение.