Multi-vendor checkout: one payment, many vendors, zero confusion

A multi-vendor cart looks like one order to the shopper and behaves like several to everyone downstream. One card charge — but three vendors who each pack, ship, invoice and occasionally refund on their own schedule. Getting that split clean, so the customer never feels the seams, is most of the engineering behind a marketplace checkout. Here is the split-order model we run in production and the edge cases that shaped it.

One payment, many sub-orders

When a shopper checks out with items from three shops, we take a single payment and immediately fan the basket out into one sub-order per vendor. The parent order is a thin envelope: it holds the payment reference, the customer identity and pointers to its children. Each child sub-order carries its own line items, its own shipping line, its own VAT breakdown, its own fulfilment status and its own invoice.

Why split at all? Because every actor downstream of the pay button operates per vendor. A vendor packs and ships only its own items. An accountant needs VAT per selling entity, not a blended total. A refund almost always concerns one vendor's parcel, not the whole basket. If you keep the order flat, you pay for that decision again and again in each of those workflows. Splitting once, at the moment of payment, is cheaper than un-blending later.

Make the split idempotent. Payment webhooks retry, and a shopper who double-clicks pay must never spawn two sets of sub-orders. Key the fan-out on the payment reference so a repeated event resolves to the same children rather than duplicating them. The same discipline protects you when a payment provider re-sends a status change hours later: the event finds the existing sub-orders and updates them in place instead of creating a phantom second order that would corrupt both fulfilment and the books.

A useful mental model is that the parent is a coordination record and the children are work records. Anything the customer experiences as one thing — the charge, the confirmation, the contact details — belongs on the parent. Anything a single vendor owns and acts on — packing, shipping, invoicing, refunding, being paid — belongs on the child. When you are unsure where a field goes, ask which of those two actors needs it, and the answer is usually obvious.

Shipping is charged per vendor, not per basket

The most common mistake is a single flat delivery fee across a mixed basket. It is wrong in both directions: it overcharges a shopper buying one small item, and undercharges a basket that pulls from a distant, heavy vendor. We compute each vendor's real fee and free-shipping threshold independently, then show the sum with the breakdown visible. A shopper who is a few euros short of one vendor's free-shipping line should see exactly that, for that vendor, in the cart — not a blended number that means nothing to anyone. The full model, including a vendor that ships cross-border on weight-based rates we crawl from its own checkout, is in per-vendor shipping.

VAT lives at the sub-order level

Because each vendor is its own selling entity, VAT is computed and reported per sub-order, never on the blended basket. That includes the VAT on shipping, which follows the goods and is easy to forget. On our marketplace, prices display inclusive of Estonia's standard 24% VAT, and each sub-order's invoice states the net, the VAT and the gross for both the items and the delivery line so the figures reconcile end to end. We go deeper in VAT for online marketplaces and marketplace invoicing.

Partial fulfilment and partial refunds

Once an order is split, most exceptions become single-vendor events. One vendor ships today, another is out of stock until Thursday, a third cancels a line. Because each sub-order has its own status, the parent's status is a roll-up of its children — partly shipped becomes a real, displayable state instead of a lie in either direction.

Refunds work the same way. A return concerns one vendor's parcel, so the refund is issued against that sub-order and its invoice, and the parent total is recomputed from the children. The subtlety worth engineering carefully: the VAT on a partial refund has to reverse out of the same sub-order's VAT it was booked against, or your monthly bookkeeping stops reconciling. Refund the money without reversing the tax and the numbers drift a little every month until someone spends an afternoon hunting the gap.

Communicating a fan-out order to the customer

A split order needs communication that hides the split from the customer while respecting it operationally. We send one confirmation that echoes the whole basket back at the moment of payment, then a dispatch email per parcel as each vendor ships, then a delivered notification driven by carrier tracking webhooks. The customer experiences one coherent story — "you ordered these things; here is each parcel on its way" — even though three independent fulfilment clocks are running underneath. The email layer has its own failure modes, covered in transactional emails.

Getting each order to the right vendor

The last step is routing each sub-order to the vendor who fulfils it. Vendors join our marketplace by having their existing store ingested; they do not change their workflow, so forwarding has to meet each vendor where they already are rather than demanding a new dashboard login. The parent order coordinates payment and customer comms; the sub-orders are the unit of fulfilment, refund and settlement. Choosing a payment provider, moving money to each vendor and reconciling those sub-orders against the provider's own records is a subject of its own — see marketplace payments.

Frequently asked questions