Checkout

The payment, shipping, order-flow and order-state rows the base guarantees, and the checkout pages surface-swift wires to them.

What the baseline guarantees

Layer: base 3.2.1 (whole-table replace) + surface-swift 1.5.1 (the pages).
EcomPayments (5): Creditcard, Faktura, Invoice, Kreditkort, MobilePay.
  PAY2 = Invoice — no gateway, resolves to DefaultCheckoutHandler and implements IRecurring;
  it is the method feature-subscription-orders' checkout probe uses.
EcomShippings (17): Bring/DAO Parcelshop (+ DAO), Business delivery, Click & Collect,
  Firmalevering, GLS Parcelshop / GLS Privat, Hjemmelevering, Home delivery (SHIP9),
  PostNord Parcelshop / Privat, UPS.
EcomMethodCountryRelation ties methods to countries.
EcomOrderFlow (4): Default cart flow, Default order flow, Default Quote flow,
  Default ledger flow. SHOP1.ShopOrderFlowId = 1.
EcomOrderStates (14): New, Draft, Approved, Rejected, Completed, Cancelled, Deleted, Paid,
  Partial-paid, Price given (+ suffixed duplicates).
EcomOrderStateRules ships the transitions.
EcomCountries / EcomCountryText / EcomVatCountryRelations ship the full country set.
Checkout pages (surface-swift replace/_content/Swift 2/Shopping cart/):
  Cart, Cart/Checkout anonymous, Cart/Checkout user, Cart/Quote checkout user,
  Cart/Empty cart, Add credit card.
Service pages: Service Pages/CartService, Service Pages/CartSummary.
Emails: System emails/Checkout Emails/Order Confirmation Email.
Two of the payment names and four of the shipping names are Danish (Faktura, Kreditkort,
Firmalevering, Hjemmelevering). These are stock DW rows the base carries verbatim, not demo
content. They are visible in the backend method lists and should be deactivated or renamed for
an English-language customer.
NOT present by design: zero orders, zero carts, zero track-and-trace rows, zero validation
rules.

Which skill covers it

dw-commerce-orders (dynamo: true) — references/checkout-configuration.md,
references/order-states-and-quotes.md, references/order-lifecycle.md,
references/cart-commands.md, references/order-notifications.md,
references/customer-center-surfaces.md.

Which MCP tools brand it

get_payments / get_shippings (read what base shipped)
-> create_payment / update_payment / toggle_payment_active / sort_payments
-> create_shipping / update_shipping / toggle_shipping_active / sort_shippings
-> create_shipping_method / save_shipping_methods (the per-country rates)
-> get_order_states / create_order_state, get_order_flows
-> save_payment_translation / save_shipping_translation (per language)
Demo orders: create_orders -> add_products -> set_order_payment_method -> complete_order.
Ceilings to state rather than route around:
- create_order_state reaches the state's name only. It has no parameter for AllowEdit,
  AllowOrder or the ten mail columns. A quote state that must permit ordering or editing is
  an admin-screen edit.
- A scripted cart command must send a BROWSER User-Agent and FOLLOW REDIRECTS. curl and wget
  defaults fail both gates, and the failure looks like a broken cart rather than a blocked
  client.

Verify

MCP: get_payments returns 5 and get_shippings returns 17 on a clean baseline; after branding,
every ACTIVE method is one you deliberately kept.
Storefront: GET <site-root>/cart/ returns 200 (a declared criticalPath in
editions/swift-demo.json). Then drive a cart to <site-root>/cart/checkout-user and assert the
payment and shipping selectors render at least one option each — an all-inactive method list
still returns 200.