Product, Checkout
Checkout is the staged process in Salesforce B2B and D2C Commerce that turns a buyer's cart into a placed order.
Definition
Checkout is the staged process in Salesforce B2B and D2C Commerce that turns a buyer's cart into a placed order. It runs a sequence of steps that collect a shipping address, calculate shipping and tax, take payment, and create the order record. The whole thing lives inside a single Checkout component placed on a store page in Experience Builder.
The way checkout is built depends on the store template. Stores on the older Aura template run checkout as a Flow Builder flow made of smaller subflows. Stores on the newer LWR (Lightning Web Runtime) template use the packaged Salesforce Commerce Checkout, which is a set of Lightning web components you arrange and customize. Both produce the same outcome: an order ready for fulfillment.
How checkout turns a cart into an order
Checkout is a process, not a single product
People sometimes read "checkout product" as a special kind of product record. It is not. A product in Commerce is one catalog item with its pricing, inventory, images, and description. Checkout is the separate flow a shopper goes through to buy whatever is in the cart. The two meet at the cart: products get added, and checkout converts that cart into an order. So there is no checkout-specific product object. What matters for checkout is that each product in the cart is sellable. It needs an active entitlement for that buyer, a price in the store's price book, and enough inventory if you track stock. Checkout reads those values, it does not store them on the product. If a product has no price in the assigned price book, it cannot be purchased even when it shows in the catalog. Treat checkout as the engine and products as the fuel. You configure products once in your catalog and pricing setup. Checkout then validates and totals them at purchase time. Keeping that line clear saves a lot of confusion when you debug why an item will not check out.
The states a shopper moves through
Checkout runs a defined sequence of states, and each state does one job. A typical order of operations is: confirm the cart, check inventory, capture or confirm the shipping address, calculate shipping cost, calculate tax, authorize payment, then create and activate the order. Some states show a screen to the buyer. Others run quietly in the background and call out to providers. Each state usually maps to an integration. Inventory checks hit an inventory service. Shipping and tax can call external rate or tax engines through registered integrations. Payment authorization talks to the Salesforce Payments API or another gateway. Order creation writes the Order and OrderItem records that fulfillment teams work from later. The sequence matters because later states depend on earlier ones. You cannot total tax before you know the shipping destination. You should not create the order before payment is authorized. If any state fails, for example a declined card or an out-of-stock item, checkout stops and surfaces the error rather than producing a half-finished order.
Aura stores: checkout as a flow of subflows
If your store uses the Aura template, checkout is an actual flow you open in Flow Builder. Salesforce ships a default checkout flow, and you customize it by adding, removing, or reordering the subflows inside it. This is declarative work. You are wiring steps together, not writing the core checkout logic by hand. A subflow is a self-contained piece of the larger checkout. Some subflows are screen flows, which means they display something to the buyer or collect input, like a shipping address form. Others are system flows that complete background actions, such as checking inventory or activating the order. The Checkout component in Experience Builder points at the flow, and the flow runs its subflows in order. This model is flexible. You can drop in a custom subflow to call your own logic, mark a subflow asynchronous so a slow integration does not block the buyer, or rearrange steps to match your business. The tradeoff is that flow-based checkout is the older approach, and Salesforce now steers new builds toward LWR.
LWR stores: the Salesforce Commerce Checkout
Stores built on the LWR template use the packaged Salesforce Commerce Checkout instead of a flow. It is a parent Checkout component with child components for each section, such as shipping address, shipping method, and payment. You configure and restyle these in Experience Builder, and developers can extend them with custom Lightning web components. LWR checkout supports two layouts. A one-page layout keeps every section expanded so the buyer can complete them in any order, with sections autosaving as valid data is entered. An accordion layout forces a sequence: shipping address, then shipping method, then payment, with a Proceed button moving to the next section. You pick the layout that fits your audience. Under the hood, child components share a small contract. They validate their own forms, then push data up with calls like dispatchUpdateAsync to update the shared store and dispatchCommit to save. Before the order is placed, the data provider runs reportValidity on every child to confirm all sections are valid. If one fails, the place-order action halts and the error is shown.
Payment and order creation
Payment is the state buyers care about most, and it is where checkout connects to money movement. In Salesforce-native setups, the payment component integrates with the Salesforce Payments API to authorize the buyer's card or chosen method. You can also wire a different gateway through a payment integration. Authorization happens before the order is created, so a failed payment never produces a real order. Once payment clears, checkout creates the order. It writes an Order record plus an OrderItem for each line in the cart, carrying the agreed prices, quantities, and addresses. That order is what downstream Order Management, fulfillment, and finance processes act on. The cart's job ends here; the order becomes the system of record for the purchase. Because order creation is the last step, you generally do not want heavy custom logic blocking it. Calculations and validations belong in the earlier states. Keep the final state focused on committing a clean order, and handle post-purchase work like notifications or fulfillment routing through separate automation triggered by the new order.
Common ways checkout breaks
Most checkout problems trace back to data the flow reads rather than the flow itself. A product that will not check out usually lacks a price in the assigned price book, has no inventory when stock is tracked, or is not entitled to the buyer's account. Fix the catalog or pricing record and the same checkout starts working. Integration failures are the next big bucket. If a tax or shipping engine times out or returns an error, the matching state fails and the buyer is stuck. Marking slow integrations asynchronous, where the design allows it, keeps the experience moving. Always test with the same buyer profile, price book, and shipping destination a real customer would use, because checkout behaves differently across those inputs. Finally, watch your layout and validation choices on LWR. If a custom child component does not report validity correctly, place-order can fail silently or block. Test the full path end to end in a real storefront session, not just the Experience Builder preview, before you let live buyers near it.
Set up checkout for a Commerce store
You do not create a checkout product. You configure the Checkout component on your store's checkout page in Experience Builder, then make sure the products buyers add are sellable. Here is the high-level path for a B2B or D2C store.
- Open the store in Experience Builder
From Commerce setup, open your store and launch Experience Builder. Go to the Checkout page, where the Checkout component already sits on stores created from a standard template.
- Choose the checkout flow or layout
On an Aura store, select the checkout flow the component should run in its properties. On an LWR store, pick the one-page or accordion layout for the Salesforce Commerce Checkout and arrange its sections.
- Configure the steps
Add, remove, or reorder subflows (Aura) or child sections (LWR) to match your process. Set slow integrations to asynchronous where supported so they do not block the buyer.
- Connect payment
Set up Salesforce Payments or your chosen gateway so the payment step can authorize transactions. Confirm the payment section appears and accepts a test method.
- Make products sellable, then test end to end
Give each product a price in the store's price book, set inventory if you track it, and confirm buyer entitlements. Run a full test purchase in the live storefront, not just the preview.
Aura stores run a Flow Builder checkout flow; LWR stores use the packaged Salesforce Commerce Checkout components. The template you chose at store creation decides which you configure.
On LWR, one-page keeps all sections open for completion in any order; accordion forces shipping then method then payment in sequence.
On Aura, a subflow can run synchronously (the buyer waits) or asynchronously (it runs in the background) to keep slow integrations from stalling checkout.
Use the native Salesforce Payments API integration or register a third-party gateway to authorize and capture funds during the payment step.
- A product without a price in the assigned price book cannot be purchased even if it shows in the catalog.
- Order creation runs only after payment authorization succeeds, so a declined card never produces a real order.
- The Experience Builder preview does not exercise every integration; always test a real storefront session before go-live.
- On LWR, a custom child component that fails to report validity can block or silently break the place-order action.
Prefer this walkthrough as its own page? How to Product, Checkout in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Product, Checkout.
Hands-on resources to go deeper on Product, Checkout.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which Salesforce context does a Product (Checkout) record belong?
Q2. Beyond basic product data, what does configuring a Product for storefront checkout typically require?
Q3. When a buyer browses the catalog, how does the storefront use Product (Checkout) records?
Discussion
Loading discussion…