Multi-Vendor Marketplaces on 1C-Bitrix: Commissions & Split Payments

Developing 1C-Bitrix Solutions for Multiple Sellers

We design and develop multi-vendor platforms on 1C-Bitrix. When a client comes with the idea of "adding sellers to an existing store," we immediately warn: the architecture is fundamentally different. In a store — one seller, one warehouse, one settlement account. In a multi-vendor platform — dozens of sellers, each with their own products, stock, delivery conditions, and commission. Trying to stretch one onto the other leads to crutches that collapse under scaling. Our approach includes a multi-vendor marketplace with seller cabinet, split payments, commission models, and product moderation for highload catalogs.

Each project is unique: from choosing a commission model to integration with payment providers. Over 10+ years we have launched 50+ projects — from regional niche platforms to federal catalogs with a million products. Our solutions are proven under loads of up to 10,000 orders per day. In this article, we will break down the key blocks without which a multi-vendor platform does not work.

Multi-Vendor Architecture: What’s Inside?

The key difference is multiple sellers on one storefront. Architecturally this requires:

• Seller entity — a separate highload block with legal entity, details, rating, and moderation status.
• Product-to-seller binding — each catalog item references VENDOR_ID.
• Data isolation — the seller sees only their products, orders, and statistics via a cabinet.

1C-Bitrix does not have a built-in marketplace module. We implement all multi-vendor logic through custom modules and events. For example, when an order is created, a handler fires that splits it into sub-orders by seller.

Seller Cabinet: What Does the Seller See?

The seller works in a separate section — without access to the Bitrix admin panel. The vendor dashboard includes:

Product management — adding, editing, uploading photos with watermarks, bulk import from CSV/Excel, managing stock and prices. Publication after moderation.

Order management — a list of orders with the seller’s positions, status change, invoice printing, return processing.

Finances — balance, transaction history, invoices, withdrawal request. The platform deducts its commission — the rest is transferred to the seller.

Analytics — sales for a period, top products, card conversion, rating, and reviews.

Financial Model: Commissions and Split Payments

Two critical components of a multi-vendor platform's financial infrastructure are commission models and split payments. They work together to ensure transparent and efficient transactions.

Commission System: Four Models

Technically: when an order is created, an agent or handler calculates each seller's share and the platform's commission. Data is written to the financial transaction table.

Choosing a Payment Splitting Method

The choice of splitting method depends on your business model. Platform as agent is the simplest path: money arrives on the platform's account, commission is deducted, the remainder is transferred to sellers. However, this requires an agency agreement and manual transfers, which with 100+ sellers is prone to errors. Split via payment system (YooKassa costs 2-3% per transaction, CloudPayments, ATOL Online) automates the process: funds are distributed automatically without accountant involvement. The downside is dependence on the provider and its commissions. Escrow accounts provide maximum buyer protection but are complex to implement and slow down fund withdrawal. We help choose the option for your jurisdiction and volumes. The built-in payment modules of 1C-Bitrix do not support splitting — we write a custom handler for each provider.

For example, split payments via YooKassa cost 2-3% per transaction but reduce accounting costs by 40%. Compared to manual transfers, automated splitting is 5 times more reliable and 3 times faster. Development of a basic MVP starts at $15,000, and a full-featured marketplace from $50,000. For a marketplace with 1000 orders per month, automated splitting can save $2,000 annually.

Product Moderation and Catalog Management

Product Moderation Mechanism

Without moderation, a marketplace quickly gets cluttered with duplicates and low-quality products. The system:

• Automatic check — a script checks mandatory fields, photo format, prohibited words.
• Manual moderation — a moderator in the admin panel approves or rejects with a comment.
• Statuses — draft → pending moderation → approved → rejected.
• Bulk moderation — for trusted sellers with high ratings we enable auto-approval.

We implement through Bitrix24 business processes or a custom workflow. A typical mistake is not setting up automatic checks. If a moderator manually reviews every product, the delay grows to 2–3 days, and sellers leave. With automatic checking, moderation time drops from 3 days to 2 hours — a 90% reduction.

Catalog with a Million Products: Search and Indexing

A unified catalog with products from all sellers requires:

• Unified category structure — the seller chooses from the platform's tree.
• Mandatory characteristics — for each category a set of properties (size, material, brand).
• Deduplication — if the same product is offered by several sellers, show one card with offers.
• Faceted search — filtering by price, seller, rating.
• Full-text search — starting from 50,000 products the built-in Bitrix search fails. We use Elasticsearch or Sphinx. Elasticsearch is up to 10 times faster than native Bitrix search for catalogs exceeding 100,000 products.

Logistics: How Do Orders Reach Customers?

One order may contain products from three sellers. The cart is split into sub-orders — each with its own seller and delivery conditions. The customer sees the total cost with breakdown. After payment, each seller receives a notification. Statuses update independently.

In 1C-Bitrix we implement this via the shipment mechanism (\Bitrix\Sale\Shipment). Integration with CDEK and Russian Post via API — cost calculation and label generation. More details in 1C-Bitrix documentation.

Development Process: Step by Step

We follow a plan to minimize risks:

1. Requirements audit — collect and document functional and non-functional requirements.
2. Architecture design — develop DB schema, API, and module structure.
3. Custom module development — write modules for multi-vendor, commissions, split payments.
4. Integration — connect payment systems, delivery services, 1C.
5. Testing — conduct load testing with 10,000+ products and 100+ sellers.
6. Launch — deploy to production and provide training.

Scope of Work and Common Pitfalls

Scope of Work

We deliver:

• Project documentation — architecture, DB schemas, API, interfaces.
• Full access — to server, admin panel, repository.
• Training webinar — for administrators and moderators.
• Instructions for sellers — on working in the cabinet.
• Technical support — 3 months after launch.

Common Pitfalls When Launching

• Underestimating load — for a catalog of 100,000 products you need SSD, 16 GB RAM, Redis, and CDN for photos. We conduct load testing.
• Lack of split payments — manual fund distribution leads to errors and delays.
• Weak moderation — the platform loses buyer trust.
• Lack of data isolation — a seller could get competitor data. We protect at the SQL query level.

Why Platform Choice Matters and When to Launch?

1C-Bitrix provides a ready-made framework for catalog, cart, orders, and access rights, cutting time-to-market by 30–40% compared to development from scratch. However, multi-vendor logic is always custom. And here experience matters: we have already collected the rake and know how to build an architecture that does not collapse under load.

Timelines: MVP with a basic catalog and seller cabinet from 3 months, full cycle with split payments and logistics from 6 months. Request an audit — and we will prepare a precise plan. Also contact us for a consultation — it is free and without obligation.

Marketplace Development on 1C-Bitrix: Overcoming Standard Architecture Limitations

The b_sale_order table and related b_sale_basket are not designed for multivendor out of the box. Bitrix has no built-in 'marketplace' module — each time it's custom development on top of the sale module. The standard sale module cannot split orders by different suppliers: if the cart contains items from three sellers, Bitrix creates a single order with one number, status, and total. It's impossible to send each sub-order to a separate dashboard, calculate commissions for each seller, or allow partial shipment. We have to redefine the entire logic: from cart to status model. Additionally, the standard search (Sphinx) and caching are not optimized for a multivendor catalog — with 100,000 items from 500 suppliers, filters by supplier lead to performance degradation (queries with WHERE on IBLOCK_ELEMENT_PROPERTY become 5–10 times slower). We write a separate module that extends the standard cart: adds item-to-supplier binding via order property, splits a single order into sub-orders by seller, and routes each separately.

Why Standard Solutions Are Not Suitable for Multivendor Platforms?

Marketplace Models

Classic marketplace — the operator does not hold inventory. All product logic lies with sellers, the platform handles traffic and payment gateway. Technically, this is a separate supplier infoblock linked via UF_VENDOR_ID in the highload catalog infoblock.

Hybrid model — the operator sells alongside external suppliers. The main pain: ranking in the catalog. If suppliers see that the platform's own listings always rank higher, they leave. We solve this with a separate sorting component where position is determined by rating, shipping speed, and price, without privileges for 'own' items.

Service marketplace — requests, tenders, escrow. Here, instead of b_sale_basket, a custom request entity works with a workflow via Bitrix business processes.

B2B marketplace — contracts, reconciliation statements, credit lines, EDI. Authorization by TIN, multi-price groups via b_catalog_group, shipping limits.

What Technical Problems Does Marketplace Development on 1C-Bitrix Solve?

Monetization Models

What Does the Seller Dashboard Include?

The dashboard is the heart of a marketplace. An inconvenient dashboard = empty platform. No standard solution exists; we build from scratch using Bitrix components.

• Catalog management — CRUD for products via custom component, bulk CSV/XML upload via CIBlockXMLFile. Nobody manually enters 10,000 SKUs, so import is the first thing we do.
• Order processing — sub-orders land in the dashboard via ajax-polling or websocket. Confirmation, invoice printing via CSalePdf, status update with back-sync to the main order.
• Financial analytics — dashboard on highload infoblock of aggregated data. Revenue, commissions, payouts — details by product and period. The seller sees what sells and what just occupies the showcase.
• Delivery settings — seller's own tariffs, binding to sale.delivery.handler.
• Communication — built-in chat without revealing contacts. Implemented via im module or custom message table.
• Promotions — discounts, promo codes via b_sale_discount with filter by vendor_id.

Moderation and Quality Control

One batch of counterfeit goods kills the platform's reputation. Therefore, moderation is mandatory.

• Product moderation — status ACTIVE='N' until verification. Auto-moderation filters obvious violations (banned words, missing photos), manual moderation handles disputes. Handler OnBeforeIBlockElementUpdate prevents bypass.
• Seller verification — TIN check via Federal Tax Service API, document scans upload. Statuses: new → verified → premium. Each level unlocks limits on product count and commissions.
• Rating system — not just stars. The algorithm considers shipping speed (AVG(ship_date - order_date)), return rate, and answer quality.
• Anti-fraud — detect rating manipulation by patterns (same IP, identical texts, abnormal frequency). Duplicate accounts caught by TIN and bank details.
• Typical mistake: storing supplier data in a regular infoblock — with 1000+ sellers, queries become slow. Use highload infoblocks.

How Is the Seller Payout System Structured?

The financial module is why sellers join the platform.

• Commission calculation — handler on order status change. Commission depends on category, seller status, current conditions. Stored in a separate table vendor_transactions.
• Periodic payouts — cron task generates a register: weekly, bi-monthly, or monthly. Minimum payout amount, holding until confirmation.
• Acts and reports — PDF generation via PhpOffice\PhpSpreadsheet, automatic numbering, one-click download.
• Holding — funds held until product received. Reduces disputes and returns.
• Payouts via banking API — YooKassa, CloudPayments, direct banking APIs. Seller receives money without calls or reminders.
• Important: splitting orders at the OnSaleOrderSaved handler leads to status mismatch. Split at the cart stage.
• Manual fiscalization of each sub-order violates 54-FZ. Use a single receipt with 'agent' attribute. On one project, fiscalization automation saved significant monthly costs. On another, search optimization via Elasticsearch reduced catalog loading time by 80% (from 3 seconds to 0.6 seconds).

How We Build Marketplace Architecture

1. Define business model — choose marketplace type and monetization scheme.
2. Database design — highload infoblocks for catalogs over 50,000 SKU, separate tables for sub-orders (orders_split) and transactions.
3. Core development — create module marketplace.vendor, implement product-to-supplier binding, order splitting mechanism, agents for commission calculation.
4. Payment gateway and 54-FZ integration — configure fiscalization via ATOL Online or CloudPayments.
5. Load testing — use k6 or ab to verify 5000 orders per day.

Typical Mistakes in Bitrix Marketplace Development

• Storing suppliers in a regular infoblock — causes slowdowns with >1000 records. Use highload infoblocks.
• Splitting orders after saving — breaks the status model. Split at the cart stage.
• Manual fiscalization of each sub-order — violates 54-FZ. Fiscalize with a single receipt with agent attribute.
• Ignoring tagged caching for the catalog — with multivendor, cache is invalidated entirely. Configure tags by vendor_id.

Technology Stack

• 1C-Bitrix 'Business' or 'Enterprise' — sale + catalog modules as foundation. Multivendor wrapper — custom modules.
• Highload infoblocks — catalogs over 100,000 SKU. Regular infoblocks at such volumes fail on filtering: CIBlockElement::GetList with a dozen properties generates JOINs on dozens of b_iblock_element_prop_sNN tables. Highload solves this with a flat structure.
• Elasticsearch — full-text search. Elasticsearch processes queries 10 times faster than the built-in search module (Sphinx). User types 'nike sneakers' — finds 'Nike sneakers'.
• Queues — catalog import, payout calculation, report generation. Bitrix agents (CAgent) for light tasks, separate queue via RabbitMQ or supervisor + custom CLI for heavy tasks.

We guarantee that the developed module will handle a load of up to 5000 orders per day on a standard VPS. Certified 1C-Bitrix specialists (over 10 years of experience, 50+ completed projects) perform architecture audit before development starts. At a scale of 2000 sellers, average moderation time is 15 minutes, and 95% of orders are processed automatically.

Industry Marketplaces

Each niche has its own pitfalls:

• Building materials — oversized delivery calculation. Pallets, tonnage, floor lift. Standard delivery calculator cannot handle it; we write custom sale.delivery.handler.
• Food products — expiration dates in infoblock properties, temperature regime, same-day delivery slots. A logistics error means write-off.
• Auto parts — VIN selection via Laximo API, cross-references, originals and analogs. A separate headache is different delivery times from different sellers for the same part.
• Clothing — size charts (EU/US/RU), high return rate. Return processing logic with commission redistribution is a whole layer.
• Industrial equipment — B2B with tenders, quotation requests. Product card with 50+ parameters in table form.

Timelines and Stages

Trying to launch everything at once is a sure way to launch nothing.

MVP in 3-4 months. Full-featured platform — 6-12 months of iterative development.

What Is Included

• Documentation: architecture diagram, API description, seller instructions.
• Access: code repository, test environment, admin panel.
• Training: two sessions for administrators and managers.
• Support: 1 month free support after launch, then according to SLA.
• Warranty on developed modules — 12 months.

Contact us for an assessment of your project — we will calculate timelines and cost individually. Request a consultation, and we will show on a real case how we solve the multivendor problem in 30 minutes. Get a detailed development plan for your marketplace today.