Separate carts for sellers on a 1C-Bitrix marketplace

Separate carts in Bitrix: where the marketplace breaks

While a customer adds products from one seller to the cart, a marketplace on Bitrix behaves like a regular online store.

As soon as an order contains items from several suppliers, the standard checkout mechanism diverges from reality: one cart — one order, and therefore one delivery, one invoice, and one warehouse. Then data diverges between participants as well.

A typical failure: a customer places four items from three sellers, the system creates a single order and reserves everything in one warehouse.

Two sellers see someone else's product in their list, the third receives no notification at all, and inventory accounting writes off stock from the wrong batches.

The delivery service receives one address and one weight instead of three shipments — and the customer finds out about the problem last.

1C-Bitrix in its base distribution does not separate the cart by sellers: the separation is built at the level of information blocks, order properties, and event handlers.

Without this, order divergence and checkout errors become permanent: the customer sees one amount to pay, sellers see different statuses, accounting sees discrepancies in acts.

We analyze how this is addressed: how to separate the cart and checkout by sellers without breaking the standard order module and while preserving purchase history in the customer account.

What cart separation gives sellers and customers

Cart separation moves the marketplace from a shared-cart mode to a model where each item is tied to its own seller. The customer adds products from different sellers, but checks out not one consolidated order but a set of independent ones: one order — one seller.

This is the foundation from which delivery, discounts, and payment are correctly calculated; without it, any rules have to be stretched over the total amount and one has to guess whose conditions to apply.

Next, per-seller delivery calculation works: cost and time are determined by the dispatch warehouse, dimensions, and zone of the specific seller, not by the total cart amount.

The customer immediately sees that one part of the order will arrive from one city and another from another, and does not receive a recalculation already at the confirmation stage.

Per-seller discounts apply only to their items and are not diluted by other sellers' products: the accumulation threshold, promotional rule, or personal discount are calculated within their own cart.

Platform conditions and seller conditions stop conflicting, and the total matches what the customer saw during checkout.

Partial order payment and the eliminated class of failures are a direct consequence of such a scheme. If one seller cannot ship a product, only their order is canceled, the rest remain paid and go to assembly; the refund is calculated for its own part. The coupling where a refusal on one item dragged down the entire receipt goes away.

The effect is measurable: the share of orders that have to be recalculated manually falls, the flow of support requests about incorrect delivery amounts decreases, and the share of successful payments grows — the customer does not pay for what they will not receive anyway.

Options for organizing orders: comparison of approaches and modes

“Separate carts” is not a single switch in the settings, but a set of checkout modes: how items are grouped, who acts as the seller of the order, how delivery, invoice, and statuses are calculated. Below are three schemes that are actually chosen between when launching a marketplace.

Checkout modes

In most projects, the hybrid scheme turns out to be the working one: items from one seller are assembled into a separate order, different sellers produce separate seller orders, and the cart remains single — the customer sees the total amount and final delivery.

We introduce the scheme gradually: new orders follow the new rules, previously placed orders remain as they were, email templates, statuses, and exports to 1C continue to work.

The mode switches by catalog section or product type, so an already operating store does not have to be stopped.

Implementation stages: order scheme audit, configuration, verification

Separate carts affect not the checkout template but the data model: order items begin to belong to different sellers, and this must be carried through checkout, payment, delivery, and reporting.

Therefore, work on 1C-Bitrix proceeds sequentially — from auditing the current scheme to a support regulation, without changes “on the live system.”

1. Order scheme audit. We analyze how order items and properties are stored, where the “one order — one seller” binding is hardcoded, which event handlers and exchanges with the accounting system read the cart. The output is a dependency map and a list of points that will have to be changed.
2. Separation design. We determine the attribute for grouping items, the composition of service fields for binding to the seller, and how this is reflected in order export to the accounting system.
3. Checkout configuration. We assemble the cart by seller, separate delivery and payment methods, and define the confirmation and notification procedure for each party.
4. Checkout scenario verification. We run a mixed cart, partial cancellation, refund for one item, and checkout when a seller is unavailable — before deployment to the production environment.
5. Migration and reconciliation. We transfer current orders, reconcile amounts and item composition, and record discrepancies separately for each seller.
6. Handover to support. We provide the data scheme, configuration composition, checklist, and incident response rules — so that further modifications do not return to the starting point.

Deliverables: schemes, rules, regulations, documentation

After launch, the client retains not only a working marketplace but also a set of documentation. Project handover follows it: entities, rules, and regulations are described so that the team can develop separate carts without the authors of the solution.

• Marketplace data schema — order and item tables, binding of an item to a seller, relationships between carts of one order, index purpose.
• Calculation rules — division of delivery, commission, and discounts between sellers, with analysis of disputed cases: partial cancellation, delivery from different warehouses.
• Access policies — seller, operator, and administrator roles: what each one sees, what they change, where the right to another party's item is verified.
• Seller operating regulations — product creation, cancellation of an item by one of the sellers, partial assembly, refund, and status recalculation.
• Order documentation — lifecycle from cart to closure, statuses, notifications to the customer and seller, exchange points with the accounting system.
• Support instructions — typical requests and procedures, where to look at cart separation logs and how to reproduce a failure on a test order.
• Update and rollback regulations — migration procedure, integrity verification after deployment, steps for returning to the previous version if data diverges.

We hand over the project according to this list: we walk through the schemes with your team and answer questions about the regulations. Documentation is updated together with the code, so after modifications it does not diverge from the actual behavior of the carts.

Case study: marketplace with multiple sellers — before and after

A marketplace on 1C-Bitrix with several sellers on one site: the customer added products from different suppliers to a shared cart, and the order was placed as a single document.

Item breakdown by seller happened after payment — manually, using a mapping table, and any error in it led to recalculating delivery and a refund.

Before

Every fifth order required manual correction: items were mixed up between sellers, commission amounts were calculated incorrectly, and order status had to be tracked in a separate table.

Processing a composite order took up to 40 minutes, the share of checkouts that reached payment hovered around two thirds, and support spent most of its time on “where is my product” questions.

What was changed

The cart was separated by seller: each had its own set of items, its own delivery calculation, and its own warehouse reservation.

During checkout, the order splits into suborders with independent statuses and separate notifications, commission and payout are calculated at the moment of confirmation, and a refund for one item does not affect the other parts of the order.

Results

The share of successful checkouts grew from 68% to 94%, and order processing time decreased from 40 minutes to 3–4.

The number of complaints about mixed-up orders fell almost fivefold, and the share of refusals at the payment step fell by a factor of three, because the customer sees the composition and cost of each shipment before confirmation. Manual order triage disappeared as a separate operation — this provided the main part of the gain.

What to do if the marketplace is already launched with a shared order scheme

A shared order scheme is when one order contains items from different sellers, and status, payment, and delivery are shared for them.

While there are two or three sellers, the scheme holds; after that, it prevents partial cancellation of items, splitting payouts, and showing the seller only their part of the order.

You can switch to separate orders without stopping sales — the question is not stopping, but the order of work.

We do not switch the scheme in a single release. A second contour is raised alongside: new orders are assembled into separate entities by seller, while the previous one continues to serve already placed orders.

Both contours live on one database, so the cart, payment, and customer account do not diverge, and the customer does not notice the model change.

The order history is not rewritten entirely — that is the most expensive and risky operation. Old orders remain in their original form and are read through a compatibility layer: the customer sees the familiar order, the seller sees only their items and their status.

If a physical history transfer is still needed, it proceeds in the background, in batches, with reconciliation of amounts and statuses after each batch — discrepancies are visible immediately, not at the end of the month during reconciliation.

Implementation on 1C-Bitrix proceeds on a copy of the production database, then on a subset of sellers: several of them work under the new scheme, the rest under the previous one.

A reverse switch remains at hand during this time: if the share of checkout failures grows on separate orders, the contour returns to the shared scheme without losing accepted orders.

After stabilization, the scheme is rolled out to everyone, and the compatibility layer remains only for history.

Technical concerns: calculations, inventory accounting, integrations

Separate carts are only the visible part. The main concerns begin further on: how goods are distributed across seller warehouses, how suborders go to the accounting system, and what happens during partial cancellation. Below are the points most often clarified before work starts.

How do orders go to 1C if there are several sellers?

Each suborder is exported as a separate sales document with its own counterparty and warehouse. The exchange proceeds in batches on a schedule, and repeated export does not create duplicates: records are reconciled by suborder identifier.

From whose warehouse is the product written off, and how is inventory accounting handled?

Stock is synchronized separately for each seller, and write-off is from their warehouse in the accounting system. If an item runs out between checkout and assembly, the suborder is moved to canceled with a notification to the customer, rather than hanging in a pending state.

How are refunds and cancellations processed?

A refund is tied to the suborder, not to the entire order, so goods and settlements are calculated separately for each seller.

The change history is written to a log: you can see who canceled an item and when, what was returned to the warehouse, and which documents went to the accounting system.

Let's discuss the task: what to prepare for the conversation

An accurate implementation estimate and work plan for the marketplace rest on one thing: how fully we can see the current project. The more assumptions at the start, the higher the chance that cart separation will require reworking the order model during the process.

Therefore, it is worth discussing the task with the materials you have at hand — this is usually enough to name the scope of work and the order of stages.

• Roles and seller types: who sells, how contracts are set up, whether there is a single seller-owner of the platform — the logic of cart separation and checkout depends on this.
• Catalog storage model and binding of products to sellers: separation by properties, trade offers, or separate sections.
• Rules for calculating delivery and taxes by seller: whether separate shipments are needed and how to calculate cost when the cart contains products from different suppliers.
• List of third-party solutions and customizations that already interfere with checkout: custom event handlers, template modifications, exchange with 1C.
• Required customer behavior: one cart per seller or a shared order with parts, what is visible in the customer account, what statuses the parts have.
• Transition constraints: whether the old scheme works in parallel with the new one, whether already placed orders need to be transferred.
• Access to the repository or a copy of the project on the test contour: a configuration snapshot resolves half the questions without back-and-forth.
• Who on your side makes decisions on disputed points in the logic — so we do not stall on approvals.

Describe the task and attach what has already been collected — we will come back with an implementation estimate, a marketplace work plan, and a breakdown by stages.