- “Collect in store” looks like the simplest fulfilment feature in commerce.
- Remove the delivery charge, show a store address and let the buyer choose pickup.
- Then pickup is no longer a label.
- For a multi-vendor marketplace built with Medusa, we modelled pickup as a real fulfilment path rather than a zero-priced delivery workaround.
The client problem
“Collect in store” looks like the simplest fulfilment feature in commerce.
Remove the delivery charge, show a store address and let the buyer choose pickup. That works until the marketplace has several suppliers, each supplier has several stores or warehouses, stock differs by location and buyers operate from properties across different territories.
Then pickup is no longer a label. It is a promise made by one physical location: this site belongs to the right seller, serves this buyer's geography, holds the chosen product and can become the fulfilment destination for the order.
For a multi-vendor marketplace built with Medusa, we modelled pickup as a real fulfilment path rather than a zero-priced delivery workaround. A supplier can enable it for an owned stock location. The platform creates a dedicated pickup topology, keeps its eligible geography aligned with that location's delivery configuration and exposes pickup only in a location and inventory context the buyer can actually use.
The business outcome is simple to describe: the buyer sees a credible place to collect the product, not every address that happens to carry the supplier's name.
A store address is not a pickup capability
A seller location contains useful facts: address, stock levels and links to fulfilment sets. None of those facts alone means the site accepts customer collections.
A warehouse can hold stock without a public counter. A store can accept pickup only for products physically available there. A location may serve one region while a buyer belongs to another. A marketplace also needs to remember which fulfilment option the cart selected so the eventual seller order follows the same site.
We therefore treat pickup enablement as an explicit operational decision at seller-location level. The vendor cannot enable it on somebody else's location. The workflow first verifies ownership, then checks that the site already has a shipping geography from which pickup eligibility can be derived.
This prevents the platform from inventing a service area or turning every stock location into a public collection point by default.
Pickup starts with a real site that the supplier controls and has configured for commerce.
Give pickup its own fulfilment identity
In Medusa, fulfilment sets and service zones provide the vocabulary for connecting locations, methods and geography.
When pickup is enabled, the workflow creates a fulfilment set whose type is pickup. It then creates a pickup service zone and a pickup shipping option linked to the seller. The option uses the supplier's shipping profile, but its fulfilment type remains distinct from normal delivery.
That distinction lets the storefront return one coherent list of applicable fulfilment choices while still telling delivery and collection apart. A buyer interface can display an address and collection wording for pickup, and a delivery estimate or price for shipping.
It also keeps return methods out of the buyer's normal choice set. Options explicitly marked as return methods are filtered separately instead of leaking into checkout because they happen to be attached to a service zone.
The underlying primitive may still be called a shipping option in Medusa's model. The business capability is a location-specific collection path with its own identity and rules.
Inherit geography instead of maintaining it twice
A supplier should not have to redraw the same operating territory merely to enable pickup.
The pickup zone is derived from the location's existing shipping fulfilment sets. Country, province, city and postal expressions are collected, deduplicated and copied into one pickup service zone. The shipping side remains the source of truth.
When shipping geography changes, the pickup zone can be regenerated from the current source. The synchronisation uses replace semantics: old derived pickup zones are removed and one fresh zone is created from the deduplicated shipping geography.
This is important for operations. Two editable copies of the same territory will drift. A supplier will update delivery coverage and forget pickup, or vice versa. Derivation turns that human coordination problem into a deterministic rule.
The rule is also appropriately bounded. Inheriting the territory does not mean delivery and pickup are identical services. It means the buyer-property perimeter used to expose the site starts from a geography the supplier already owns and maintains.
Do not show an out-of-area pickup site
Pickup may involve travel by the buyer rather than a delivery by the seller, but geography still matters.
A national marketplace should not show every enabled store for every product. A collection point hundreds of miles away is technically an address and practically noise. A supplier may also deliberately limit which customer properties a location serves.
When a buyer has a selected property, the storefront resolves shipping options whose service-zone geography covers that property. The resolver explicitly includes both shipping and pickup fulfilment types; otherwise a default delivery-only query would discard every collection option.
The seller's options are intersected with that deliverable set before they reach the buyer. If none remain, the response is empty rather than falling back to a generic marketplace option.
This makes availability contextual. Pickup can be enabled for the store and still remain invisible to a buyer whose property lies outside the derived operating area.
Stock must exist at the location offering collection
Seller-level availability is too broad for pickup.
The supplier may have ten units across its network while the nearest store has none. Showing pickup because “the seller has stock” would make the buyer travel to the wrong site or force an unmodelled internal transfer.
The marketplace therefore resolves eligible product locations for pickup and uses the same location-inventory context when enriching product and seller options. The dedicated pickup-distance path requests locations with pickup enabled and returns the chosen stock-location identity alongside its distance and address.
For ordinary delivery options on a product page, the route also checks whether the selected variant can fulfil one unit at the location behind the shipping topology. Pickup remains gated through its dedicated location and distance resolver.
The important promise is narrow and useful: a displayed pickup result is tied to a pickup-enabled stock location considered viable for that product context. It is not a claim that stock can never change before checkout completes.
Use distance to make the choice understandable
An eligible store is not automatically the useful store.
The buyer needs a location name, address, postcode and meaningful distance from the selected property. The product pickup endpoint resolves that context and returns rounded miles plus the pickup location identifiers.
The response can enrich product cards without blocking the base catalogue experience. Visible product IDs are bounded per request, filtered through the buyer's accessible catalogue and resolved through the shared property-to-store distance contract.
This turns a technical eligibility result into a buyer decision: “Available for pickup at this location, approximately this far from your property.”
Distance is not presented as a universal optimisation score. It helps rank or explain viable sites. Price, operational preference or future stock transfers may lead a business to choose differently. The system exposes the physical context needed for a sensible interface.
Enable pickup safely when two operators click at once
Location configuration is an administrative workflow, and administrative actions are often retried.
Two requests to enable pickup at the same moment must not create duplicate fulfilment sets, zones or options. The vendor route holds a per-location database advisory lock around the workflow. Once inside, an idempotency probe checks whether a pickup fulfilment set and option already exist.
If they do, the workflow returns the existing identifiers. If not, it creates the missing topology in sequence. Mutating creation steps carry compensation so a later failure can remove the fulfilment set or shipping option they introduced. The derived zone sync can be regenerated by the next configuration mutation.
This is not merely clean implementation. Duplicate buyer options and orphaned seller links are operational defects. A retry-safe toggle gives vendors one stable capability even when browsers retry or operators act concurrently.
The user sees a switch. Underneath, that switch coordinates several Medusa entities as one business change.
Keep the cart connected to the selected location
Discovery is only the first half of pickup.
Once the buyer selects a method, the fulfilment plan must retain the seller, stock location and chosen option that made the promise viable. Completion cannot later assign the order to a different site merely because that site belongs to the same vendor.
The broader marketplace flow builds a persisted seller-and-location fulfilment plan for the cart. Shipping-method validation and the split-and-complete order workflow use that accepted topology when turning a multi-vendor cart into seller-specific orders.
For pickup, this means the order remains connected to the collection location rather than carrying only a generic “pickup” label. Order APIs expose pickup identity and its address separately from the seller's general location shape, so the buyer and vendor can understand where collection happens.
The business journey remains coherent from product discovery to checkout and order operations.
Mark the order ready instead of pretending it shipped
Collection has a different operational moment from delivery.
A seller does not hand a pickup parcel to a carrier. It prepares the goods and tells the buyer when they are ready. The platform therefore includes a vendor action and notification path for an order becoming ready for pickup.
That distinction matters to customer communication. “Your order shipped” is misleading when the parcel is waiting behind a store counter. “Ready for pickup” tells the buyer what happened and what they should do next.
The fulfilment type selected earlier gives downstream workflows the context to use the appropriate language and address. The capability is not complete merely because checkout accepted a zero-cost method.
Good commerce modelling follows the buyer's real-world next step. For delivery, wait for the carrier. For pickup, travel to the specified site once the seller has prepared the goods.
Why Medusa was the right foundation
Medusa already modelled stock locations, fulfilment sets, service zones, shipping profiles, options, carts and order workflows. The client needed those primitives to express a multi-vendor pickup promise that standard configuration did not assemble automatically.
We extended the engine at the right boundaries. Seller ownership controls enablement. Existing shipping geography becomes the source for derived pickup coverage. Inventory and distance determine which locations are useful to the buyer. The fulfilment plan preserves the selected site through checkout.
This is why an extensible commerce engine matters. We did not bolt a store locator beside checkout and hope the two stayed aligned. We made collection part of the same fulfilment model that already governs product availability and orders.
The added capability fits the client's supplier network instead of forcing that network into one generic delivery method.
A practical pickup checklist
Before offering store collection, define:
- Which seller owns each pickup location?
- Is pickup explicitly enabled or inferred from an address?
- Does the location already have a trusted service geography?
- Is pickup represented separately from delivery and returns?
- How does pickup geography stay aligned after vendor edits?
- Can out-of-area sites appear to the buyer?
- Is the selected variant in stock at the actual site?
- Which property or customer address anchors distance?
- How many product-location candidates may one request resolve?
- What happens when distance resolution fails for one site?
- Can repeated enable requests create duplicate options?
- What compensates a partially failed configuration workflow?
- Does the cart persist the selected seller and location?
- Does order completion preserve that plan?
- Can the seller mark the order ready for pickup?
- Does the buyer receive collection-specific communication?
These decisions separate a credible fulfilment promise from a free-shipping label.
The broader lesson
Pickup is physical commerce.
It only works when the platform can answer four questions together: who owns the site, which buyers it serves, whether the product is there and whether the order will remain attached to that location.
For this marketplace, enabling pickup creates a dedicated Medusa fulfilment path under the seller-owned stock location. Geography is derived from the location's maintained delivery territory. Buyer-facing options are filtered by property context, inventory and pickup eligibility. Distance explains the viable site, and the accepted fulfilment plan follows the cart into the seller order.
The buyer experiences one straightforward choice. The supplier receives an order tied to a real place. Operations do not have to reconcile a generic checkout label with a different inventory or warehouse system later.
That is the difference between displaying pickup and actually supporting it.