Cart and checkout

The problem#

A store cart is a list of items. A marketplace cart is a list of items belonging to different people, each with their own shipping, their own return terms and their own settlement. The buyer is not supposed to notice, and the system has to know from the first item.

Checkout adds a second thing: it is the only moment at which you can record what the world looked like at the time of purchase. Anything you do not record then will later be read from live records that will have moved on.

Minimum version#

• A cart line knows its seller. That is one field and everything else depends on it.
• The cart can group lines by seller, even when there is one group.
• Shipping is chosen and priced per group, not per cart.
• Availability and completeness are validated at order creation, not at add-to-cart.

What to record at purchase time#

This is the real substance of a checkout chapter. It is not about the form, it is about the list of things that stop being readable later.

What not to build yet#

• Separate per-seller carts in the interface. The buyer should see one cart; the split is the system concern.
• A shipping calculator with weight and dimension rules, before anybody asks for one.
• Carts persisted across devices, until you have accounts with real usage.
• Holding goods for longer than the checkout session.

Plan ahead#

A grouping key separate from the seller#

Today you group by seller. Tomorrow a shipping location or a delivery method may join it. If the group is derived from an explicit key rather than hardwired as "by seller", adding a second dimension is one function instead of a checkout rebuild.

Payment and order as two events#

A successful payment does not mean an order exists. Those are two operations in two systems, and anything can happen in between. The model has to allow the in-between state and give you a way to close it or unwind it.

Validation in one place#

Checking availability, address completeness and shipping validity should be one operation run right before the order is created. Spreading those checks through the interface ends with every new purchase path skipping one of them.

Triggers#

• a buyer asks why they are paying shipping twice;
• the first payment that produced no order;
• a seller changes a price while somebody has the item in their cart;
• a second purchase path appears, for example guest checkout;
• a buyer wants to cancel part of an order.

Next stage#

After the second trigger: a way to reconcile payments against orders, even if it is only a list of discrepancies to review by hand. After the fourth: lifting validation into one operation that every path calls. After the fifth: that is the order model chapter.

Common mistakes#

What works in practice#

With a year and a half behind it, what paid off most was treating checkout as a moment of recording rather than as a form. Everything touching money is persisted then: line values, the rate applied and the shipping chosen. Later changes to the catalogue and the configuration therefore move nothing that has already happened.

The second lesson was separating payment from order. Money taken with no order created is rare, but it does happen. If the model does not allow for it, the only remedy is digging through data by hand.

Checklist#

• A cart line knows its seller, whatever today model is.
• Grouping is derived from an explicit key, not hardwired into checkout.
• Shipping is chosen and priced per group.
• Validation happens once, right before the order is created.
• Every value needed for settlement is recorded at purchase time.
• There is a way to detect a payment with no order.