Separate carts for sellers on a 1C-Bitrix marketplace

Separate carts in Bitrix: where an order breaks on a marketplace

The out-of-the-box store in 1C-Bitrix puts everything into a single order: one cart, one payment, one status. While a single supplier sells the goods, the scheme works.

On a marketplace, the cart contains items from different sellers — and the standard logic turns into a source of checkout errors.

The first break occurs at the confirmation step. The order is created as a single entity, although items from different sellers require separate delivery terms, shipment times, and payment recipients.

The manager receives a mixed request, and the seller sees neither their own items nor the amount due to them at the end.

Next, order statuses diverge. The platform changes the state of the entire order as a whole, although one seller has already shipped, the second is still assembling, and the third has removed their item.

Partial shipment and partial return are not reflected correctly: the buyer sees an incorrect state, and support reconciles everything manually using exports.

Checkout errors surface later — two invoices for one cart, a repeated charge during re-assembly, a lost item after editing the contents. The manager resolves each such situation manually, and each one eats up the buyer's time.

Separate carts in Bitrix close this at the architecture level: marketplace checkout is split by seller at the input, rather than corrected afterward. We'll break down how this is structured and what to look at during implementation.

What changes after implementation: assembly speed and fewer abandonments

The main effect is visible in order assembly time: carts are formed by seller automatically, and the manager no longer needs to manually distribute items from one order across different suppliers.

The contents, warehouse, and delivery method are populated from the seller's settings, rather than being overwritten by hand. In practice, assembly is reduced severalfold — what took ten to fifteen minutes per order now fits into a minute or two of checking.

The share of orders without edits grows. Previously, after checkout the manager edited the contents, delivery, or final terms — the system combined items from different sellers into one calculation.

After separating carts, each part is calculated by its own rules, and manual edits remain only where a human is truly needed.

A whole class of checkout abandonments disappears — the one that arose when items from different sellers were mixed.

The buyer sees separate carts with transparent contents, timing, and delivery terms, so they do not abandon the order at a step where the total or delivery suddenly changed.

In total, this speeds up request processing: fewer returns for rework, a shorter path from checkout to handoff to the seller, and a more even manager workload.

The metrics we use to verify the result after implementation are order assembly time, the share of orders without edits, the number of abandonments at the checkout step, and request processing speed. All of them are pulled from system logs and reports, rather than estimated by eye.

One order or seller cart: comparing approaches

At the checkout level, a marketplace solves one task: the buyer pays once, and sellers receive only their own items. On 1C-Bitrix, this is implemented in three ways, and the choice between them determines where delivery, commission, and returns are calculated.

The difference shows up not in checkout, but in business logic: in a single cart, delivery is calculated as one amount, in a seller cart — separately for each sender, and the hybrid combines both models.

Switching between schemes after launch almost always means rebuilding the delivery and status calculation, so the choice is fixed before work begins.

In practice, they focus on two signs: how many sellers appear in one order and who is responsible for delivery. If there is one seller or the goods ship from a shared warehouse, a single cart is enough.

As soon as the buyer regularly assembles an order from items of different suppliers, a hybrid scheme is more advantageous — it keeps a single order for the buyer, while giving the seller only their lines and their payouts.

How implementation proceeds: audit, scheme, setup, acceptance

Separate carts cannot be enabled with a single setting — the scheme is built for the specific logic of sellers, delivery, and returns.

Therefore, the work proceeds in stages: first we record how the order is checked out now, then we design the target model, and only after that do we touch the production environment. Below are the six steps that make up implementation.

1. Checkout audit. We walk the buyer's path from adding an item to payment and analyze where the cart mixes items from different sellers, how delivery is calculated at that moment, and which modules intervene in the calculation. The output is a map of bottlenecks indicating where the logic is tied to a single supplier.

2. Designing the order scheme. We describe the cart as a set of independent parts: each item has its own seller, its own delivery terms, its own status, and its own total. We separately define the behavior for partial payment, cancellation of one item, and return.

3. Setting up delivery and payment rules. We separate the calculation by sellers and warehouses, determine when shipments are combined and when they go as separate dispatches, and how this is reflected in the invoice and notifications.

4. Order migration. We move the history into the new model so that old orders open correctly and statuses and totals match the previous ones. We run the migration on a copy and compare exports before and after.

5. Scenario acceptance. We agree on a checklist and use it to verify real paths: an order with several sellers, cancellation of one part, return, repeated payment, and operation under load. The client goes through the scenarios themselves and sees the result.

6. Handoff to support. We provide the data schema, a description of the rules, a procedure for typical requests, and instructions for managers — so that future changes can be made without re-analyzing the logic from scratch.

After that, the solution lives as a normal environment: new sellers connect according to the described rules, rather than rewriting checkout. Describe your task — we will get back to you with an estimate and work plan.

Configurations, data schemas, and order processing procedures

The documentation package is assembled during the project, not at the end: each schema describes what has already been verified on staging.

Therefore, the client receives not “how it was supposed to be,” but an up-to-date picture of the working environment — they can use it to accept edits on their own or hand individual enhancements to us.

• Checkout module configuration — which carts are assigned to sellers, the rules for consolidating items into one order, and restrictions on delivery and minimum total for each part.
• Order data schema — the entities that store the split by seller and the relationships between items, payments, and shipments, so that reporting by part reconciles with the total.
• Status and email templates — transition logic separately for each part of the order and notifications to the buyer and sellers at each step.
• Instructions for managers — how to process an order with several sellers, what to do when one item is canceled or returned, and where to look for the cause of a discrepancy.
• Integration map — what exchanges data and in which direction with the accounting system, warehouse, payments, and delivery, including exchange failure points.
• Processing procedures — the exchange schedule, rules for resending after a failure, the procedure for manual intervention, and the boundaries beyond which we step in.
• Set of test scenarios — orders with different combinations of sellers, partial cancellations, and returns; every change after release is verified against it.

The documentation lives next to the code in the version control system, not as a separate archive on disk. A change to a schema or procedure follows the same path as code: edit, verification on staging, and an entry in the change log.

Marketplace case study: fewer order errors and faster assembly

Before: one cart for all sellers

The client is a marketplace on 1C-Bitrix with several hundred sellers in a shared catalog. The cart was single: the buyer put goods from different stores into one order, and the code split items by seller at the save stage.

About one order in forty was mixed up — a seller received someone else's line, and the delivery calculation was based on someone else's set. Support handled each such request manually: verify the contents, coordinate with two sellers, re-checkout the order, and issue a refund.

What we changed

We separated the cart, checkout, and order by seller: each has its own cart, its own delivery calculation, and its own statuses. The final total and promotions are calculated at the buyer level, so that discounts and bonuses do not break apart into parts.

We added checks on order save — a content discrepancy is caught before writing to the database, not after. We separately described cart transfer when logging in from another device and when the contents change.

What changed in metrics

Item mixing disappeared as a class: after launch, not a single order with someone else's line was recorded. Seller order assembly was cut roughly in half — someone else's items no longer have to be filtered out manually.

Support requests about order contents dropped almost fivefold, and edits to already checked-out orders became isolated.

What to do if checkout is already set up under the old scheme

Switching is not done in a single release: checkout is a point where an error costs lost sales, so the new scheme is enabled on top of the old one and removed only after both environments have run in parallel.

In 1C-Bitrix, this is solved at the level of checkout handlers and cart-to-seller binding: while separation is disabled, the components work as before.

Next is phased enablement. First, the new logic is run on a copy: an order with several sellers, partial cancellation, return.

Then separate carts are enabled for one group of sellers, while the rest trade under the previous scheme; expansion proceeds by group with monitoring of the share of successful checkouts and support requests.

Migration of active orders is a separate step: payment, invoice, item reservation, and seller notifications are linked to an order, so mass rewriting is unacceptable.

Orders in intermediate statuses are completed under the old rules, and the new environment takes only those that have not yet gone to payment. A paid cart does not break into parts retroactively.

Backward compatibility relies on the readability of old records: reports, emails, and exchange with the accounting system continue to see the familiar fields. Without checking this, what breaks is not checkout but order export and reconciliation with accounting.

The main risks during switching are status desynchronization, duplicate items when carts are created simultaneously, and loss of the order-to-seller link.

These are mitigated by procedure: enabling during a low-load window, an order transition log, and quick rollback of the flag to the previous behavior.

Payment, delivery, and order statuses: common technical concerns

Separate carts break the familiar scheme where an order is one transaction. As soon as it contains goods from several sellers, delivery is calculated separately for each, payment is split into parts, and the buyer gets several statuses instead of one. Below are the contentious points most often raised before work starts on Bitrix.

Can payment be made in one operation rather than several charges?

Yes, if the payment service supports payment splitting: the amount is charged once and distributed among sellers, and the platform commission is withheld automatically.

If the service cannot do this, we use sequential charges or hold funds until all parts of the order are confirmed, so that the platform does not pay the seller from its own funds.

What does the buyer see in terms of statuses if parts of the order ship separately?

The order retains an overall status — paid, in transit, completed — while inside it each seller maintains their own: assembled, handed to delivery, delivered. Notifications are sent for each part, so the buyer does not receive “order delivered” when only half has arrived.

How do parts of the order get into the accounting system?

The order is exported with a split by seller: separate sales records, separate delivery documents, coordinated statuses and returns. The period closes without manual reconciliation, and settlements with each seller are visible line by line.

Let's discuss your task: we will get back with an estimate and work plan

To discuss the task concretely, send us the current checkout scheme and the rules for how sellers operate: how the cart is assembled now, at what point items are separated by seller, and what restrictions on delivery, pickup, and payment apply to each party. This is enough to estimate the scope of work, rather than build guesses.

For the review, you will receive:

• an analysis of the current order scheme: where the cart is shared, what data is lost during splitting, and what prevents calculating delivery cost by each seller;
• a map of integration points — cart properties, checkout handlers, exchange with the accounting system, and order statuses;
• an estimate of the scope of work by stage: component enhancements, item separation rules, and the logic of promo codes and discounts across multiple sellers;
• an implementation plan with the order of work — from a prototype on staging to deployment to the production site;
• an acceptance procedure: the set of order scenarios we verify before handoff and the procedure for rolling back to the previous scheme;
• a list of changes in email templates, the customer account, and exports, so that accounting and managers can see separate orders without manual edits.

Describe the task in a convenient form — we will get back with a scope estimate and implementation plan, and point out the risks and stages that will require access to the admin area and staging.