Розробка многовендорного маркетплейсу
Многовендорний маркетплейс відрізняється від звичайного маркетплейсу тим, що у кожного продавця — повноцінний магазин з власним брендингом, налаштуваннями доставки, правилами повернення та аналітикою. Покупець може додати в кошик товари від різних вендорів та оплатити одним платежем. Складність — у тому, що одне замовлення технічно розбивається на кілька під-замовлень, кожне з яких живе за своїми правилами.
Архітектура многовендорного замовлення
Замовлення #12345 (покупець платить 5000₽)
├── Під-замовлення #12345-1 → Вендор A (2800₽ → 2520₽ після комісії 10%)
├── Під-замовлення #12345-2 → Вендор B (1500₽ → 1350₽ після комісії 10%)
└── Комісія платформи: 430₽
Кожне під-замовлення має свій статус, свою логістику, свій трекінг-номер. Продавець бачить лише свої під-замовлення; покупець бачить загальне замовлення з розбивкою по магазинах.
Особистий кабінет вендора
Ключовий розділ платформи. Включає:
- Каталог — створення, редагування, імпорт товарів (CSV/XLSX)
- Замовлення — черга нових замовлень, статуси, друк накладних
- Склад — рівні запасів, резервування, сповіщення про низький запас
- Фінанси — баланс, історія транзакцій, запит на виплату, податкові документи
- Аналітика — продажі за періодами, топ товари, повернення
- Налаштування магазину — назва, опис, логотип, банер, реквізити
Управління комісіями
Комісія може бути:
- Фіксованою (одинаковою для всіх вендорів)
- Категорійною (різна для електроніки, одежди, продуктів)
- Договірною (індивідуальна ставка на рівні вендора)
- Прогресивною (знижується при досягненні порогів обороту)
У таблиці vendor_commission_rules зберігається ієрархія: глобальна ставка < категорійна ставка < індивідуальна ставка. При розрахунку береться найбільш специфічне правило.
Мультивалютність та мультирегіональність
Для міжнародних платформ кожний вендор може працювати у своїй валюті. Ціни зберігаються в базовій валюті, конвертуються при відображенні за курсом на дату створення замовлення. Курси оновлюються через API (наприклад, Fixer.io або ЦБ РФ).
Система верифікації вендорів
Продавець проходить KYB (Know Your Business) перед отриманням виплат:
- Реєстрація (email + пароль)
- Заповнення профілю магазину
- Завантаження документів (ІНН, ОГРН/ОГРНИП, банківські реквізити)
- Модерація оператором → статус
verified - Підключення до платіжної системи (наприклад, ЮКасса — створення SubAgent)
Поки вендор не верифікований, його товари видні, але недоступні для покупки.
Політики доставки та pickup
Кожний вендор налаштовує власні зони доставки та тарифи. Інтеграції з операторами (СДЕК, Boxberry, Почта Росії, DHL) можуть бути як на рівні платформи (єдиний контракт), так і на рівні вендора (свої ключі API). Підтримка самовивозу — окрема сутність pickup_point з часами роботи та адресою.
Відгуки в контексті многовендора
Відгуки можуть бути:
-
На товар — привязані до
product_id, незалежно від вендора -
На магазин — привязані до
vendor_id, враховують якість обслуговування
Рейтинг магазину впливає на позицію в листингах категорій (крім пошукового ранжування).
Технічний стек
Для многовендорної платформи з високим навантаженням:
- Backend: Laravel або Django з мікросервісним розділенням (order service, catalog service, payment service) або моноліт з модульною архітектурою
- Очереди: Redis + Horizon (Laravel) для обробки платежів, сповіщень, пересчету рейтингів
- Пошук: Elasticsearch з per-vendor фільтрами
- Кеш: Redis для сторінок каталогу, цін, статусів запасів
Терміни
MVP з особистим кабінетом вендора, розбивкою замовлень, базовою аналітикою та виплатами: 4–6 місяців. Повна платформа з KYB, мультивалютністю, мобільним додатком для вендорів: 8–14 місяців.