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

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

Комиссионная система — финансовый скелет маркетплейса. Её сложность недооценивают на старте: кажется, что достаточно умножить сумму заказа на процент. На практике комиссия зависит от категории, объёма продаж, типа продавца, наличия промоакций, применённых купонов, метода доставки и десятков других факторов. Ошибка в расчёте на 1% при обороте в 10 млн/месяц — это 100 тысяч рублей.

Структура данных

commission_rules (
  id, name, priority,
  seller_id (nullable — глобальное или для конкретного продавца),
  category_id (nullable),
  min_price, max_price,
  commission_type: percentage | fixed | tiered,
  commission_value,
  valid_from, valid_until,
  is_active
)

commission_tiers (
  rule_id,
  from_amount, to_amount,
  commission_value
)

order_commissions (
  order_id, seller_id,
  gross_amount,
  commission_amount,
  net_amount,
  rule_id (applied),
  calculated_at
)

Логика выбора правила

Правила применяются в порядке приоритета. Первое подходящее правило выигрывает. Алгоритм выбора:

1. Найти все активные правила, где valid_from ≤ now ≤ valid_until
2. Отфильтровать по seller_id (специфичные для продавца имеют приоритет над глобальными)
3. Отфильтровать по category_id товара
4. Отфильтровать по диапазону min_price ≤ order_total ≤ max_price
5. Применить правило с наименьшим priority (меньше число = выше приоритет)

Если правило не найдено — применяется дефолтная ставка из конфига.

Многоуровневые (tiered) комиссии

Для крупных продавцов часто применяется регрессивная шкала:

Расчёт ведётся помесячно: в начале каждого месяца накопленный оборот сбрасывается, применяется базовая ставка. По мере роста оборота ставка снижается. Технически это требует хранения monthly_seller_turnover и пересчёта при каждом заказе.

Комиссия с учётом скидок и купонов

Маркетплейс может субсидировать скидки. Схемы разные:

• Продавец платит скидку полностью — комиссия считается от полной цены
• Платформа субсидирует скидку — комиссия от итоговой суммы, платформа покрывает разницу
• Разделение — 50/50 или по договорённости

Каждый вариант требует отдельного флага в заказе и отдельной строки в финансовой отчётности.

Комиссия за доставку

Часть маркетплейсов берёт комиссию и со стоимости доставки. Другие — нет. Некоторые берут фиксированный сбор за каждый заказ независимо от суммы. Все эти варианты должны конфигурироваться без правок кода.

Расчёт и фиксация

Комиссия рассчитывается в двух точках:

1. При оформлении заказа — предварительный расчёт, отображается продавцу
2. При подтверждении получения — финальная фиксация в order_commissions

До финальной фиксации сумма может измениться: частичный возврат, изменение состава заказа. После фиксации — immutable, любые корректировки через отдельную запись commission_adjustments.

Отчётность и прозрачность

Продавец видит в кабинете:

• Комиссию по каждому заказу с расшифровкой применённого правила
• Агрегированный отчёт за период: оборот, комиссия, нетто
• Прогноз: при текущем обороте ставка снизится в следующем месяце

Платформа видит:

• Revenue report: сколько заработала платформа по категориям
• Анализ эффективности правил: какие правила приносят больше оборота/комиссии
• Сравнение продавцов по доходности

Аудит и история изменений

Любое изменение правила комиссии должно логироваться с changed_by, changed_at и diff старого/нового значения. Это критично при спорах с продавцом — всегда можно показать, какое правило действовало на момент конкретного заказа.

Технические аспекты

• Все суммы хранятся в целых числах (копейки/центы) — никаких float для денег
• Расчёт комиссии вынесен в отдельный CommissionCalculator service — тестируемый, без side effects
• Изменения правил не влияют на уже рассчитанные комиссии — snapshot правила сохраняется в order_commissions.rule_snapshot (JSON)
• Нагрузочные тесты: расчёт 1000 заказов в секунду без деградации

Срок разработки: 5–7 недель для полной системы с тарифными сетками, отчётностью и интерфейсом управления правилами.