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

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

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

Ключові сутності та ролі

Покупець: пошук товарів, додавання в кошик, оформлення замовлення, рецензії, спори.

Продавець: реєстрація магазину, управління каталогом, обробка замовлень, отримання виплат.

Оператор: модерація товарів та продавців, управління комісіями, розв'язання спорів, фінансова аналітика.

Архітектура платіжного шару

Ключова різниця маркетплейсу від звичайного магазину — розщеплення платежів (split payment). Покупець платить одну суму, яка автоматично розділяється: частина йде продавцю, частина залишається платформі.

Stripe Connect — стандарт для західних ринків:

Покупець → Stripe → Рахунок платформи
                     ↓
              Переведення продавцю (connected account)
              Платформа утримує комісію автоматично

Схеми Stripe Connect:

• Direct — продавець повністю підключений до Stripe, бачить дані клієнтів
• Destination — гроші йдуть через платформу й переводяться продавцю
• Separate charges + transfers — максимальна гнучкість, потребує multi-vendor cart

На ринках СНГ: ЮKassa (Сплітування через API deals + payouts), CloudPayments через агентську схему.

Приклад створення Transfer у Stripe:

import stripe
stripe.Transfer.create(
    amount=8500,  # у центах
    currency="usd",
    destination="acct_1BuAYuBnMOckkSJp",  # connected account продавця
    transfer_group="ORDER_95",
)

Пошук та каталог

Для маркетплейсу з тисячами товарів від різних продавців повнотекстового пошуку БД недостатньо. Типовий стек:

• Elasticsearch або OpenSearch — індексація товарів з фасетною фільтрацією (категорія, ціна, продавець, рейтинг, атрибути)
• Meilisearch — легша альтернатива для малого/середнього маркетплейсу (до ~1 млн документів)

Фасетний пошук потребує зберігання індексованих атрибутів як окремих полів, не JSON-blob.

Система рецензій та рейтингів

Рецензія повинна бути верифікована: тільки покупець, який фактично отримав товар, може залишити рецензію. Тригер — зміна статусу замовлення на delivered або completed + N днів. Продавець може відповісти на рецензію.

Рейтинг продавця обчислюється за ковзаючим середнім, часто з вагою за свіжістю (свіжі рецензії важливіші).

Система розв'язання спорів

Спір — сутність, яка виникає при конфлікті покупця/продавця:

• Покупець відкриває спір
• Продавець відповідає
• Оператор виносить рішення (повернення / на користь продавця)
• Платіжна система виконує рішення (refund або transfer)

Таймаути: стандарт — продавець відповідає протягом 3 днів, оператор вирішує протягом 5 робочих днів.

Технічний стек

Строки розробки

MVP-маркетплейс (реєстрація продавців, каталог товарів, кошик, оплата з розщепленням, особисті кабінети продавця та покупця, базовий пошук, панель адміністратора): 3–5 місяців залежно від команди та обсягу функцій. Повноцінна платформа з рецензіями, спорами, аналітикою, мобільними додатками — 6–12 місяців.