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

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

Система выплат — это то, что делает маркетплейс доверенным для продавцов. Задержки выплат, непрозрачные удержания или ошибки в расчётах быстро приводят к оттоку поставщиков. При этом выплатная система несёт финансовые и юридические риски: нужно учитывать холды, эскроу, возвраты, комиссии, налоговые документы.

Финансовая модель

Деньги покупателя поступают на счёт платформы. Платформа удерживает комиссию и периодически перечисляет нетто-сумму продавцу. Ключевые сущности:

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 недель для полной системы с автоматическими выплатами, документооборотом и интеграцией с платёжными системами.