Розробка системи виплат продавцям маркетплейсу

Розробка системи виплат продавцям маркетплейсу

Система виплат — це те, що робить маркетплейс довіреним для продавців. Затримки виплат, непрозорі утримання або помилки в розрахунках швидко приводять до відтоку постачальників. Водночас виплатна система несе фінансові та юридичні ризики: потрібно враховувати холди, еськроу, повернення, комісії, податкові документи.

Фінансова модель

Гроші покупця поступають на рахунок платформи. Платформа утримує комісію та періодично перевиває нетто-суму продавцю. Ключові сутності:

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

Життєвий цикл грошей

1. Замовлення оплачено → сума за вирахуванням комісії зараховується в hold_balance продавця
2. Період холду минув (зазвичай 7–14 днів після доставки) → переведення з hold в available
3. Продавець запитує виплату → створюється payout_request
4. Платформа одобряє та ініціює переведення → статус processing
5. Переведення підтверджено банком → статус completed, списання з available_balance

Холд захищає від ситуації, коли продавець виводить гроші, а покупець ініціює чарджбек.

Графік виплат

Маркетплейси використовують різні моделі:

• За запитом — продавець ініціює виведення в будь-який момент (поріг суми)
• За розкладом — автоматично кожного тижня/два тижні/місяць
• Гібридна — планові + позапланові за запитом

Для автоматичних виплат: scheduled job запускається в фіксований час, вибирає продавців з available_balance ≥ min_payout, створює batch payout.

Інтеграція з платіжними системами

Виплати реалізуються через:

• ЮKassa Split / ЮMoney — для РФ-маркетплейсів
• Тінькофф Партнери / Сбербанк Бізнес — банківські переводи
• Stripe Connect — для міжнародних маркетплейсів
• PayPal MassPay — масові виплати в закордонні країни
• Прямі банківські переводи через банківський API або XML-файли для завантаження в банк-клієнт

Кожен провайдер має свій формат підтверджень та webhook-сповіщень про успіх/невдачу.

Обробка повернень

Повернення зменшує баланс продавця. Якщо на рахунку достатньо коштів — списується з available_balance. Якщо недостатньо — з hold_balance, якщо й його немає — утворюється негативний баланс, що блокує майбутні виплати до погашення.

При поверненні:
1. Повернення покупцю → з еськроу/балансу платформи
2. Списання з продавця: refund_amount + повернення комісії (опціонально)
3. Запис в balance_transactions з type='refund_debit'

Документообіг

В РФ продавцам потребує:

• Акт виконаних робіт / звіт агента за період
• Рахунок-фактура (для платників ПДВ)
• Реєстр продаж для декларування

Документи генеруються автоматично: PDF через wkhtmltopdf або Puppeteer, зберігаються в S3, доступні в кабінеті продавця. Для ІП та самозайнятих — різні шаблони документів.

Інтерфейс продавця

• Поточний баланс: доступно / на утриманні
• Історія транзакцій з фільтрами та експортом в Excel
• Форма запиту виплати: сума, реквізити (прив'язані заздалегідь)
• Статус поточних виплат: processing / completed / failed
• Архів документів по періодам

Верифікація реквізитів

Перед першою виплатою — обов'язкова верифікація банківських реквізитів: IBAN/номер рахунку, БІК банку (перевірка за довідником Банку Росії), відповідність ІНН. Деякі платформи вимагають тестовий переведення на 1 рубль з підтвердженням.

Фінансовий контроль

• Ліміти: денний та разовий ліміт на виведення (захист від компрометації акаунту)
• Подвійне підтвердження великих виплат (понад поріг)
• Моніторинг аномалій: різкий ріст виплат, нетипові реквізити
• Reconciliation: щодобова звірка суми виплат з платіжною системою

Строк розробки: 6–8 тижнів для повної системи з автоматичними виплатами, документообігом та інтеграцією з платіжними системами.