После запуска выплатного модуля без холда баланс продавца на маркетплейсе ушёл в минус на 500 000 рублей из-за массовых возвратов. Чтобы такое не повторялось, мы проектируем системы с эскроу и автоматическими расчётами. Наша команда с 7-летним опытом в финтехе реализовала выплатные модули для 20+ маркетплейсов — от стартапов до платформ с 10 000 продавцов. За 5 лет на рынке мы научились строить надёжное финансовое ядро, которое выдерживает тысячи транзакций в день. Автоматизация выплат продавцам снижает операционные расходы на 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 продавцов экономия на операционных расходах достигает 2 млн рублей в год. Для платформы с 10 000 продавцов экономия может превышать 20 млн рублей в год.
| Модель выплат | Когда выбирать | Особенности |
|---|---|---|
| По запросу | Мало продавцов, высокая маржа | Ручная работа, нагрузка на бухгалтерию |
| По расписанию | Стабильный поток заказов | Минимум операций, негибко для продавцов |
| Гибридная | Крупные маркетплейсы | Компромисс, но сложнее в коде |
Автоматические выплаты по расписанию снижают нагрузку на поддержку в 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 рубль.
Безопасность и контроль
- Лимиты на вывод (дневной, разово)
- Двойное подтверждение сумм свыше порога
- Мониторинг аномалий
- Ежедневная сверка с платёжной системой
Мы гарантируем соответствие 115-ФЗ и полный аудит всех транзакций.
Что входит в разработку под ключ
- Детальная спецификация API и модели данных
- Интеграция с выбранным платёжным шлюзом
- Модуль автоматических выплат по расписанию
- Генерация бухгалтерских документов
- Личный кабинет продавца с балансом и историей
- Развёртывание на инфраструктуре заказчика
- Обучение команды и документация
- 30 дней технической поддержки после запуска
Сроки: от 6 до 8 недель на типовую систему. Свяжитесь с нами, чтобы получить предварительную архитектуру вашей системы. Закажите разработку — начните с аудита текущей схемы выплат.