Как запустить свой нишевый B2B-маркетплейс: архитектура и риски

Крупные игроки B2B-рынка - от продавцов металлопроката до дистрибьюторов медицинского оборудования - рано или поздно приходят к одной идее: «А давайте мы на своем портале разрешим продавать не только наши товары, но и товары наших конкурентов/партнеров. Станем агрегатором, будем брать комиссию и капитализируем нашу базу клиентов!»

Идея отличная. Ozon и Wildberries доказали, что модель платформы побеждает модель классического ритейлера. Но запуск нишевого B2B-маркетплейса скрывает под капотом колоссальные юридические, финансовые и архитектурные сложности, о которых забывают на этапе фантазий.

Чем B2B-портал отличается от B2B-маркетплейса?

В обычном B2B-портале есть один продавец (Вы) и тысячи покупателей (Ваши дилеры). Юридически всё прозрачно: дилер переводит деньги вам, вы отгружаете ему товар со своего склада и выписываете УПД.

На B2B-маркетплейсе есть тысячи продавцов (Мерчантов) и тысячи покупателей. Вы выступаете лишь витриной. И тут возникает главная развилка: кто и кому платит деньги?

Главные риски и как их закрывает IT-архитектура

1. Сплитование платежей и Налоги

Если покупатель переводит 1 000 000 рублей на расчетный счет вашего маркетплейса, налоговая сочтет это вашей выручкой. Вы заплатите налог со всего миллиона, хотя ваша комиссия - всего 50 000 рублей.

IT-решение: Использование банковских продуктов для сплитования (например, Точка Маркетплейсы или Яндекс Сплитование). Платформа по API передает в банк инструкцию: «Списать 1 млн с покупателя. 950к отправить на счет Мерчанта А, 50к - на наш счет». Деньги даже не касаются вашего расчетного счета.

2. Единый каталог (Борьба с дублями)

Если 10 мерчантов продают один и тот же "Кабель ВВГнг", на плохом маркетплейсе появится 10 карточек с разным названием и плохими фото. Покупатель не найдет нужное.

IT-решение: Внедрение жесткой PIM-системы (Product Information Management). Карточку товара создает модератор платформы (единая, красивая, с характеристиками). А мерчанты могут только "прикрепиться" к ней, указав свою цену и остаток. Покупатель видит одну карточку и блок: "Этот товар предлагают 5 поставщиков по цене от 120 руб".

3. Сложная корзина (Мульти-заказ)

Покупатель кладет в корзину Товар А (от Мерчанта 1 из Москвы) и Товар Б (от Мерчанта 2 из Самары).

IT-решение: Алгоритм корзины должен разбить этот заказ на два независимых подзаказа. Покупатель оплачивает всё одной кнопкой, но под капотом генерируются два разных счета, два разных логистических трека и два комплекта закрывающих документов.

4. Электронный документооборот (ЭДО)

В B2B без документов сделка недействительна. Покупателю нужна счет-фактура и УПД от того юрлица, чей товар он купил.

IT-решение: Глубокая интеграция с Диадок или СБИС через API. При оформлении заказа маркетплейс автоматически генерирует драфты УПД от лица Мерчанта и отправляет их в кабинет Покупателя. Если маркетплейс берет комиссию, он автоматически генерирует акт об оказанных услугах для Мерчанта.

Архитектура микросервисов: почему нельзя собрать это на шаблоне

Запустить полноценный B2B-маркетплейс со сплитованием и ЭДО на готовом коробочном решении вроде 1С-Битрикс (в базовой комплектации) или Shopify - невозможно. Такие проекты строятся на микросервисной архитектуре:

• Frontend: Быстрый SPA на React или Vue.js (Next.js/Nuxt).
• PIM-система: Микросервис для управления каталогом.
• Order Management System (OMS): Движок, который разбивает мультикорзины, считает логистику и общается с API Банка для сплитования.
• Личный кабинет Мерчанта: Отдельное приложение, где продавец видит свои продажи, остатки и акты сверки.

Интеграция с ERP: как избежать коллапса при загрузке 100 000 SKU

Многие начинающие владельцы B2B-площадок недооценивают сложность работы с каталогами поставщиков. В рознице продавец может вручную загрузить 50 товаров через админку. В B2B один поставщик может принести каталог на 100 000 номенклатурных позиций (SKU) со сложной матрицей цен, зависящей от объема закупки.

Если архитектура маркетплейса не предусматривает асинхронный обмен данными с ERP-системами поставщиков (1С, МойСклад, SAP), произойдет коллапс:

• Платформа не выдержит синхронной загрузки прайс-листов в формате XML/CSV и просто упадет.
• Остатки перестанут сходиться. Клиент закажет 10 тонн металла, а по факту на складе продавца осталось только 2 тонны (потому что остатки обновляются раз в сутки, а не в реальном времени).

Правильная архитектура подразумевает использование очередей сообщений (например, RabbitMQ или Apache Kafka). Когда поставщик обновляет цены в своей 1С, система отправляет событие в очередь. Маркетплейс забирает эти события в фоновом режиме порциями, не перегружая базу данных. Это гарантирует актуальность цен и остатков в режиме 24/7 даже при пиковых нагрузках.