Реалізація 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 | Direct Charge |
|---|---|---|
| Рух грошей | Кошти надходять на рахунок платформи, потім переводяться продавцям | Покупець платить безпосередньо продавцю, платформа отримує комісію |
| Відповідальність за KYC | Платформа зобов'язана перевіряти продавців | Продавці проходять KYC самостійно |
| Контроль над рефандами | Платформа керує поверненнями централізовано | Повернення — на стороні продавця, платформа може не брати участі |
| Складність інтеграції | Вища, потрібне налаштування webhook-ів та трансферів | Нижча, але потрібна обробка application fee |
| Юридичні ризики | Вищі (платформа — податковий агент) | Нижчі, але потрібен договір з кожним продавцем |
Для більшості маркетплейсів на ранній стадії простіше 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
| Провайдер | Модель split | Гнучкість | Фіскалізація | Регіон |
|---|---|---|---|---|
| Stripe Connect | Charge + Transfer / Direct Charge | Висока | Потрібна окрема | Global |
| CloudPayments | Receipt з кількома отримувачами | Середня | Вбудована | СНД |
| YooKassa Deal | Deal API | Середня | Вбудована | РФ |
| Fondy | Партнерський договір | Низька | На стороні провайдера | Україна |
У середньому інтеграція з 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-платежами. Отримайте консультацію вже сьогодні.