Оператор маркетплейсу керує продавцями, замовленнями та платіжними потоками
← Усі статтіeCommerce-інжиніринг

Розробка eCommerce-маркетплейсу: продавці, платежі та масштабування

Онбординг продавців, каталог, комісії, довіра й архітектура маркетплейсу.

2 хв читання

Розробка eCommerce-маркетплейсу об’єднує покупців, продавців, керування каталогом, рух грошей, виконання замовлень, спори та compliance в єдину операційну модель.

Які правила маркетплейсу потрібно визначити до розробки

До вибору ПЗ визначте onboarding продавців, схвалення товарів, власників контенту, цін і залишків, комісії, розподіл платежів, повернення, SLA, модерацію та вирішення спорів.

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

Чому винятки важливіші за ідеальне замовлення

Складність проявляється у винятках: розділені доставки, часткові повернення, блокування продавця, податкові документи, невдалі виплати, дублікати товарів і застарілі залишки. Стани та відповідальність потрібно моделювати явно.

Для складної моделі продавців і транзакцій API-платформа може відокремити marketplace-правила від storefront та зовнішніх систем.

Одне замовлення, кілька зобов’язань

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

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

Платежі та життєздатний запуск

Не створюйте спрощений «баланс продавця» без бухгалтерської моделі. Провайдер, повернення, chargeback і строки виплат узгоджують до розробки. Перший реліз може обмежити категорії й регіони, але має провести замовлення через оплату, виконання, повернення та звірку. Звичайний магазин кращий, якщо компанія сама володіє асортиментом.

Операційні моделі маркетплейсу

МодельВласник товаруВиконанняПлатіжний потікГоловна складність
Ритейл оператораОператорОператорОдин продавецьМерчандайзинг і supply
Курований marketplaceПродавець або змішаноПродавець або змішаноSplit або settlementКерування та SLA
Відкритий marketplaceПродавецьПереважно продавецьБагатостороннійДовіра, модерація, compliance
B2B-мережаПостачальникЗа договоромРахунок або кредитні умовиАкаунти, договори, погодження

Пов’язані статті

B2B-фахівець координує eCommerce та складські операціїРозробка B2B eCommerce: функції та архітектураАрхітектор проєктує модульну кастомну commerce-платформуКастомна eCommerce-платформа: коли вона справді потрібнаІнженер контролює транзакційний eCommerce вебзастосунокРозробка eCommerce-вебзастосунку: архітектура для зростання