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

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

Комісійна система — фінансовий скелет маркетплейсу. Її складність недооцінюють на старті: здається, що достатньо помножити суму замовлення на відсоток. На практиці комісія залежить від категорії, обсягу продаж, типу продавця, наявності промоакцій, застосованих купонів, методу доставки та десятків інших факторів. Помилка в розрахунку на 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 — тестований, без побічних ефектів
• Зміни правил не впливають на вже розраховані комісії — snapshot правила зберігається в order_commissions.rule_snapshot (JSON)
• Навантажувальні тести: розрахунок 1000 замовлень в секунду без деградації

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