Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 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+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.