Платёжная система: не просто «принять деньги», а распределить их правильно
Обсуждали с коллегами статью про платежные системы для маркетплейсов — и в ней вдруг всплыл момент, который сразу зацепил: не все сервисы умеют правильно распределять деньги, когда покупатель платит за товары сразу у нескольких продавцов. Понял, что это не просто техническая деталь, а фундаментальная уязвимость, если не проработать схему заранее. И это касается почти всех площадок, которые не контролируют процесс от начала до конца.
О чём речь и почему я считаю это важным для сайта
Речь о том, как именно деньги от покупателя доходят до продавцов — и кто за это отвечает. Многие думают: «всё, подключил эквайринг, всё работает». Но если не прописано, как распределять платеж, кто удерживает комиссию, как возвращать часть суммы — в итоге получается хаос. И это не про «случайный сбой», а про системную ошибку в архитектуре. Я считаю, что для маркетплейса это не просто «вопрос удобства» — это вопрос доверия и стабильности. Если продавцы не получают деньги вовремя, или получают с ошибкой — они уйдут. А если покупатель видит, что оплата прошла, но деньги не пришли — он не вернётся.
Сейчас многие площадки строятся на «всё в одном»: платёж, выплаты, чеки. Но если система не умеет правильно сплитовать платежи — всё это ложится на ручной расчёт. А ручной расчёт — это ошибка, задержка, конфликт. И это уже не «технический сбой», а риск для бизнеса.
Как это устроено — что тут вообще происходит
Когда покупатель платит за товары у нескольких продавцов одним платежом, система должна не просто принять деньги, а понять: сколько кому из продавцов, сколько удержать площадке, как оформить возврат, если часть заказа отменена. Это называется сплитование. И не все платёжные сервисы его поддерживают — или делают это с оговорками. Например, один сервис может распределить деньги, но не умеет частичного возврата. Другой — даёт «Безопасную сделку», но только для физлиц. А если у вас юрлица — схема ломается.
Ключевое — не просто подключить платёжку, а понять, кто на кого отвечает. Кто формирует чек? Кто хранит данные? Кто отвечает за возврат? Если ответы не чёткие — в любой момент может возникнуть задержка, ошибка, конфликт. И это не про «случайный баг», а про архитектурный риск.
Как понять, что это касается вашего сайта
Я проверяю это первым делом, когда берусь за маркетплейс. Просто: смотрю, как устроена схема оплаты. Если покупатель платит за несколько товаров — где и как распределяются деньги? Если есть частичный возврат — как он обрабатывается? Если нет чёткого описания — это красный флаг. Особенно если платёжная система не говорит прямо, что поддерживает сплитование и частичные возвраты. Или если в документации написано «поддерживается», но в примерах нет сценария с несколькими продавцами.
Даже если всё «работает», это не значит, что оно надёжно. Я смотрю на то, как реализованы выплаты, возвраты, учёт комиссии. Если это требует ручного вмешательства — это не масштабируемо. И если у вас есть форма заявки — вы уже оператор персональных данных, и это отдельный риск, который не закрываешь за вечер.
Что с этим делать
Что я делаю в таких случаях — начинаю с архитектуры. Сначала прописываю, кто принимает деньги, кто удерживает комиссию, кто выплачивает продавцам. Потом проверяю, как платёжный сервис это реализует. Если нет — ищу решение, которое это умеет. Или пересматриваю схему. Иногда проще изменить модель — например, не принимать оплату от покупателя напрямую, а через платёжный шлюз, который сам распределяет деньги.
Объём работ зависит от того, насколько сложна схема. Если всё просто — оплата, комиссия, выплата — можно подключить за день. Если нужны частичные возвраты, сплитование, чеки — нужно тестировать сценарии. И главное — проверить, как это работает в реальных условиях, а не только в документации.