Эквайринг для маркетплейса

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

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

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

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

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

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

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

Выплаты отправляются реестром через API — одним запросом на сотни получателей, со статусом по каждому. Доступны переводы на карты, по СБП и в USDT, USDC и Bitcoin по рыночному курсу на момент выплаты. Зачисление от 15 секунд.

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

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

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

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

Фискализация. Если площадка выступает агентом продавца, обязанность выдать чек покупателю обычно ложится на неё, а состав такого чека отличается от чека обычного магазина. Требование зависит от того, что продаётся и на каком налоговом режиме находится продавец, поэтому конструкцию стоит проверить с бухгалтером до запуска.

Персональные данные. Обработка данных покупателей и продавцов подпадает под 152-ФЗ. Карточные данные при этом не попадают на серверы площадки: они токенизируются на нашей стороне, и платформа работает с токеном, а не с номером карты.

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

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

От первого сообщения до тестовой транзакции проходит около 11 минут, продакшн-доступ открываем в среднем за 24 часа. Отдельная онлайн-касса для подключения не требуется. Порядок такой:

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