Комісії, спліт-платежі та модерація: як створити мультивендорний маркетплейс на 1С-Бітрікс

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

Наш досвід — понад 10+ років на ринку, 50+ успішних проєктів, сертифіковані фахівці 1С-Бітрікс. Ми гарантуємо якість та надійність. 1С-Бітрікс прискорює запуск на 30–40% порівняно з розробкою з нуля — це перевірено на практиці. Кожен проєкт унікальний: від вибору моделі комісій до інтеграції з платіжними провайдерами. За 10+ років ми запустили 50+ проєктів — від регіональних нішевих майданчиків до федеральних каталогів з мільйоном товарів. Наші рішення перевірені на навантаженні до 10 000 замовлень на день. У цій статті розберемо ключові блоки, без яких маркетплейс не працює.

Мультивендорна архітектура: що всередині?

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

• Сутність "Продавець" — окремий highload-блок з юрособою, реквізитами, рейтингом та статусом модерації.
• Прив'язка товарів до продавця — кожен елемент каталогу посилається на VENDOR_ID.
• Ізоляція даних — продавець бачить лише свої товари, замовлення та статистику через кабінет.

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

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

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

Управління товарами — додавання, редагування, завантаження фото з водяними знаками, масовий імпорт із CSV/Excel (до 1000 товарів за раз), управління залишками та цінами. Публікація — після модерації.

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

Фінанси — баланс, історія транзакцій, акти, запит на виведення коштів. Майданчик утримує комісію — решта переводиться продавцеві.

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

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

Комісійна система: чотири моделі

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

Розщеплення платежів: як вибрати спосіб?

Вибір методу розщеплення залежить від вашої бізнес-моделі. Майданчик як агент — найпростіший шлях: гроші приходять на рахунок майданчика, комісія утримується, залишок перераховується продавцям. Однак це вимагає агентського договору та ручних переказів, що при 100+ продавцях загрожує помилками (їх кількість зростає в 10 разів порівняно з автоматизацією). Спліт через платіжну систему (ЮKassa, CloudPayments, АТОЛ Онлайн) автоматизує процес: кошти розподіляються автоматично, без участі бухгалтера. Мінус — залежність від провайдера та його комісій (0.5–2% за транзакцію). Ескроу-рахунки дають максимальний захист покупцеві, але складні в реалізації та сповільнюють виведення грошей. Ми допомагаємо підібрати варіант під вашу юрисдикцію та обсяги. Штатні платіжні модулі 1С-Бітрікс не підтримують розщеплення — пишемо кастомний обробник для кожного провайдера.

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

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

Без модерації маркетплейс швидко забивається дублями та неякісними товарами. Система:

• Автоматична перевірка — скрипт перевіряє обов'язкові поля, формат фото, заборонені слова.
• Ручна модерація — модератор в адмінці схвалює або відхиляє з коментарем.
• Статуси — чернетка → на модерації → схвалено → відхилено.
• Масова модерація — для надійних продавців з високим рейтингом вмикаємо автосхвалення (зменшує час модерації до 2 годин замість 3 днів).

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

Каталог на мільйон товарів: пошук та індексація

Єдиний каталог з товарами всіх продавців вимагає:

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

Логістика: як замовлення добираються до покупців?

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

У 1С-Бітрікс це реалізуємо через механізм відвантажень (\Bitrix\Sale\Shipment). Інтеграція з СДЕК та Поштою Росії через API — розрахунок вартості та генерація етикеток. Детальніше — в документації 1С-Бітрікс.

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

Ми дотримуємося плану, щоб мінімізувати ризики:

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

Що входить в роботу? (Deliverables)

Ми передаємо:

• Проєктну документацію — архітектуру, схеми БД, API, інтерфейси.
• Повні доступи — до сервера, адмінки, репозиторію.
• Навчальний вебінар — для адміністраторів та модераторів.
• Інструкції для продавців — по роботі в кабінеті.
• Технічну підтримку — 3 місяці після запуску.

Часті прорахунки при запуску

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

Чому вибір платформи важливий і коли запуск?

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

Терміни: MVP з базовим каталогом і кабінетом продавця — від 3 місяців, повний цикл зі спліт-платежами та логістикою — від 6 місяців. Вартість розробки під ключ: MVP від 500 000 грн, повний цикл від 1 500 000 грн. Замовте безкоштовний аудит — і ми підготуємо точний план та оцінимо ваш проект. Також зв'яжіться з нами для консультації — вона безкоштовна та без зобов'язань. Ми гарантуємо якість та прозорість на всіх етапах.

Розробка маркетплейсів на 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‑ФЗ. Використовуйте єдиний чек з ознакою «агент». На одному з проєктів автоматизація фіскалізації скоротила витрати на значну суму щомісяця. На іншому проєкті оптимізація пошуку через 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 хвилин. Отримайте детальний план розробки вашого маркетплейсу вже сьогодні.