Свой маркетплейс — один из самых сложных типов веб-проектов. Это не интернет-магазин с витриной, а финансовая платформа, где сходятся каталог, платежи, комиссии продавцов, модерация контента и юридические обязательства перед покупателями, продавцами и налоговой. Ошибки в архитектуре на старте оборачиваются дорогими переделками, когда площадка уже обросла продавцами и живыми транзакциями. В этой статье разберём, из каких блоков состоит маркетплейс, как устроить логику комиссий и выплат и на что смотреть при планировании разработки.
Начните с бизнес-модели, а не с кода
Прежде чем проектировать базу данных, ответьте на вопрос: как площадка зарабатывает? От модели монетизации напрямую зависит архитектура. Основные варианты:
- Комиссия с продаж — 5–25% от каждой транзакции, классика для товарных маркетплейсов (типа Ozon или Wildberries);
- Подписка продавца — фиксированный платёж за доступ к площадке, нужен модуль биллинга и управления тарифами;
- Плата за листинг — размещение товара платное, актуально для нишевых B2B-площадок;
- Смешанная модель — например, бесплатное размещение + комиссия + платное продвижение карточек.
Ключевая метрика — take rate: доля площадки в общем обороте (GMV). Посчитайте юнит-экономику до разработки: сколько продавцов и транзакций в месяц нужны, чтобы окупить поддержку платформы. Если модель не сходится на бумаге, код её не спасёт.
Мультиселлерность меняет всю архитектуру
Главное отличие маркетплейса от интернет-магазина — множество независимых продавцов с изолированными данными. Проектируйте систему ролей с первого дня: покупатель, продавец, модератор, администратор. У каждого продавца — личный кабинет с товарами, заказами, финансами и отчётами, и он не должен видеть чужие данные.
Второй принципиальный момент — разделение понятий «товар» и «торговое предложение». Один и тот же смартфон могут продавать десять продавцов по разным ценам: для покупателя это одна карточка, для системы — десять офферов. При оформлении заказа корзина с товарами разных продавцов разбивается на субзаказы — у каждого свой статус, своя отправка и свой расчёт комиссии. Если заложить это в архитектуру позже, переделка затронет каталог, корзину, заказы и финансы одновременно.
Ключевые модули платформы
Маркетплейс — это конструктор из отдельных подсистем, каждая из которых должна работать автономно и корректно взаимодействовать с остальными. Минимальный состав:
- Каталог и поиск — категории, атрибуты, фильтры, полнотекстовый поиск, объединение офферов в карточки;
- Личные кабинеты продавцов — товары, остатки, цены, заказы, финансовая отчётность;
- Мультипродавецкий чекаут — корзина, разбивка на субзаказы, доставка от разных продавцов;
- Платёжный модуль — приём платежей со сплитом и холдированием;
- Модуль комиссий и тарифов — гибкие правила расчёта по категориям и продавцам;
- Модерация — проверка продавцов и товаров до публикации;
- Система споров — возвраты, претензии, арбитраж между покупателем и продавцом;
- Админка и аналитика — управление площадкой, GMV, take rate, выплаты.
Отдельно закладывайте логирование всех финансовых операций — каждая копейка должна иметь историю изменения статуса.
Комиссии: логика денег должна быть точной до копейки
Модуль комиссий — сердце маркетплейса, и проектировать его нужно с запасом гибкости. Заложите поддержку нескольких схем: процент от суммы, фиксированная ставка, смешанная комиссия (процент + минимум) и дифференцированные ставки по категориям — в реальности комиссия на электронику и на одежду почти всегда разная. Опытные площадки вводят и прогрессивную шкалу: чем больше оборот продавца, тем ниже ставка — это удерживает крупных партнёров.
Обязательно зафиксируйте момент начисления комиссии: при оплате, при передаче товара в доставку или при закрытии заказа. И продумайте возвраты — при отмене заказа комиссия должна сторнироваться автоматически. Округления, частичные возвраты, изменение ставки в середине месяца — всё это краевые случаи, которые ломают отчётность, если не продумать их заранее. Для продавцов нужны прозрачные реестры операций, иначе бухгалтерия партнёров будет заваливать поддержку вопросами.
Приём платежей и выплаты: самая рискованная часть
Деньги на маркетплейсе проходят сложный путь, и ошибка здесь — не баг, а репутационная катастрофа и претензии со стороны банков и налоговой. Правильный поток выглядит так:
- Покупатель оплачивает заказ — деньги поступают на платёжный шлюз;
- Средства холдируются или зачисляются на номинальный счёт площадки до подтверждения получения товара;
- Платёж автоматически сплитится: часть — продавцу, часть — комиссии площадки;
- По 54-ФЗ формируются чеки — при агентской схеме площадка пробивает чеки за продавцов;
- После закрытия заказа и истечения окна на спор продавцу начисляется выплата — на расчётный счёт ИП/ООО или самозанятому через СБП.
Технически это решается через split-платежи — их поддерживают ЮKassa, CloudPayments, Prodamus и другие агрегаторы. Для выплат физлицам и самозанятым используйте API банков (например, выплаты через Т-Банк или СБП-выплаты). Критически важны идемпотентность платежных операций (повторный вебхук не должен привести к двойной выплате) и резервирование средств на случай возвратов и чарджбеков. Юридическую схему — агентский договор или комиссию — согласуйте с юристом до разработки, она влияет на фискальную логику.
Модерация: доверие площадке создаётся фильтрами
Качество маркетплейса определяют не функции, а отсутствие мусора и мошенничества. Начните с проверки продавцов (KYC): запрос ИНН/ОГРН, автоматическая проверка статуса через API ФНС, верификация самозанятых. Мошенник, прошедший регистрацию за минуту, обойдётся дороже, чем недошедший честный продавец.
Товары запускайте через премодерацию: фотографии, описания, запретные категории. Ручную проверку усиливайте автоматикой — фильтры по стоп-словам, детект дублей и признаков подделок, лимиты на подозрительные цены. В админке нужна очередь модерации с SLA: продавец, ждущий одобрения три дня, уйдёт к конкуренту. И закладывайте модуль споров с первого дня: кто принимает решение по возврату, в какой срок, что происходит с холдом — эти сценарии нужно описать регламентом и реализовать в интерфейсе, а не решать по телефону в чате поддержки.
Что войдёт в MVP: resist соблазну построить всё сразу
Типичная ошибка первых маркетплейсов — попытка реализовать все функции сразу. В результате запуск откладывается на год, а продукт так и не проверяет спрос. В MVP достаточно:
- Каталога с карточками товаров и базовым поиском;
- Регистрации продавцов с ручной верификацией на старте;
- Личного кабинета продавца: товары, заказы, оборот;
- Чекаута со сплитом платежей и холдированием;
- Одной схемы комиссии (например, единый процент для всех категорий);
- Админ-панели с модерацией товаров и выплатами;
- Базовой аналитики: GMV, заказы, комиссии.
Прогрессивные тарифы, встроенные чаты, мобильное приложение, программа лояльности — всё это вторая очередь, когда есть первые продавцы и оборот. Ручные операции в MVP — нормальная практика: модерация через таблицу и выплаты раз в неделю вручную работают, пока их не заменили автоматикой.
Технологии и команда: сколько это стоит
Для MVP выбирайте модульный монолит, а не микросервисы: последний — избыточен для первых тысяч заказов в день, но модульность внутри кода обязательна, чтобы позже выделить платёжный сервис или поиск в отдельные компоненты. Рабочий стек — Laravel или Django на бэкенде, PostgreSQL, Redis для очередей и кэша, Vue или React для фронтенда. Очереди критичны: вебхуки платёжного шлюза, рассылки, генерация отчётов не должны блокировать основной поток.
По команде ориентируйтесь на состав: менеджер проекта, дизайнер, два бэкенд-разработчика, фронтендер, QA-инженер. Срок разработки MVP — 3–5 месяцев, бюджет варьируется примерно от 1,5–3 млн рублей в зависимости от сложности логики доставки, интеграций и объёма кастомного дизайна. Готовые решения типа CS-Cart или ShareTribe ускоряют запуск, но жёстко ограничивают финансовую логику — если ваша модель комиссий нестандартная, кастомная разработка окупится.
Маркетплейс — это марафон, а не спринт: сначала качество архитектуры, потом обороты. Три вещи, которые нельзя экономить на старте, — финансовая логика (сплит, холдирование, идемпотентность), проверка продавцов и модульность системы. Начинайте с компактного MVP, проверяйте юнит-экономику на реальных продавцах и наращивайте функциональность по данным, а не по догадкам. Если планируете запуск собственной площадки — напишите нам: спроектируем архитектуру под вашу бизнес-модель, посчитаем бюджет и покажем, как обойти типовые грабли маркетплейсов.