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.