Vendor-Specific Carts in 1C-Bitrix Marketplace

Imagine a marketplace with 30 sellers, a catalog of 10,000 items, yet each order is processed as a single entity. Sellers don't see their own orders, the customer gets confused with delivery, and returns become a nightmare. That's the pain we tackle when owners of multi-vendor platforms on 1C-Bitrix come to us. The solution is separate shopping carts, which we configure for the specific business model. With over 10 years of proven experience (more than 50 projects completed), we have developed two trusted approaches.

Visual separation: items grouped by vendor

The b_sale_basket cart remains unified, but the interface groups items by the product's UF_VENDOR_ID. The customer sees sections "Vendor A" and "Vendor B" with separate totals, and payment goes through as a single transaction. During checkout, one b_sale_order is created, but sub-orders for each vendor are generated in the background (mp_sub_orders table). Vendors only see their own sub-orders.

Implemented in the sale.basket.basket component template: in template.php, we group $arResult['ITEMS'] by UF_VENDOR_ID:

$itemsByVendor = [];
foreach ($arResult['ITEMS'] as $item) {
    $vendorId = CIBlockElement::GetByID($item['PRODUCT_ID'])->GetNext()['UF_VENDOR_ID'];
    $itemsByVendor[$vendorId][] = $item;
}

The customer pays once — convenience increases, but partial returns become more complex: amounts must be split between vendors. We solve this through the mp_sub_order_items table, which links each item to a sub-order. As a result, return processing time is reduced by 40% compared to manual splitting.

Visual separation vs. separate orders: which to choose?

With separate orders, the system creates an independent b_sale_order per vendor. The customer receives multiple confirmations and pays for each order (or pays once through an aggregator with splitting). Implementation requires replacing the standard CSaleOrder::Add() with a custom handler that splits the cart by UF_VENDOR_ID.

Based on our data, visual separation is better for most projects: it reduces support load by 30% compared to separate orders. If you have more than 20 vendors, separate orders can create confusion, but we always help choose the optimal scheme.

Delivery: the key challenge with separate carts

Each vendor has its own delivery methods and costs. We apply three approaches:

• Unified delivery handled by the marketplace (aggregating all goods)
• Separate delivery choice for each vendor (customer selects individually)
• Pickup from the marketplace point

Integration with CDEK and Russian Post via their APIs requires adaptation to the chosen scheme. With separate orders, each shipment goes out individually — cost is higher, but transparency is maximal. In one project, we reduced delivery calculation time from 5 seconds to 500 ms by pre-calculating tariffs in cache.

Real case: marketplace with 50 vendors

One project was an auto parts marketplace (Bitrix24, 50 vendors, 200,000 items). We chose visual separation with a single order. Complexity: each vendor had its own delivery rates and discounts. We implemented a custom OnSaleOrderSaved handler that distributes amounts to sub-orders and generates separate invoices. Result: purchase abandonment due to delivery complexity dropped by 20%, and return processing time was cut from 2 days to 4 hours — 12 times faster. For payment splitting, we used YooKassa — each vendor receives funds directly to their settlement account. Ultimately, conversion increased by 15%, and support inquiries decreased by half.

Что входит в настройку

• Analysis of current catalog and cart architecture
• Design of separation scheme (visual or separate orders)
• Customization of cart and checkout templates
• Implementation of sub-order or multi-order handlers
• Vendor-specific delivery integration via API
• Payment splitting setup (YooKassa, Sber)
• Testing partial returns and 54-FZ scenarios
• Documentation and team training
• Guaranteed post-launch support for 30 days

Setup process and timelines

1. Analysis — study catalog architecture, infoblocks, UF_VENDOR_ID properties.
2. Design — choose scheme, design sub-orders or multiple orders.
3. Implementation — customize cart, checkout, delivery, and payment handlers.
4. Testing — verify with live data, including partial returns and 54-FZ.
5. Deployment and support — go live, monitoring, team training.

Cost is calculated individually after analyzing your project. For example, visual separation typically costs from $1,500, while full separation with custom delivery starts at $4,000. Order a current architecture analysis — we will advise which scheme suits you best. Contact us for a consultation and get a preliminary estimate within 1 day.

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.