Skip to main content
In development. 86d is being built in the open. Every capability is Experimental until it earns evidence, so check maturity levels before you rely on anything here.
A purchase leaves behind several records, and most commerce bugs come from treating one of them as proof of another. A paid Order is not a shipped Order. A bought label is not a delivered Parcel. 86d keeps these separate on purpose, and this page is the map. Trace a purchase in this order: Cart, then Checkout, then Order. Payment, Fulfillment, and Shipping sit beside the Order rather than replacing it.

​
What each record proves

​
Checkout recalculates the money

Checkout is where the Store decides what a purchase actually costs, and it works out every one of these on the server:
  • Product and Variant identity
  • price, discounts, and Loyalty redemption
  • Inventory availability and reservations
  • Shipping options and cost
  • tax treatment and amount
  • which Payment Connection handles the charge, and what the provider answered
A browser can ask for a price and display one. It cannot set one. The same goes for an agent: it can propose a Cart, and the server still prices it. When a required decision is missing, Checkout stops rather than guessing. If tax or a Shipping quote cannot be resolved, the Store can save a non-binding Checkout Request instead: it holds what the Shopper asked for and the estimate they saw, stores no card details, reserves no stock, and creates no Order. When the Store can fulfill it, Checkout runs the numbers again and the Shopper accepts the new offer or walks away.

​
A refund goes back the way it came

A Payment records which Payment Connection took the money. Refunds, disputes, and every later provider operation go back through that same Connection. If it has been revoked or is unhealthy, the operation stops and asks for attention. 86d does not reroute a refund through a different processor, because the money is not there. Provider events have to be authenticated, scoped to the right Store, and deduplicated before they are allowed to change a Payment or an Order.

​
Delivery does not close an Order

One Order can have several Fulfillments. One Fulfillment can need several Parcels. A Fulfillment can also cover zero Order lines, which is how an Order-level obligation like a service call or a gift note gets tracked without claiming that any item shipped. Buying a label means the Parcel is pre-transit. Nothing has moved. Delivering one Parcel closes that Parcel, not the Order. An Order closes when its commercial, Payment, dispute, and Fulfillment obligations are all terminal. Someone with authority can close one manually, and that stays visible in the audit history with who did it and why.