Разработка маркетплейса на 1С-Битрикс: комиссии и сплит-платежи

Разработка маркетплейса на 1С-Битрикс

Мы проектируем и разрабатываем мультивендорные маркетплейсы на 1С-Битрикс. Когда клиент приходит с идеей «добавить продавцов в существующий магазин», мы сразу предупреждаем: архитектура принципиально иная. В магазине — один продавец, один склад, один расчётный счёт. В маркетплейсе — десятки продавцов, у каждого свои товары, остатки, условия доставки и своя комиссия. Попытка натянуть одно на другое приводит к костылям, которые разваливаются при масштабировании.

Каждый проект уникален: от выбора модели комиссий до интеграции с платёжными провайдерами. За 10+ лет мы запустили 50+ проектов — от региональных нишевых площадок до федеральных каталогов с миллионом товаров. Наши решения проверены на нагрузке до 10 000 заказов в день. В этой статье разберём ключевые блоки, без которых маркетплейс не работает.

Мультивендорная архитектура: что внутри?

Ключевое отличие — множество продавцов на одной витрине. Архитектурно это требует:

• Сущность «Продавец» — отдельный highload-блок с юрлицом, реквизитами, рейтингом и статусом модерации.
• Привязка товаров к продавцу — каждый элемент каталога ссылается на VENDOR_ID.
• Изоляция данных — продавец видит только свои товары, заказы и статистику через кабинет.

В 1С-Битрикс нет встроенного модуля маркетплейса. Всю мультивендорную логику реализуем через кастомные модули и события. Например, при создании заказа срабатывает обработчик, который расщепляет его на подзаказы по продавцам.

Кабинет продавца: что он видит?

Продавец работает в отдельном разделе — без доступа к админке Битрикс. Кабинет включает:

Управление товарами — добавление, редактирование, загрузка фото с водяными знаками, массовый импорт из CSV/Excel, управление остатками и ценами. Публикация — после модерации.

Управление заказами — список заказов с позициями продавца, смена статуса, печать накладных, обработка возвратов.

Финансы — баланс, история транзакций, акты, запрос на вывод средств. Площадка удерживает комиссию — остальное переводится продавцу.

Аналитика — продажи за период, топ товаров, конверсия карточки, рейтинг и отзывы.

Финансовая модель: комиссии и сплит-платежи

Комиссионная система: четыре модели

Технически: при создании заказа агент или обработчик рассчитывает долю каждого продавца и комиссию площадки. Данные пишутся в таблицу финансовых транзакций.

Расщепление платежей: как выбрать способ?

Выбор метода расщепления зависит от вашей бизнес-модели. Площадка как агент — самый простой путь: деньги приходят на счёт площадки, комиссия удерживается, остаток перечисляется продавцам. Однако это требует агентского договора и ручных переводов, что при 100+ продавцах чревато ошибками. Сплит через платёжную систему (ЮKassa, CloudPayments, АТОЛ Онлайн) автоматизирует процесс: средства распределяются автоматически, без участия бухгалтера. Минус — зависимость от провайдера и его комиссий. Эскроу-счета дают максимальную защиту покупателю, но сложны в реализации и замедляют вывод денег. Мы помогаем подобрать вариант под вашу юрисдикцию и объёмы. Штатные платёжные модули 1С-Битрикс не поддерживают расщепление — пишем кастомный обработчик для каждого провайдера.

Модерация товаров и управление каталогом

Механизм модерации товаров

Без модерации маркетплейс быстро забивается дублями и некачественными товарами. Система:

• Автоматическая проверка — скрипт проверяет обязательные поля, формат фото, запрещённые слова.
• Ручная модерация — модератор в админке одобряет или отклоняет с комментарием.
• Статусы — черновик → на модерации → одобрен → отклонён.
• Массовая модерация — для надёжных продавцов с высоким рейтингом включаем автоодобрение.

Реализуем через бизнес-процессы Битрикс24 или кастомный workflow. Типичная ошибка — не настраивать автоматическую проверку. Если каждый товар модератор смотрит вручную, задержка растёт до 2–3 дней, и продавцы уходят. При автоматической проверке время модерации сокращается до нескольких часов.

Каталог на миллион товаров: поиск и индексация

Единый каталог с товарами всех продавцов требует:

• Единую структуру категорий — продавец выбирает из дерева площадки.
• Обязательные характеристики — для каждой категории набор свойств (размер, материал, бренд).
• Дедупликацию — если один товар у нескольких продавцов, показываем одну карточку с офферами.
• Фасетный поиск — фильтрация по цене, продавцу, рейтингу.
• Полнотекстовый поиск — начиная с 50 000 товаров штатный поиск Битрикс не справляется. Используем Elasticsearch или Sphinx.

Логистика: как заказы добираются до покупателей?

В одном заказе могут быть товары от трёх продавцов. Корзина разбивается на подзаказы — для каждого свой продавец, свои условия доставки. Покупатель видит итоговую стоимость с разбивкой. После оплаты каждый продавец получает уведомление. Статусы обновляются независимо.

В 1С-Битрикс это реализуем через механизм отгрузок (\Bitrix\Sale\Shipment). Интеграция с СДЭК и Почтой России через API — расчёт стоимости и генерация этикеток. Подробнее — в документации 1С-Битрикс.

Процесс разработки: шаг за шагом

Мы следуем плану, чтобы минимизировать риски:

1. Аудит требований — собираем и документируем функциональные и нефункциональные требования.
2. Проектирование архитектуры — разрабатываем схему БД, API и модульную структуру.
3. Разработка кастомных модулей — пишем модули для мультивендора, комиссий, сплит-платежей.
4. Интеграция — подключаем платёжные системы, службы доставки, 1С.
5. Тестирование — проводим нагрузочное тестирование на 10 000+ товаров и 100+ продавцов.
6. Запуск — разворачиваем на production и проводим обучение.

Состав работы и частые просчёты

Состав работы

Мы передаём:

• Проектную документацию — архитектуру, схемы БД, API, интерфейсы.
• Полные доступы — к серверу, админке, репозиторию.
• Обучающий вебинар — для администраторов и модераторов.
• Инструкции для продавцов — по работе в кабинете.
• Техническую поддержку — 3 месяца после запуска.

Частые просчёты при запуске

• Недооценка нагрузки — для каталога в 100 000 товаров нужен SSD, 16 ГБ RAM, Redis и CDN для фото. Мы проводим нагрузочное тестирование.
• Отсутствие сплит-платежей — ручное распределение денег приводит к ошибкам и задержкам.
• Слабая модерация — площадка теряет доверие покупателей.
• Отсутствие изоляции данных — продавец может получить данные конкурента. Защищаем на уровне SQL-запросов.

Почему выбор платформы важен и когда запуск?

1С-Битрикс даёт готовый каркас для каталога, корзины, заказов и прав доступа, что сокращает time-to-market на 30–40% по сравнению с разработкой с нуля. Однако мультивендорная логика — всегда кастом. И здесь важен опыт: мы уже собрали грабли и знаем, как построить архитектуру, которая не развалится под нагрузкой.

Сроки: MVP с базовым каталогом и кабинетом продавца — от 3 месяцев, полный цикл со сплит-платежами и логистикой — от 6 месяцев. Закажите аудит — и мы подготовим точный план. Также свяжитесь с нами для консультации — она бесплатна и без обязательств.

Разработка маркетплейсов на 1С-Битрикс: как преодолеть ограничения стандартной архитектуры

Таблица b_sale_order и связанные с ней b_sale_basket не рассчитаны на мультивендорность из коробки. В Битриксе нет штатного модуля «маркетплейс» — каждый раз это кастомная разработка поверх модуля sale. Стандартный модуль sale не умеет разделять заказ по разным поставщикам: если в корзине товары от трёх продавцов, Битрикс создаст один заказ с единым номером, статусом и общей суммой. Невозможно отправить каждый субзаказ в отдельный личный кабинет, рассчитать комиссию для каждого продавца или разрешить им частичную отгрузку. Нам приходится переопределять всю логику: от корзины до статусной модели. Дополнительно стандартный поиск (Sphinx) и кэширование не оптимизированы под мультивендорный каталог — при 100 000 товаров от 500 поставщиков фильтры по поставщику приводят к падению производительности (запросы с WHERE по IBLOCK_ELEMENT_PROPERTY становятся медленнее в 5–10 раз). Мы пишем отдельный модуль, который расширяет стандартную корзину: добавляет привязку товара к поставщику через свойство заказа, разбивает один заказ на субзаказы по продавцам и маршрутизирует каждый отдельно.

Почему стандартные решения не подходят для мультивендорных площадок?

Модели маркетплейсов

Классический маркетплейс — оператор не держит склад. Вся товарная логика лежит на продавцах, площадка занимается трафиком и платёжным шлюзом. Технически это отдельный инфоблок поставщиков со связью через UF_VENDOR_ID в highload-инфоблоке каталога.

Гибридная модель — оператор продаёт наравне с внешними поставщиками. Главная боль: ранжирование в каталоге. Если поставщики видят, что карточки площадки всегда выше — уходят. Мы решаем это отдельным компонентом сортировки, где позиция определяется рейтингом, скоростью отгрузки и ценой, без привилегий для «своих».

Маркетплейс услуг — заявки, тендеры, эскроу. Тут вместо b_sale_basket работает кастомная сущность заявки с воркфлоу через бизнес-процессы Битрикс.

B2B-маркетплейс — договоры, акты сверки, кредитные линии, EDI. Авторизация по ИНН, мультиценовые группы через b_catalog_group, лимиты отгрузки.

Какие технические проблемы решает разработка маркетплейсов на 1С-Битрикс?

Модели монетизации

Что включает кабинет продавца?

Кабинет — сердце маркетплейса. Неудобный кабинет = пустая площадка. Стандартного решения нет, пишем с нуля на компонентах Битрикс.

• Управление каталогом — CRUD товаров через кастомный компонент, массовая загрузка CSV/XML через CIBlockXMLFile. Вручную вбивать 10 000 SKU никто не станет, поэтому импорт — первое, что делаем.
• Обработка заказов — субзаказы падают в кабинет через ajax-polling или websocket. Подтверждение, печать накладных через CSalePdf, обновление статуса с обратной синхронизацией в основной заказ.
• Финансовая аналитика — дашборд на highload-инфоблоке агрегированных данных. Выручка, комиссии, выплаты — детализация по товарам и периодам. Продавец видит, что продаётся, а что просто занимает витрину.
• Настройки доставки — собственные тарифы продавца, привязка к sale.delivery.handler.
• Коммуникация — встроенный чат без раскрытия контактов. Реализуем через модуль im или кастомную таблицу сообщений.
• Акции — скидки, промокоды через b_sale_discount с фильтром по vendor_id.

Модерация и контроль качества

Одна партия контрафакта убивает репутацию площадки. Поэтому модерация — обязательный слой.

• Модерация товаров — статус ACTIVE='N' до прохождения проверки. Автомодерация отсекает очевидное (запрещённые слова, отсутствие фото), ручная разбирает спорное. Обработчик OnBeforeIBlockElementUpdate не даёт обойти.
• Верификация продавцов — проверка ИНН через API ФНС, загрузка сканов документов. Статусы: новый → проверенный → премиум. Каждый уровень открывает лимиты по количеству товаров и комиссиям.
• Рейтинговая система — не просто звёзды. Алгоритм учитывает скорость отправки (AVG(ship_date - order_date)), процент возвратов, качество ответов на вопросы.
• Антифрод — детектим накрутку рейтингов по паттернам (один IP, одинаковые тексты, аномальная частота). Дублирование аккаунтов ловим по ИНН и банковским реквизитам.
• Типичная ошибка: хранение данных о поставщиках в обычном инфоблоке — при 1000+ продавцов запросы становятся тормозными. Используйте highload-инфоблоки.

Как устроена система выплат продавцам?

Финансовый модуль — то, ради чего продавцы приходят на площадку.

• Расчёт комиссии — обработчик на смену статуса заказа. Комиссия зависит от категории, статуса продавца, текущих условий. Хранится в отдельной таблице vendor_transactions.
• Периодические выплаты — cron-задача формирует реестр: еженедельно, дважды в месяц или ежемесячно. Минимальная сумма выплаты, холдирование до подтверждения получения.
• Акты и отчётность — генерация PDF актов через PhpOffice\PhpSpreadsheet, автоматическая нумерация, скачивание в один клик.
• Холдирование — деньги удерживаются до получения товара. Снижает споры и возвраты.
• Выплаты через банковские API — ЮKassa, CloudPayments, прямые банковские API. Продавец получает деньги без звонков и напоминаний.
• Важно: разделение заказов на уровне обработчика OnSaleOrderSaved приводит к расхождению статусов. Разделяйте на этапе корзины.
• Ручная фискализация каждого субзаказа нарушает 54‑ФЗ. Используйте единый чек с признаком «агент». На одном из проектов автоматизация фискализации сократила издержки на 400 000 руб. ежемесячно. На другом проекте оптимизация поиска через Elasticsearch сократила время загрузки каталога на 80% (с 3 секунд до 0.6 секунды).

Как мы строим архитектуру маркетплейса

1. Определение бизнес-модели — выбираем тип маркетплейса и схему монетизации.
2. Проектирование БД — highload-инфоблоки для каталогов свыше 50 000 SKU, отдельные таблицы для субзаказов (orders_split) и транзакций.
3. Разработка ядра — создаём модуль marketplace.vendor, реализуем привязку товаров к поставщикам, механизм разделения заказов, агенты для расчёта комиссий.
4. Интеграция платёжного шлюза и 54-ФЗ — настраиваем фискализацию через АТОЛ Онлайн или CloudPayments.
5. Тестирование на нагрузку — используем k6 или ab для проверки 5000 заказов в сутки.

Типичные ошибки при разработке маркетплейсов на Битрикс

• Хранение поставщиков в обычном инфоблоке — приводит к тормозам при >1000 записей. Используйте highload-инфоблоки.
• Разделение заказов после сохранения — нарушает статусную модель. Разделяйте на этапе корзины.
• Ручная фискализация каждого субзаказа — нарушает 54-ФЗ. Фискализируйте единым чеком с признаком агента.
• Игнорирование кэширования тегированного для каталога — при мультивендорности кэш сбрасывается целиком. Настраивайте теги по vendor_id.

Технологический стек

• 1С-Битрикс «Бизнес» или «Энтерпрайз» — модуль sale + catalog как фундамент. Мультивендорная обвязка — кастомные модули.
• Highload-инфоблоки — каталоги свыше 100 000 SKU. Обычные инфоблоки при таких объёмах падают на фильтрации: CIBlockElement::GetList с десятком свойств генерирует JOIN-ы на десятки таблиц b_iblock_element_prop_sNN. Highload решает это плоской структурой.
• Elasticsearch — полнотекстовый поиск. Elasticsearch обрабатывает запросы в 10 раз быстрее штатного модуля поиска (Sphinx). Пользователь пишет «кроссовки найки» — находит «Nike кроссовки».
• Очереди — импорт каталогов, расчёт выплат, генерация отчётов. Агенты Битрикс (CAgent) для лёгких задач, отдельная очередь через RabbitMQ или supervisor + кастомный CLI для тяжёлых.

Мы гарантируем, что разработанный модуль выдержит нагрузку до 5000 заказов в сутки на стандартном VPS. Сертифицированные специалисты 1С-Битрикс (опыт более 10 лет, 50+ реализованных проектов) выполняют аудит архитектуры до старта разработки. При масштабе 2000 продавцов среднее время модерации — 15 минут, а 95% заказов обрабатываются автоматически.

Отраслевые маркетплейсы

Каждая ниша — свои грабли:

• Стройматериалы — расчёт доставки крупногабарита. Паллеты, тоннаж, подъём на этаж. Обычный калькулятор доставки не справляется, пишем кастомный sale.delivery.handler.
• Продукты питания — сроки годности в свойствах инфоблока, температурный режим, слоты доставки «день в день». Ошибка в логистике = списание.
• Автозапчасти — подбор по VIN через laximo API, кросс-номера, оригиналы и аналоги. Отдельная headache — разные сроки поставки у разных продавцов на одну деталь.
• Одежда — размерные сетки (EU/US/RU), высокий процент возвратов. Логика обработки возвратов с перераспределением комиссии — отдельный пласт.
• Промоборудование — B2B с тендерами, запросами КП. Карточка товара с 50+ параметрами в табличном виде.

Сроки и этапы

Пытаться запустить всё сразу — надёжный способ не запустить ничего.

MVP за 3-4 месяца. Полнофункциональная платформа — 6-12 месяцев итеративной разработки.

Что входит в работу

• Документация: архитектурная схема, описание API, инструкции для продавцов.
• Доступы: репозиторий с кодом, тестовый стенд, админка.
• Обучение: две сессии для администраторов и менеджеров.
• Поддержка: 1 месяц бесплатного сопровождения после запуска, далее по SLA.
• Гарантия на разработанные модули — 12 месяцев.

Свяжитесь с нами для оценки вашего проекта — рассчитаем сроки и стоимость индивидуально. Закажите консультацию, и мы покажем на реальном кейсе, как решаем проблему мультивендорности за 30 минут. Получите детальный план разработки вашего маркетплейса уже сегодня.