- A buyer does not think in marketplace sub-orders.
- They build one basket for a property.
- Behind that basket, the platform may have a much harder job.
- That was the client problem we solved on a B2B marketplace built with Medusa.
The client problem
A buyer does not think in marketplace sub-orders.
They build one basket for a property. They choose what they need, compare the available delivery options and expect one clear path to confirmation.
Behind that basket, the platform may have a much harder job. The products belong to different sellers. One seller may fulfil from several stores or warehouses. Each seller has its own shipping methods, stock constraints and delivery territory. Some baskets need approval before completion. The final transaction may create several operational orders.
That was the client problem we solved on a B2B marketplace built with Medusa.
We wanted to preserve one coherent checkout for the buyer without hiding the facts that sellers and fulfilment sites need downstream. The central capability was a persisted fulfilment plan: a cart-level record of which seller, location and shipping choice belongs to each part of the basket.
The buyer sees one journey. The platform carries enough structure to create the right orders.
Why a global shipping choice breaks in a marketplace
A conventional single-merchant checkout can often ask one question: which shipping option applies to this cart?
A marketplace cart asks several versions of that question at once.
Seller A may offer local delivery and pickup. Seller B may ship from a regional warehouse. Seller C may serve the buyer’s property only from one of its stores. A single “standard shipping” value at cart level cannot explain who will fulfil what, from where or under which commercial promise.
The naïve alternatives are equally problematic.
One option is to split the cart into separate checkouts before the buyer pays. That makes the platform’s internal organisation the buyer’s burden. Another is to pretend the cart has one global method and attempt to reconstruct seller-specific fulfilment later. That delays a critical decision until after the buyer believes the order is settled.
We chose a third model: keep one cart, but represent fulfilment per seller and location inside it.
The fulfilment plan is the contract behind checkout
The fulfilment plan records the decisions that connect cart lines with their operational path.
At a simplified level, each part of the plan answers:
- which seller owns these lines;
- which stock location is expected to fulfil them;
- which seller-specific shipping method the buyer selected;
- which service topology made that method eligible.
The plan is exposed in the buyer flow and persisted with the cart. It is not recreated from labels on the final screen.
This gives the checkout a stable internal contract. The interface can still present one page and one progression, but every delivery choice has a seller and location identity behind it.
When the cart eventually completes, the split-and-complete workflow can use those accepted decisions to create the downstream seller orders. The split is an execution detail of one buying journey, not a surprise introduced after it.
Query shipping methods in the context of each seller
Shipping methods are not interchangeable rows in one global list.
The marketplace needs to query and filter methods for the seller, basket lines, stock location and buyer property involved. A method is meaningful only if its fulfilment path can serve that part of the cart.
The shipping workflows therefore operate on seller-specific choices. They add, remove and validate methods in the context of the fulfilment plan rather than applying one method indiscriminately to every line.
For the buyer, this can appear as grouped choices: these products arrive through one seller’s local service, while those products use another seller’s warehouse delivery. The UI explains the natural consequence of buying from several businesses without forcing the buyer to place several orders manually.
For operations, each selected method remains attached to the seller and site expected to honour it.
Preserve the decision when the cart changes
B2B carts have a longer and less linear life than many retail baskets.
A buyer may submit for approval. An approver may request a quantity change. The buyer may revise the cart and resubmit. During that time, shipping decisions must remain connected to the lines they were chosen for.
The platform uses shipping guards to protect seller-and-location method integrity through those revisions. If a change remains compatible with the accepted plan, the context can continue. If the basket no longer matches the method, checkout must request a valid choice again.
This avoids two frustrating outcomes.
The first is unnecessary loss: every small revision wipes all delivery work and makes the buyer start again. The second is silent staleness: the old method remains even though its seller, stock or location context no longer fits the basket.
A coherent checkout preserves what is still true and revalidates what changed.
Approval belongs before final completion
For this marketplace, some purchases require organisational approval.
Approval cannot be bolted on after seller orders have already been created. At that point, the platform would need to cancel or hold several operational objects while the buyer’s organisation is still deciding whether the purchase is authorised.
The cart-completion route therefore integrates the approval decision before invoking the final split-and-complete workflow. The cart remains the shared commercial context while approval is pending. Once the purchase is eligible to complete, the platform can create the downstream orders from the accepted fulfilment plan.
This keeps the sequence intelligible:
- the buyer assembles one cart;
- seller-specific fulfilment choices are recorded;
- required organisational approval is resolved;
- the cart completes into the operational seller orders.
The approval system and the marketplace split solve different problems, but their order matters.
Validate the accepted plan, not a new invisible plan
Conditions can change between selection and completion.
The right response is not to run an opaque optimisation that silently replaces the buyer’s choices. It is to validate that the accepted seller, location and shipping relationships still form a coherent checkout.
The platform checks the integrity of the shipping methods represented in the plan. The completion path then relies on that validated context when creating seller orders.
This distinction matters for trust. If a selected method is no longer viable, the buyer should be asked to choose from the valid options rather than discovering after confirmation that the platform assigned something else.
The checkout promise is therefore preservation plus validation. The system remembers what the buyer selected, checks that the associated topology is still coherent and carries the decision into order creation.
One checkout does not mean one operational order
From the buyer’s perspective, one checkout is valuable because it combines intent, approval and confirmation.
From the marketplace’s perspective, each seller remains responsible for its own lines. A seller should not see another seller’s commercial data or fulfil their products. A location-specific order must reach the site attached to the accepted shipping path.
Medusa’s commerce model and the marketplace split workflow give us the foundation for that separation. The fulfilment plan supplies the missing project-specific context.
This allows the platform to maintain both truths:
- the buyer placed one coherent purchase;
- several sellers or sites may need to execute it independently.
The buyer-facing order experience can aggregate those outcomes while seller operations remain scoped to the work each party owns.
Assignment should follow business responsibility
Seller order creation answers who owns the commercial lines. Operational assignment may need another layer.
A Store Manager can be responsible for a particular site. An Account Manager can own the relationship for the buyer’s territory or property group. The order context can be used to route visibility and action to the appropriate responsible person.
That assignment is valuable because a seller organisation is not one shared inbox. The person who can act on a warehouse order may differ from the person who follows the commercial account.
The checkout does not need to expose this hierarchy to the buyer. It needs to preserve the property, seller and location facts that make correct routing possible downstream.
This is a recurring architecture principle in B2B commerce: collect the business context once, then carry it through each transition instead of asking every operational module to infer it again.
Keep payment and order splitting as separate concerns
A multi-seller checkout also raises payment questions. Does the buyer make one payment? How is financial state represented on the split orders? What changes for purchase-order terms?
Those questions deserve explicit provider and payment-state contracts. They should not be hidden inside fulfilment planning.
The fulfilment plan decides which seller and location must execute each part of the purchase. Payment providers and split-payment state describe how the financial commitment moves. Keeping those responsibilities separate makes both easier to reason about.
For example, an account-term purchase order is not the same as a successful card charge. It can still participate in the same checkout and seller-order structure while retaining validation, buyer confirmation and seller capture stages of its own.
The coherent experience comes from coordinating these contracts, not collapsing them into one status.
Quotes can enter the same order journey
B2B buyers do not always begin with a fixed-price cart.
They may request a quote, discuss quantities or prices with a seller and accept a negotiated proposal. If that process ends in an email attachment that somebody must retype into checkout, the platform loses the context it worked to create.
The marketplace models quotes and edits as durable commerce entities. An accepted quote can resolve its shipping choice and convert its draft order into the Medusa order path.
This is adjacent to the standard-cart story but reinforces the same principle: one coherent purchase journey depends on preserving commercial context through transitions. Whether the buyer begins with catalogue checkout or negotiation, the final order should inherit the decisions that led to it.
Why Medusa was the right foundation
This client needed more than a multi-vendor cart screen.
They needed carts, seller ownership, stock locations, shipping topology, approvals, quotes, payment terms and downstream order operations to work as one product.
Medusa provided the commerce primitives and workflow model. The marketplace layer supplied split order behaviour. We added the fulfilment-plan contract and the project-specific coordination around seller methods, locations and approvals.
That choice let us extend a coherent commerce engine rather than integrate several disconnected checkout, approval and order systems after the fact.
The architectural value is visible in the buyer experience: complexity remains behind one journey because the platform has explicit contracts for the complexity instead of ignoring it.
A checkout design checklist for multi-vendor operations
Before building the interface, answer these questions.
- What does the buyer experience as one purchase? Define the cart, approval and confirmation boundary.
- What belongs to each seller? Lines, shipping choices, payment state and operational visibility need explicit ownership.
- Does fulfilment depend on a physical site? Carry location identity with the shipping method.
- Where is the accepted plan persisted? Do not reconstruct it from labels after completion.
- What happens when the cart changes? Preserve valid choices and invalidate stale ones.
- When does approval occur? Resolve authorisation before creating downstream operational orders.
- What is validated at completion? Check the accepted plan rather than silently inventing a replacement.
- How are orders split? Use seller and location responsibility, not arbitrary line boundaries.
- Who operates each resulting order? Preserve the facts needed for site and account assignment.
- How do payment and quote lifecycles join the journey? Coordinate them without confusing them with fulfilment.
If those contracts are explicit, the UI can be simple without the platform being simplistic.
Complexity behind the checkout, clarity in front of it
The buyer should not have to understand the marketplace’s internal order graph.
They should understand what will arrive, through which option, for which property and what happens next. The system should then give each seller and site the exact work it owns.
We achieved that by persisting the fulfilment decision before completion, preserving it through approval and revision, validating it at the final transition and using it to create the downstream seller orders.
Medusa was the commerce foundation. The client’s multi-vendor and multi-site operating model shaped the capability we built on top.
If your marketplace checkout looks simple only because seller, location and shipping decisions are postponed until after the order, WeAreSouk can map those contracts and build one buyer journey that remains operationally coherent behind the scenes.