Реалізація 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-платежами. Отримайте консультацію вже сьогодні.