Покупець додає в кошик товари від трьох вендорів. Система має єдиним платежем провести оплату, у реальному часі розбити замовлення на підзамовлення, розрахувати комісію для кожного продавця та повідомити склади. При невдалій архітектурі на етапі оплати виникають deadlock’и, а вендори бачать чужі дані. Ми — команда з 5-річним досвідом розробки маркетплейсів — спроектуємо та реалізуємо масштабоване рішення. Розробка багатовендорного маркетплейсу потребує точного проектування даних та асинхронних процесів. Отримайте консультацію інженера.
Як працює розбивка замовлень у багатовендорному маркетплейсі?
Після оформлення замовлення система групує товари за унікальним vendor_id. Для кожного вендора створюється підзамовлення з власною сумою, комісією та статусом. Платіжне доручення формується на загальну суму, але кожне підзамовлення обробляється незалежно. Це дозволяє вендорам бачити лише свої замовлення, а покупцеві — єдиний трекінг.
Приклад із продакшену: на платформі fashion-маркетплейсу замовлення містять до 5 вендорів. Середній час обробки підзамовлення — 1 секунда при 10 000 замовлень на годину. Використовуємо event-driven архітектуру з Redis чергами — це виключає конкуренцію за ресурси БД.
Чому важлива гнучка система комісій?
Комісія — основне джерело доходу платформи. Єдина ставка неефективна: різні категорії товарів мають різну маржинальність. Ми реалізуємо ієрархію правил: глобальна ставка → категорійна → договірна → прогресивна. Наприклад, електроніка 8%, одяг 12%, а для стратегічного партнера — індивідуальна 5%. Комісія може варіюватися від 2% до 15% залежно від категорії та обсягів. Порівняння типів:
| Тип |
Приклад |
| Фіксована |
10% для всіх |
| Категорійна |
Електроніка: 8%, Одяг: 12% |
| Договірна |
5% для партнера |
| Прогресивна |
до 1 млн: 10%, далі 7% |
Прогресивна шкала стимулює зростання вендорів — економія до 3% при обороті понад 1 млн.
Особистий кабінет вендора та аналітика
Ключовий модуль платформи. Містить: управління товарами (CSV-імпорт з валідацією по 20 полях), замовлення з фільтрацією за статусами, складські залишки з low-stock сповіщеннями, фінансовий блок з балансом та запитом виплат. Аналітика в реальному часі: топ-список товарів, звіт по поверненнях, динаміка продажів.
Верифікація вендорів (KYB)
Без Know Your Business не можна виводити кошти на рахунки вендорів. Процес: реєстрація → завантаження скан-копій (ІПН, ОГРН) → модерація за 24 години. Після верифікації статус verified — лише тоді вендор може отримувати виплати. Неверифіковані вендори видимі, але недоступні для покупки.
Технічна архітектура та стек
Backend: Laravel 11 (PHP 8.3) або Django з мікросервісним поділом або модульним монолітом. Мікросервісна архітектура масштабується в 3 рази швидше за моноліт при зростанні кількості вендорів. Черги: Redis + Horizon. Пошук: Elasticsearch з індексами по вендорах. База: PostgreSQL з шардуванням по tenant. Деплой: Docker + CI/CD на GitHub Actions.
Приклад конфігурації комісійного правила
{
"global": 10,
"overrides": [
{"category": "electronics", "rate": 8},
{"vendor_id": 42, "rate": 5}
]
}
Що входить у розробку маркетплейсу
Ми надаємо повний набір deliverables для запуску платформи:
| Етап |
Результат |
| Аналітика |
Технічне завдання, структура комісій, логістика, мультивалютність |
| Проектування |
ERD, схема мікросервісів, API-специфікація, UI/UX дизайн |
| Розробка |
Особистий кабінет вендора, розбивка замовлень, платіжні інтеграції, KYB |
| Тестування |
100+ сценаріїв (змішаний кошик, повернення, виплати) |
| Підтримка |
3 місяці після деплою, навчання команди (2 дні) |
Досвід команди
Понад 5 років на ринку розробки маркетплейсів. Виконали 15+ проектів для рітейлу та електронної комерції. Сертифіковані спеціалісти з Laravel та React гарантують прозорий код і дотримання термінів. Замовте розробку маркетплейсу — ми підготуємо для вас комерційну пропозицію.
Процес розробки та терміни
- Аналітика (2 тижні) — вивчаємо бізнес-модель, логістику, мультивалютність.
- Проектування (2–4 тижні) — ERD, мікросервісна схема, UI/UX.
- Реалізація (8–20 тижнів) — код особистого кабінету, розбивки замовлень, платіжної інтеграції.
- Тестування (2–4 тижні) — сценарії «змішаний кошик», повернення.
- Деплой та підтримка (1 тиждень) — продакшн, CI/CD.
MVP займає 4–6 місяців, повноцінна платформа — 8–14 місяців. В результаті ви отримуєте робочу платформу з кабінетами вендорів, розбивкою, комісіями, KYB та базовою аналітикою. Документація по API, код, навчання команди (2 дні), 3 місяці підтримки.
Залиште заявку на аудит поточної архітектури або зв'яжіться з нами для консультації — оцінимо ваш проект та запропонуємо оптимальне рішення.
Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.
Як побудувати надійну мультивендорну платформу?
Як уникнути розбіжностей у розрахунках комісій
Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.
Моделі комісій (використовуємо одну з або комбінуємо):
| Модель |
Принцип |
Типовий сценарій |
| Фіксований відсоток |
5% з кожного продажу |
Прості торгові майданчики |
| Диференційований за категоріями |
Електроніка 3%, одяг 8% |
Маркетплейси з різними маржами |
| Tiered за оборотом |
До 100k — 10%, від 100k — 7% |
B2B-платформи з об'ємними знижками |
| Змішаний |
% + фіксована сума за транзакцію |
Високоризикові або дорогі товари |
Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.
Escrow та холдування — приклад реалізації
Гроші з покупця списуються одразу, продавцю переказуються із затримкою 7–14 днів після підтвердження отримання. Це захист від шахрайства та можливість утримання при спорах. Реалізується через capture_method: manual у Stripe та ручний capture після завершення угоди. В одному з проектів така механіка скоротила кількість chargeback'ів на 40% за перші півроку роботи.
Чому архітектура мультиарендності критична для ізоляції даних
Перший крок — вибір архітектури мультиарендності. У 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?
Порівняння підходів до каталогу товарів:
| Аспект |
Unified-каталог (Amazon-like) |
Per-vendor-каталог (Avito-like) |
| Єдина картка товару |
Так, product → offers |
Ні, кожен продавець свою |
| SEO |
Оптимізується за карткою |
Дублікати, але швидший запуск |
| UX покупця |
Вищий (порівняння цін) |
Нижчий (багато дублів) |
| Складність розробки |
Висока (модерація атрибутів) |
Середня |
| Конверсія покупки |
На 25% вища |
Нижча |
Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.
Пайплайн модерації: автоматика та ручна верифікація
Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:
- Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
- AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
- Черга ручної перевірки для 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+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.
