One basket contains items from three sellers and one line the customer wants to collect in store. What does that do to your design?

One order to the customer, several orders to the operation

The customer bought once, so she has one order number, one confirmation, one payment on her statement and one place to look for progress. That is a product requirement and it should not bend. Everything underneath is a different shape.

The model that holds up has three levels. The customer order is the commercial agreement with the shopper, carrying the total she agreed to pay and the addresses she gave. Beneath it sits one fulfilment order per seller per destination, which is the unit a seller sees in their portal, the unit that gets its own despatch note and tracking, and the unit that ends up in a payout. Beneath that sit the lines and their allocations. The collect-in-store line produces a fulfilment order too, addressed to a store rather than to a customer, which is what stops click-and-collect becoming a special case threaded through the whole codebase.

Splitting has consequences you must face at the point of purchase rather than after it. Three sellers means three delivery estimates and potentially three delivery charges, and the customer needs to see that before paying, since discovering it afterwards is a dispute. Cancellation and returns become per-seller operations with per-seller policies, which the platform must normalise to a minimum standard or the experience is a lottery. Tax treatment can also differ line by line, because sellers may be established in different countries.

Who is the merchant of record decides most of the architecture

Before designing any payment splitting, answer a question that is legal rather than technical: for each line, who is selling to the customer? If the platform is the merchant of record, it takes the money as its own revenue, it owes the tax, it owns the consumer relationship and it buys from the seller separately. If the seller is the merchant of record and the platform is an agent, the money is the seller's from the moment it is paid and the platform's revenue is only its commission.

The distinction is not cosmetic. It determines whose revenue appears in your accounts, who is liable when the goods never arrive, whose name appears on the customer's card statement, and whether the funds sitting in your account between payment and payout are your money or somebody else's. That last point is the one that catches engineering teams: holding other people's money as a business is a regulated activity in most jurisdictions, and building an internal balance table that accumulates seller funds in your own bank account can put you inside a licensing regime you were not planning to enter.

The usual way out is to use a payment provider's marketplace facility, where the provider holds the funds against sub-accounts belonging to the sellers and performs the split and the payout under its own licence. You then keep the commercial ledger and the provider keeps the money. That is a sound division of responsibility, but it makes the provider's model a hard constraint on yours, so its rules about split timing, reserve balances and payout schedules need reading before the design is fixed, not after.

Two obligations are worth knowing exist even if the details vary by market. Several US states make the marketplace facilitator, rather than the seller, responsible for collecting and remitting sales tax on facilitated sales. And in the EU, DAC7 requires platforms to report identity and income information about their sellers, so onboarding must capture and verify data you would not otherwise ask for.

Payouts are a ledger problem, and the ledger must go negative

The naive payout is a scheduled transfer of the order total minus commission once the item ships. It breaks on the first refund, because by then the money has gone.

What you need is a double-entry ledger per seller in which every event posts entries, and the payout is the settlement of a balance rather than a calculation over orders. A sale credits the seller and credits the platform its commission. Fulfilment may release funds from a held state to an available one. A refund debits the seller. A chargeback debits the seller and posts the dispute fee wherever your seller agreement says it lands. Each payout is a debit against the available balance, with an identifier that ties it back to the entries it settled.

Seller ledger, one sale of 100 with 15% commission, refunded after payout:

  sale               seller +100   platform commission -15   seller available  85
  payout             seller  -85                             seller available   0
  refund             seller -100                             seller available -100
  commission reversal seller +15   platform commission +15    seller available -85

The instructive line is the last balance. A seller can legitimately owe the platform money, so the ledger has to permit a negative available balance and the design has to say how it is recovered - netted against future sales, drawn from a rolling reserve withheld at payout time, or collected directly under the seller agreement. A reserve is the standard answer and it is really a credit decision: withhold more from a new seller with no history and from categories where disputes arrive late, less from a seller with years of clean trading.

Hold periods exist for the same reason. Paying out the instant an order is marked shipped means paying before the customer has had a chance to say the parcel was empty, so funds normally become available some days after delivery, and the length of that window is a risk parameter rather than a technical detail. Reconciliation closes the loop: ledger balances plus everything paid out must equal what the provider says it holds, checked daily, with a break investigated rather than absorbed.

Click-and-collect is a promise made against the least accurate count you own

Here is where designs that look complete fall over, and it is a physical problem rather than a software one. A distribution centre exists to be counted. It has receiving docks, fixed locations, scanners at every move, and staff whose job is inventory accuracy. A shop exists to be shopped in. Customers pick items up, carry them to another aisle and abandon them, staff sell the last unit over the counter, units are stolen, deliveries are put on the shelf before being received into the system, and the point-of-sale feed may reach your platform on a delay measured in minutes or hours.

The result is that a store's count for a given item is materially less reliable than a warehouse's, and it is wrong in a direction that matters: the system usually believes there is more than there is. Treating a store as a small warehouse therefore produces a specific, expensive failure - a customer who has paid, driven to the shop, and is standing at a counter while an assistant searches for something that is not there. That single incident costs more goodwill than a dozen slow deliveries, because the customer did the work and you did not.

Designing for it means several things at once. Advertise a per-store buffer, so the last unit or two are not promotable to collection, sized per category from that store's own observed error rate rather than as one global number. Require an explicit pick-and-confirm step before the customer is told the order is ready, so the promise is made after a human has the item in hand rather than when the order is placed, and be honest in the interface about the difference between "available" and "confirmed ready". Feed every failed collection pick back as a correction and a trigger for a count of that item, since a failed pick is a free and precise accuracy signal. And measure the metric that matters, which is the share of collect orders that a store cannot fulfil, per store, because it will vary enormously between stores and the variation tells you where the process rather than the software is broken.

The reservation also needs an expiry with a defined consequence. An uncollected order occupies space in a back room that has very little of it, so after a stated number of days the units return to sellable stock and the payment is refunded - and the customer is told that at the point of purchase rather than discovering it when she arrives on day twelve.