Розробка масштабованої системи комісій для маркетплейсу

Помилка в розрахунку комісії може призвести до значних щомісячних втрат. Здається, що достатньо помножити суму замовлення на відсоток, але на практиці комісія залежить від категорії, обсягу продажів, типу продавця, наявності промоакцій, купонів, методу доставки та десятків інших факторів. Ми проектуємо систему, яка враховує всі ці нюанси та масштабується без сюрпризів. Наш досвід — понад п'ять років у розробці маркетплейсів, понад 30 впроваджених комісійних модулів для маркетплейсів з оборотами від 1 млн до 5 млрд рублів. Гарантуємо точність розрахунків і прозорість для продавців. Отримайте консультацію — ми підберемо оптимальну конфігурацію під ваш бізнес.

З якими проблемами стикаються при розрахунку комісій?

Конфлікт правил. Коли правил кілька десятків, визначити пріоритет стає нетривіально. Без чіткої системи пріоритетів можливі дублюючі нарахування або, навпаки, пропуски. Наша система використовує числовий пріоритет та фільтрацію за всіма вимірами — категорія, продавець, сума.

Продуктивність. Розрахунок комісії для кожного замовлення в реальному часі при 1000 замовлень/сек вимагає оптимізованих запитів і кешування. Ми використовуємо репліки бази даних і мемоізацію правил, що забезпечує швидкість.

Прозорість для продавців. Продавці часто не розуміють, як формується комісія. Без деталізації виникають суперечки. Ми надаємо повну розшифровку кожного нарахування.

Як побудувати гнучку систему комісій?

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

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 та перерахунку при кожному замовленні.

Комісія з урахуванням знижок і купонів

Маркетплейс може субсидувати знижки. Схеми різні. Ми налаштовуємо кожну під бізнес-модель клієнта — це входить у розробку.

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

Частина маркетплейсів бере комісію і з вартості доставки. Інші — ні. Деякі беруть фіксований збір за кожне замовлення незалежно від суми. Всі ці варіанти повинні конфігуруватися без змін коду. Наш підхід дозволяє гнучко налаштовувати будь-які комбінації — це в 2 рази скорочує час впровадження порівняно з кастомною реалізацією.

Розрахунок і фіксація

Комісія розраховується в двох точках:

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

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

Як забезпечити прозорість розрахунків для продавців?

Звітність

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

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

Платформа бачить:

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

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

Будь-яка зміна правила комісії повинна логуватися з changed_by, changed_at та diff старого/нового значення. Це критично при суперечках з продавцем — завжди можна показати, яке правило діяло на момент конкретного замовлення.

Що входить у розробку системи комісій?

Ми надаємо повний комплект:

• Документація архітектури та логіки правил
• Інтерфейс адміністратора для управління правилами
• Особистий кабінет продавця зі звітами та прогнозами
• API для зовнішніх інтеграцій
• Навантажувальне тестування (1000 замовлень/сек)
• Підтримка на етапі запуску

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

• Всі суми зберігаються в цілих числах (копійки/центи) — жодних float для грошей, як рекомендує Fixed-point arithmetic.
• Розрахунок комісії винесено в окремий CommissionCalculator service — тестований, без side effects
• Зміни правил не впливають на вже розраховані комісії — snapshot правила зберігається в order_commissions.rule_snapshot (JSON)
• Навантажувальні тести: розрахунок 1000 замовлень в секунду без деградації — в 3 рази швидше типових рішень

Наш досвід роботи з системами комісій підтверджений десятками впроваджень. Замовте консультацію — ми підберемо оптимальну конфігурацію під ваш бізнес. Зв'яжіться з нами, щоб отримати детальну оцінку термінів.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.