The supplier has stock. But which site can actually fulfil the Medusa order?

The client problem

“In stock” sounds like a complete answer until a supplier operates more than one physical site.

The item may be available in a store across town, a regional warehouse outside the delivery zone and a distribution centre reserved for another territory. The supplier has stock in aggregate, but only one of those locations may be able to serve the buyer’s property through the shipping option selected at checkout.

That was the logistics problem behind a multi-vendor procurement marketplace we built on Medusa.

The platform could not stop at seller-level ownership. It needed to connect five facts throughout the buying journey: who sells the item, where the stock sits, which fulfilment service belongs to that site, whether that service covers the property and which site the final order should instruct.

We modelled stores, warehouses and distribution centres as real stock-owning locations, then carried the accepted fulfilment choice from cart to order.

The result is simple for the buyer: the shipping option they select corresponds to a site that can actually fulfil it.

Why seller-level availability is not enough

Marketplace catalogues often answer availability with a seller and a quantity.

That works when each seller ships from one undifferentiated pool. It breaks as soon as the business has local stores, multiple warehouses, pickup sites or regional distribution centres.

Imagine that a supplier owns ten units of a product:

• four in a store that offers pickup only;
• three in a warehouse serving the buyer’s state;
• three in a distribution centre outside that service area.

The aggregate quantity is ten, but the buyer cannot necessarily choose any shipping method for all ten units. A storefront that displays “in stock” without location and service context may make a promise the operations team cannot keep.

The correct question is not “does the seller own this SKU?” It is “which seller-owned location can serve this basket, for this property, through an eligible fulfilment method?”

Treat physical sites as commerce entities

A store or warehouse should not be a text field added to an order after checkout.

In Medusa, stock locations, fulfilment sets, service zones, shipping options and shipping profiles provide the primitives for modelling the topology. We used those primitives to represent each seller site as a participant in inventory and fulfilment.

The site owns inventory levels. Its fulfilment set describes the services associated with it. Service zones define where those services apply. Shipping options present the buyer-facing choice.

This creates a traceable chain:

seller → stock location → fulfilment set → service zone → shipping option

Every link answers part of the business decision. The seller establishes marketplace ownership. The location identifies the physical source. The service zone establishes geographic eligibility. The shipping option is the promise selected by the buyer.

Without this chain, a shipping label can become detached from the stock and site expected to honour it.

Build a fulfilment plan before the cart completes

Checkout has a moment when several possible routes become one accepted plan.

For each seller represented in the cart, the platform needs to know which selected shipping method maps to which fulfilment set and stock location. We persist that seller-and-location fulfilment plan with the cart.

The plan is important because the decision should not be rediscovered differently after payment or approval. It captures the accepted relationship between the basket, shipping choice and physical source.

When the cart completes, order assignment follows that plan. A resolver walks from the selected shipping topology back to the stock-owning location behind the order. The resulting seller order remains attached to the site responsible for fulfilment.

This is deterministic assignment from an accepted plan. The platform records the route established by the buyer’s choice and the availability rules, then uses it consistently. If the business later needs cost or distance optimisation across several viable sites, that capability can build on the same explicit topology.

Split only where ownership or location requires it

A multi-vendor cart already contains an important boundary: one seller should not receive another seller’s lines.

Multiple sites introduce a second boundary. Two products from the same seller may need different fulfilment instructions when their stock and accepted methods point to different locations.

The cart’s fulfilment plan gives the split logic a concrete key: seller and stock-owning location. Lines that belong together remain together. Lines that require different operational owners can become separate fulfilment units.

This prevents two opposite mistakes.

Splitting every line creates unnecessary operational noise and fragmented orders. Never splitting hides the fact that two sites must act. The right boundary comes from the physical responsibility encoded in the plan.

For the buyer, the journey can still feel like one checkout. Behind it, each seller and site receives the part it can actually fulfil.

Keep the selected method and site aligned

A cart can change after the buyer first chooses shipping.

Quantities move. Lines are added or removed. An approval workflow may ask for revisions. Inventory can change. If the shipping choice remains while its underlying location no longer matches the basket, checkout carries stale operational context.

The platform therefore guards the integrity between seller lines, shipping methods and the location-specific plan. Approval and shipping flows preserve the chosen relationship rather than treating shipping as a decorative price line.

This is especially important in B2B procurement, where a cart may live longer than a typical retail session. A request can wait for approval, return for revision and then be resubmitted. The fulfilment decision has to remain intelligible throughout that lifecycle.

The rule is straightforward: if the basket changes in a way that invalidates the selected path, the platform must ask for a valid path again rather than carrying an impossible promise forward.

Make pickup a location capability

Store pickup illustrates why location modelling matters.

A generic “pickup” shipping option tells the buyer almost nothing. Pickup where? Does that site stock the item? Does the seller operate the location? Is it inside the relevant geography? Which address appears on the order?

In this platform, pickup is tied to a seller-owned location through its own fulfilment set and shipping option. The store route separately checks location inventory before offering pickup for the requested products.

That turns pickup from a zero-price shipping label into a real fulfilment path. The buyer chooses an actual site. The order exposes pickup identity and address. The seller knows where the collection must be prepared.

Pickup deserves a dedicated article because its buyer experience and setup lifecycle are specific, but it depends on the same foundation: physical sites are first-class parts of commerce.

Service zones turn locations into viable options

Stock at a warehouse does not mean the warehouse can serve every buyer.

The site’s fulfilment topology includes service zones. Those zones can represent the seller’s operating territory with structured country, state, city, postal or radius rules. The platform evaluates the buyer property against those rules when determining viable options.

This separates two facts that are often collapsed:

• the location has the product;
• the location serves the destination.

Both must be true before a delivery option is meaningful.

Structured geography also gives operations a maintainable model. A supplier can change its territory without rewriting product records. Intentional overlaps can exist where more than one site serves an area. The selection logic can then apply the product’s explicit distance, price or fulfilment rules to the viable candidates.

Use the buyer’s property, not only their browser

In property procurement, the delivery destination is a business object.

A buyer may manage several properties and switch between them during a session. The relevant geography, distance and available supplier sites follow the active property, not simply the user account or device location.

We persist property-to-stock-location distance results with an address identity. Product and pickup paths can reuse those valid results and rank bounded candidate locations without recalculating an unbounded routing matrix for every search.

That creates a more stable experience. The marketplace can say which viable site is closer in the context of the selected property. If one external distance lookup fails while others succeed, the successful results can still be retained rather than discarding the entire set.

Distance is one input to the fulfilment decision, not a replacement for stock, service zones or seller ownership. A nearby warehouse outside the property’s allowed service topology is still not a viable promise.

What the order needs to remember

Once checkout completes, the operational team should not have to infer the chosen site from an address or SKU.

The seller order needs a durable link to its assignment. That link allows fulfilment screens, pickup information and downstream processes to answer:

• which seller owns these lines;
• which stock location is responsible;
• which shipping or pickup method the buyer selected;
• which property and address the decision served.

This is valuable even before warehouse automation. A human operator can see the intended source of fulfilment without reverse-engineering the cart.

It also creates a foundation for later capabilities such as location-specific acknowledgements, partial fulfilment, pickup preparation and performance reporting. Those capabilities can build on an explicit site identity rather than guessing where an order “probably” belongs.

Why we extended Medusa’s fulfilment model

The client did not need a generic shipping-rate calculator. They needed a marketplace logistics model in which sellers own several physical sites and buyers purchase for specific properties.

Medusa provided strong foundations: inventory by stock location, fulfilment sets, service zones, shipping options, profiles, carts and workflows. We extended those foundations with the missing connective capability:

• seller ownership of locations;
• a persisted cart fulfilment plan;
• deterministic location assignment at completion;
• seller-and-location order splits;
• inventory-gated pickup;
• structured geographic eligibility;
• reusable property-to-location distance.

Choosing Medusa made sense because the platform could absorb this client-specific topology without requiring us to rebuild the commerce lifecycle around it.

The architecture followed the business: the seller has sites, the sites have stock and services, and the order must reach the site responsible for the promise.

A practical modelling checklist

Before offering multi-site fulfilment, answer these questions.

1. Who owns each physical site? Marketplace ownership must be explicit.
2. Where does inventory live? Availability needs a location, not only a seller total.
3. Which services belong to that site? Delivery and pickup should map to actual fulfilment capabilities.
4. Where can each service operate? Model structured zones or radius rules.
5. What makes a location viable for a basket? Combine ownership, stock, geography and method compatibility.
6. When is the choice persisted? Capture the accepted plan before order creation.
7. What is the split boundary? Divide work by the operational owner that must act.
8. How are cart changes handled? Revalidate stale location-specific methods.
9. What does the order remember? Preserve enough site identity for fulfilment and support.
10. Which optimisation is actually required? Deterministic eligibility may be sufficient; advanced allocation is a separate business capability.

This checklist turns “multi-location inventory” into an end-to-end fulfilment contract.

The buyer sees a promise the operator can honour

The customer-facing benefit is not that the database contains stock-location records.

It is that availability, shipping and pickup refer to the same physical reality.

The buyer selects an option that belongs to an eligible site. The order keeps that assignment. The seller’s team knows which location must act. The platform can evolve geography, distance and local services without reducing fulfilment to a seller-level stock number.

That is how WeAreSouk approaches logistics architecture: start with the operational promise the client needs to make, then connect every commerce primitive required to honour it.

If your Medusa marketplace knows which supplier owns a product but not which store or warehouse should fulfil it, we can map the stock and shipping topology and build a location-aware journey from search to order.