Design checkout, payment and shipping

Checkout configuration

Four sets of rules meet at the end of a cart. What to decide, and where each decision lives.

Checkout is where every configuration decision in this area becomes visible to a buyer at once. It is also the place people look for a single settings page, and there is not one: what a buyer meets at the end of a cart is assembled from rules that live in four different places.

Before you begin. Have at least one payment method and one shipping method enabled, and know which market and currency the checkout runs in. A checkout with nothing eligible to offer is the most common "the shop is broken" report on a fresh tenant.

What happens at checkout

The storefront asks three questions and then places the order.

  1. Which payment methods apply? It sends the buyer's country, the order amount and the currency, and gets back only the methods that are eligible, each with its computed fee.
  2. Which shipping methods apply, and what do they cost? It sends the country, the net and gross order value, the weight and any product attributes a rate matrix might price on, and gets back the applicable methods with prices and delivery estimates, plus the excluded ones with reasons.
  3. May this person place this order? The buyer's permissions and the approval threshold decide whether the result is a placed order or a pending one.

All three are evaluated server-side. The storefront renders the answer; it does not decide it. That is why a method that "should not appear" is never fixed in the theme.

The decisions, and where each one lives

DecisionWhere you set it
Which payment methods exist, their fees and limitsOrder Management › Payments › Methods
Which shipping methods exist and what they costOrder Management › Shipping › Methods
Free shipping above a valueThe method's own threshold, or one shop-wide setting
Whether an order needs approval above a valueThe Orders app's approval threshold
The currency stamped on an order that names noneThe Orders app's default currency, per market
The maximum number of positions on one orderThe Orders app's position cap (default 500)
Whether a converting cart holds stockThe Carts app's reservation setting
Which price a converted cart is booked onThe Carts app's price-snapshot setting
Fields a buyer fills in, such as PO number, cost centre, delivery dateYour storefront's checkout page

The last row is the one that catches people out. The capture of the buyer's own PO number happens in the storefront; the storage is a first-class field on the order (customer_order_number). If your checkout does not ask for it, the field stays empty and your invoices go out without the number the buyer's AP department matches on.

The four B2B fields worth insisting on

FieldWhy it earns its place
Purchase order numberThe buyer's own reference. Missing it is a payment delay, not a cosmetic gap. Lands in customer_order_number
Cost centreWhich budget the line is booked to. Stored per position, because one order can span several
Delivery date wantedWunschtermin. Common in project business, and it belongs on the order rather than in a comment
Position textThe buyer's own text on a line: their internal article number, a machine number, a floor

Cost centre and position text are per-position fields on the order, which is the right granularity. A buyer ordering for three departments in one basket needs three cost centres.

Prices: which one the order is booked on

A cart line carries two prices: the one shown when the buyer added it, and the current one if the catalogue has moved since. When the cart converts, one of them wins, and that is a setting.

  • Snapshot books the price the buyer was shown. Predictable, and defensible in a dispute. This is the default.
  • Current re-reads the price at conversion. Correct if you never want to sell below today's price, and a support case waiting to happen if a buyer leaves a cart open over a price change.

Whichever you choose, the order freezes afterwards. See The order lifecycle.

Reserving stock at checkout

Conversion can ask the stock system to hold the goods. Three positions:

SettingBehaviour
NeverNo hold. Fastest, and two buyers can order the last item
ReserveAsk for a hold; carry on if it fails
RequireAsk for a hold; refuse the conversion if it fails

Require is right when you sell scarce, high-value or serialised goods, and wrong when you sell from a live ERP stock feed that is authoritative anyway. The hold has an expiry, so an abandoned checkout gives the stock back on its own. See Stock, locations and availability.

What to check

Place one test order end to end, then open it under Order Management › Orders and confirm:

  • The three status badges read placed / the payment state you expect / unfulfilled.
  • customer_order_number on the Overview tab carries what you typed.
  • The totals match what the buyer was shown: subtotal, shipping, tax, grand total.
  • The shipping and payment snapshots on the Payment tab name the method you chose.
  • Cost centre and position text landed on the position, not in a comment.

If a method you expected was not offered, that is an eligibility answer: check the country list, the order-value bounds and, for shipping, the carrier's status.

Next