Skip to main content
Experimental. Session create and update exist for sandbox evaluation. Completion and live Payment stay contained. Live payment fails closed with PAYMENT_ACTIVATION_REQUIRED. Shopper HTTP cannot complete a live purchase. See maturity levels.
The Checkout Module manages the current session-based Checkout flow. Each session stores contact details, addresses, discounts, and displayed totals. See How commerce records relate for the product boundary this Module is moving toward. Source: modules/checkout · npm: @86d-store/checkout

Planned Checkout Request

When a required decision is unavailable, the planned safe path creates a non-binding Checkout Request instead of an Order. It stores no payment credential, promises no Inventory, and requires a fresh server calculation before purchase. This record is not part of the current module API.

Installation

Configuration

number
default:"1800000"
Session time-to-live in milliseconds. Sessions that exceed this age without completing transition to expired. Defaults to 30 minutes (1,800,000 ms). Pass a per-session ttl override to controller.create() when you need a different window for a specific session.
string
default:"\"USD\""
Default currency code applied to new Checkout sessions. Individual sessions can override this by passing currency to POST /checkout/sessions.

Session status flow

Call controller.expireStale() periodically (for example from a cron job) to transition past-TTL pending sessions to expired.

Store endpoints

Checkout is shopper-facing only. This Module has no admin endpoints.

Components

CheckoutForm

CheckoutForm is the multi-step checkout orchestrator. It renders the active step (information, shipping, payment, or review) alongside the CheckoutSummary sidebar. A step indicator shows Shoppers how far along they are. If no session ID is set in checkoutState, the component falls back to a “Return to cart” message.
Place this on your Checkout page. Before the component renders, set checkoutState.sessionId to a valid server-created session ID:

CheckoutInformation

Step 1 collects the Shopper’s email address and advances to the shipping step on submit.
CheckoutForm renders this automatically. Use it standalone only if you are building a fully custom checkout layout.

CheckoutShipping

Step 2 collects the shipping address: first and last name, address lines, city, state, postal code, country, and phone number. On submit it advances to the payment step.

CheckoutPayment

Step 3 confirms the session and creates a payment intent. Its development-only completion path cannot represent live payment. With a configured sandbox provider, it renders that provider’s payment UI.

CheckoutReview

Step 4 shows the final order summary: contact information, shipping address, line items, and totals. The review UI exists for sandbox evaluation. Place order does not complete a live purchase. Completion and live Payment stay contained.

CheckoutSummary

CheckoutSummary is the order summary sidebar: line items, subtotal, shipping, tax, discount, and total. It includes promo-code application and removal. A legacy gift card already stored on the Checkout can be displayed and removed, but gift-card application is unavailable. CheckoutForm renders this sidebar automatically; you can also use it standalone in a custom layout.

Types

Completing a session

In sandbox evaluation, an order-creation flow can link a new Order by calling complete():
This stores the orderId on the session. It is not a live Shopper purchase and does not authorize live Payment.

Discount integration

When the Discounts Module is also enabled, promo codes work at Checkout without extra configuration. A Shopper applies a code, and the Checkout Module validates and applies it through the Discounts Module. See the Discounts module reference for the promo code API and the DiscountController interface.