Після запуску модулю виплат без холду баланс продавця на маркетплейсі пішов у мінус на $4.5k–6.5kів через масові повернення. Щоб таке не повторювалося, ми проектуємо системи з ескроу та автоматичними розрахунками. Наша команда з 10+ роками досвіду в фінтехі реалізувала виплатні модулі для 20+ маркетплейсів — від стартапів до платформ з 10 000 продавців. За 10+ років на ринку ми навчилися будувати надійне фінансове ядро, яке витримує тисячі транзакцій на день. Автоматизація виплат продавцям знижує операційні витрати на 40% та виключає помилки ручного введення. Фінансовий контроль маркетплейсу — запорука прозорості та дотримання 115-ФЗ.
У цій статті розберемо ключові компоненти: фінансову модель, життєвий цикл грошей, інтеграцію з платіжними шлюзами, обробку повернень та документообіг. Ви дізнаєтеся, як уникнути типових помилок і побудувати інфраструктуру, що масштабується разом з маркетплейсом.
Автоматизована система виплат: архітектура та ключові модулі
Як влаштований життєвий цикл виплат?
Покупець платить — гроші надходять на рахунок платформи. Платформа утримує комісію (зазвичай 5–15%) і перераховує нетто-суму продавцю. Основні сутності — баланси та транзакції, які зберігаються в базі:
seller_balances (
seller_id,
available_balance,
hold_balance,
total_earned,
currency,
updated_at
)
balance_transactions (
id,
seller_id,
type,
amount,
balance_before,
balance_after,
reference_type,
reference_id,
status,
created_at,
description
)
-- type: order_credit | commission_debit | payout_debit | refund_debit | adjustmentЕтапи руху коштів
- Оплата замовлення — сума за вирахуванням комісії зараховується в
hold_balanceпродавця. - Закінчення холд-періоду (7–14 днів після доставки) — переведення з
holdвavailable. - Запит виплати — продавець ініціює виведення коштів.
- Схвалення та переказ — платформа відправляє кошти через платіжний шлюз.
- Підтвердження — статус
completed, списання зavailable_balance.
Холд захищає від чарджбеків — без нього продавець міг би вивести гроші, а покупець одразу запросити повернення. Докладніше про механізм ескроу.
Чому важлива модель виплат?
Автоматичний розклад — золота середина: знижує навантаження на підтримку в 2 рази порівняно з ручними виплатами і не потребує постійного моніторингу. Гібридна модель (планові + позапланові виплати) додає гнучкість, але складніша в реалізації. Для маркетплейсу з 1000 продавців економія на операційних витратах є значною. Для платформи з 10 000 продавців економія може бути значною.
| Модель виплат | Коли вибирати | Особливості |
|---|---|---|
| На запит | Мало продавців, висока маржа | Ручна робота, навантаження на бухгалтерію |
| За розкладом | Стабільний потік замовлень | Мінімум операцій, негнучко для продавців |
| Гібридна | Великі маркетплейси | Компроміс, але складніше в коді |
Автоматичні виплати за розкладом знижують навантаження на підтримку в 2 рази порівняно з ручними. Гібридна модель виплат в 1.5 рази ефективніша за чисто планову за показником задоволеності продавців.
Як інтегрувати платіжні системи?
Обираємо шлюз під завдання маркетплейсу. Кожен провайдер має формат webhook-нотифікацій. Ми налаштовуємо обробку успіху/помилки та автоматичне звіряння балансів.
| Платіжний шлюз | Комісія | Особливості |
|---|---|---|
| ЮKassa Split | 3–6% | Для РФ, автоматичний розподіл платежів |
| Тінькофф Партнери | — | Банківські перекази, робота з юрособами |
| Stripe Connect | 2.9% + $0.30 | Міжнародні, підтримка багатьох валют |
| PayPal MassPay | — | Масові виплати за кордон |
Обробка повернень
При поверненні сума списується з available_balance продавця; якщо коштів недостатньо — з hold_balance. Якщо і там пусто — утворюється від'ємний баланс, що блокує майбутні виплати. В системі це запис з type='refund_debit'.
- Повернення покупцю — з ескроу/балансу платформи.
- Списання з продавця:
refund_amount+ повернення комісії (опціонально). - Запис у
balance_transactions.
Документообіг та звітність
Для російських продавців генеруємо:
- Акт виконаних робіт / звіт агента
- Рахунок-фактуру (при ПДВ)
- Реєстр продажів
PDF-файли (через Puppeteer) зберігаються в хмарному сховищі. Для ФОП та самозайнятих — окремі шаблони. Всі документи доступні в кабінеті продавця в архіві.
Інтерфейс продавця
- Поточний баланс (доступно / на утриманні)
- Історія транзакцій з експортом в Excel
- Форма запиту виплати з реквізитами
- Статуси виплат (processing / completed / failed)
Перед першою виплатою — верифікація реквізитів: перевірка БІК та тестовий переказ на $1–1.
Безпека та контроль
- Ліміти на виведення (денний, разовий)
- Подвійне підтвердження сум понад поріг
- Моніторинг аномалій
- Щоденне звіряння з платіжною системою
Ми гарантуємо відповідність 115-ФЗ та повний аудит всіх транзакцій.
Що входить у розробку під ключ
- Детальна специфікація API та моделі даних
- Інтеграція з обраним платіжним шлюзом
- Модуль автоматичних виплат за розкладом
- Генерація бухгалтерських документів
- Особистий кабінет продавця з балансом та історією
- Розгортання на інфраструктурі замовника
- Навчання команди та документація
- 30 днів технічної підтримки після запуску
Терміни: від 6 до 8 тижнів на типову систему. Зв'яжіться з нами, щоб отримати попередню архітектуру вашої системи. Замовте розробку — почніть з аудиту поточної схеми виплат.
