Реализация Split-платежей (расщепление оплаты) на сайте

Реализация Split-платежей (расщепление оплаты) на сайте

Split-платежи — разбивка одной транзакции покупателя на несколько получателей одновременно. Типичный кейс — маркетплейс с 50 продавцами, где каждый заказ нужно разделить между продавцом, платформой и партнёрской программой. Без системы split-платежей бухгалтер тратит 3 часа в день на ручную разноску — с нашей реализацией время сокращается до 15 минут, а 95% возвратов обрабатываются автоматически. Другие сценарии: booking-сервис с комиссией агрегатора, подписка с revenue share между партнёрами.

Мы проектируем и реализуем split-платежи под ключ: от выбора провайдера до мониторинга и фискализации. Реализация занимает от 5 до 14 рабочих дней в зависимости от количества получателей, логики распределения и используемого платёжного провайдера. Закажите аудит вашей платёжной системы — найдём узкие места и предложим оптимальное решение.

Почему split-платежи требуют правильной архитектуры?

Некорректное расщепление приводит к финансовым расхождениям, проблемам с рефандами и налоговым рискам. Например, если не использовать transfer_group в Stripe, при возврате трансферы не отменяются автоматически, и деньги могут потеряться. Архитектура должна учитывать обработку ошибок, округление копеек и мониторинг. Наши инженеры с 10-летним опытом строят надёжные схемы, которые экономят до 20% времени на бухгалтерию.

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

Есть два принципиально разных подхода — Charge + Transfer и Direct Charge, и выбор между ними определяет всё остальное.

Для большинства маркетплейсов на ранней стадии проще Charge + Transfer — меньше юридической сложности при онбординге продавцов.

Как работает Charge + Transfer в Stripe?

Stripe Connect — де-факто стандарт для split-платежей. Сначала создаём PaymentIntent на полную сумму, затем в обработчике webhook выполняем трансферы:

$paymentIntent = \Stripe\PaymentIntent::create([ 'amount' => $order->total_cents, 'currency' => 'eur', 'payment_method_types' => ['card'], 'metadata' => [ 'order_id' => $order->id, 'split_recipients' => json_encode($order->recipients), ], ]); // В webhook-обработчике public function handlePaymentSucceeded(array $payload): void { $intent = $payload['data']['object']; $recipients = json_decode($intent['metadata']['split_recipients'], true); foreach ($recipients as $recipient) { \Stripe\Transfer::create([ 'amount' => $recipient['amount_cents'], 'currency' => $intent['currency'], 'destination' => $recipient['stripe_account_id'], 'transfer_group' => $intent['transfer_group'], 'source_transaction' => $intent['charges']['data'][0]['id'], ]); } } 

transfer_group связывает все трансферы с исходным платежом — это критично для корректного рефанда. source_transaction гарантирует, что трансфер выполняется только из средств конкретного платежа, а не из общего баланса. Подробнее о механизме — в документации Stripe Connect: Charge Transfers.

Хранение конфигурации расщепления

Правила split хранятся в БД, не в коде — иначе каждое изменение комиссии требует деплоя. Пример схемы: таблица split_rules с полями entity_type, entity_id, rule_type (percentage, fixed, remainder), value, priority. Расчёт долей происходит перед созданием трансферов, причём правило remainder должно быть ровно одно — это защита от округления и накопленных ошибок. Сумма долей обязана совпадать с total до копейки.

class SplitCalculator { public function calculate(int $totalCents, array $rules): array { $allocated = 0; $result = []; // Сначала фиксированные суммы foreach ($rules as $rule) { if ($rule['rule_type'] === 'fixed') { $result[] = ['recipient' => $rule['entity_id'], 'amount' => $rule['value']]; $allocated += $rule['value']; } } // Затем процентные foreach ($rules as $rule) { if ($rule['rule_type'] === 'percentage') { $amount = (int) round($totalCents * $rule['value'] / 100); $result[] = ['recipient' => $rule['entity_id'], 'amount' => $amount]; $allocated += $amount; } } // Остаток — платформе или last-in-line получателю $remainder = $totalCents - $allocated; foreach ($rules as $rule) { if ($rule['rule_type'] === 'remainder') { $result[] = ['recipient' => $rule['entity_id'], 'amount' => $remainder]; break; } } return $result; } } 

Как обрабатывать возвраты при split-платежах?

Возврат при расщеплённом платеже — самое болезненное место. Stripe автоматически не отзывает трансферы при рефанде на PaymentIntent — это нужно делать явно. Алгоритм: 1) рефанд основного платежа, 2) реверс трансферов пропорционально сумме возврата. Если на аккаунте получателя недостаточно средств для реверса, Stripe вернёт ошибку — тогда требуется ручное дебетование.

public function refund(Order $order, int $refundCents): void { // 1. Рефанд основного платежа \Stripe\Refund::create([ 'payment_intent' => $order->stripe_payment_intent_id, 'amount' => $refundCents, 'refund_application_fee' => true, ]); // 2. Реверс трансферов пропорционально $ratio = $refundCents / $order->total_cents; foreach ($order->transfers as $transfer) { $reverseAmount = (int) round($transfer->amount_cents * $ratio); \Stripe\Transfer::createReversal($transfer->stripe_transfer_id, [ 'amount' => $reverseAmount, 'refund_application_fee' => true, ]); } } 

Типичные ошибки при возвратах

• Забыли отменить refund_application_fee – платформа теряет комиссию.
• Неверно рассчитали пропорцию из-за округления – копеечные расхождения накапливаются.
• Не обработали частичный возврат, когда перевод уже реверсирован частично.

Альтернативы Stripe

В среднем интеграция с Stripe Connect даёт на 30% больше контроля над транзакциями, чем аналоги CloudPayments, но требует больше времени на настройку. Выбор провайдера зависит от географии и требований к фискализации.

Что делать при расхождениях в мониторинге?

Каждый день запускается reconciliation job — сравнение сумм трансферов в БД с реальными трансферами в Stripe через API. Расхождения уходят в алерт. Это не паранойя — webhook-и иногда теряются, особенно при деплоях в момент транзакции. Настроив мониторинг, вы сократите финансовые потери от таких сбоев на 10–15%.

$stripeTransfers = \Stripe\Transfer::all([ 'created' => ['gte' => $yesterday->timestamp, 'lt' => $today->timestamp], 'limit' => 100, ]); $dbTransfers = Transfer::whereDate('created_at', $yesterday)->get()->keyBy('stripe_id'); foreach ($stripeTransfers->autoPagingIterator() as $transfer) { if (!isset($dbTransfers[$transfer->id])) { Log::critical('Untracked transfer', ['stripe_id' => $transfer->id, 'amount' => $transfer->amount]); } } 

Что входит в работу по реализации split-платежей

• Анализ бизнес-логики и выбор оптимальной модели расщепления.
• Интеграция с платёжным провайдером (Stripe, CloudPayments, YooKassa).
• Настройка правил распределения и хранение в БД.
• Реализация обработки рефандов и реверсов трансферов.
• Настройка webhook-ов и мониторинга.
• Документация API и инструкции для бухгалтерии.
• Обучение команды работе с платёжной системой.
• Поддержка после запуска (1 месяц).

Налоговые и юридические аспекты

Расщепление платежа не освобождает платформу от фискальных обязательств — в большинстве юрисдикций платформа является налоговым агентом. Это означает передачу данных о выплатах в налоговые органы (в РФ — ФНС, в ЕС — DAC7 reporting). Нужно учитывать это при проектировании схемы split ещё на старте — переделывать потом дороже. Обратите внимание на требования DAC7 Directive при работе в Европе.

Свяжитесь с нами для оценки вашего проекта — мы поможем выбрать оптимальное решение и реализуем его в кратчайшие сроки. Наш опыт — 5+ лет в разработке платёжных систем, более 15 успешных проектов с split-платежами. Получите консультацию уже сегодня.