Multi-Vendor Marketplace Architecture on 1C-Bitrix

Multi-Vendor Marketplace Architecture on 1C-Bitrix

A typical multi-vendor marketplace on Bitrix faces duplicate products (up to 15% duplicates), order confusion with three or more sellers, and manual commission calculations that waste up to 20 hours per week. Our solution isolates vendor data at the information block level and automates payouts, cutting administration time by three times. On one project, we handle 50,000 products from 200 vendors — the system processes 1,000 orders per day without lags. Order a preliminary assessment of your project — we will analyze the complexity and propose the optimal path.

How to Isolate Vendor Data?

The most practical approach is to add a vendor ID at the catalog information block level. The vendor registers as a Bitrix user in the “Vendors” group; their USER_ID serves as VENDOR_ID. The main catalog information block is extended with a UF field UF_VENDOR_ID (link to b_user.ID). All catalog components add a filter by UF_VENDOR_ID during selection. In the vendor’s personal account, only elements with their UF_VENDOR_ID appear.

An alternative for large marketplaces: a HighLoad information block as an intermediate layer that stores the PRODUCT_ID → VENDOR_ID mapping and is used for quick permission checks.

Vendor table (via HL information block or custom):

How to Split Orders Between Vendors?

A customer adds products from three vendors to the cart. In Bitrix, this is one order in b_sale_order. We use sub-orders as child records: an additional table mp_sub_orders is created with fields ORDER_ID, VENDOR_ID, STATUS, TOTAL, COMMISSION. Upon order creation, the OnAfterOrderAdd handler automatically creates sub-orders by grouping cart items by the products’ UF_VENDOR_ID. The vendor sees only their sub-orders.

Our sub-order solution handles 1,000 orders per day without delays, while the typical event-based approach starts lagging at 200 orders. An alternative is to store VENDOR_ID in b_sale_basket as a custom property and manage statuses at the item level. This approach is simpler but complicates payout aggregation. For most projects, sub-orders are optimal.

Vendor Personal Account

Minimum vendor account components:

• Product management: add/edit/deactivate with forced UF_VENDOR_ID = current user
• Sub-order management: list, status change, invoice printing
• Stock and price management: bulk update via CSV or AJAX
• Analytics: sales by period, top products, returns based on sub-orders
• Profile and payment details: documents, payment info, verification status
• Finance: accrued commissions, payout history, balance

Permissions: user in the “Vendors” group plus UF_VENDOR_ID check on every request.

Commission System

Commissions are calculated at sub-order creation or when it reaches a final status. Logic:

// Simplified pseudocode $commissionRate = $vendor['UF_COMMISSION_RATE'] ?? $categoryRate[$product['IBLOCK_SECTION_ID']] ?? $defaultRate; $commission = $subOrder['TOTAL'] * $commissionRate / 100; // Save to financial operations table MpFinanceTable::add([ 'VENDOR_ID' => $vendor['ID'], 'ORDER_ID' => $orderId, 'TYPE' => 'commission', 'AMOUNT' => -$commission, 'STATUS' => 'pending', ]); 

Commission can vary: flat rate, by product category, individual vendor rate, progressive (based on turnover). Clients save up to 500,000 rubles per year on manual payouts.

Product Moderation

Vendor products undergo moderation before publication. Technically, this is a status of the information block element: when a vendor adds a product, ACTIVE = N and a special status UF_MODERATION_STATUS = 'pending' are set. The moderator (user in the “Moderators” group) sees the moderation queue, reviews, sets ACTIVE = Y or rejects with a comment. Vendor notification via CEvent::Send() or built-in Bitrix notifications.

What’s Included in Development: Delivery and Documentation

Each project includes:

• Project documentation: ER diagram, commission logic description, access rights scheme.
• Access to code repository (Git).
• Operation manual for admin and vendors.
• Team training (up to 2 hours via webinar).
• 2 weeks of free support after launch.
• 6-month code warranty.

How We Develop a Multi-Vendor Marketplace: Step by Step

1. Analysis and architecture – design ER diagram, access rights scheme.
2. Vendor registration – configure profiles, payment details, tax ID verification.
3. Product and order isolation – implement UF_VENDOR_ID and sub-orders.
4. Vendor personal account – develop module for product, order, and analytics management.
5. Financial module – automatic commission calculation, payouts via bank API.
6. Moderation and analytics – moderation queue, admin reports.
7. Testing and launch – load testing, team training, 2 weeks of support.

Development Timeline

Timelines are for development from scratch. Using a ready multi-vendor module as a base reduces customization to 10-16 weeks.

Benefits of Working with Us

Our experience in Bitrix development spans over 5 years; we have completed 30+ projects. Certified 1C-Bitrix specialists ensure a 6-month code warranty. Contact us for a consultation — we will evaluate your project in one day and provide a solution.

What Problems Does the Multi-Vendor Architecture Solve?

We eliminate typical pain points: product duplicates, order confusion, manual commission calculation, slow moderation. Our clients save up to 30% of time on marketplace administration. Get an engineer consultation — discuss your case.