Checkout
A checkout is the guided, multi-step flow in Salesforce Commerce that turns an active shopping cart into a placed order.
Definition
A checkout is the guided, multi-step flow in Salesforce Commerce that turns an active shopping cart into a placed order. It collects the shipping address, the billing address and payment method, then validates inventory, calculates tax, authorizes payment, and finally converts the cart into an Order record. In B2B Commerce and D2C Commerce on Aura stores, the checkout is built as a Lightning Flow made up of smaller subflows, so each step can be moved, removed, or replaced.
A checkout is the highest-stakes part of any storefront because every shopper passes through it to become a customer. The flow coordinates a sequence of system actions and screens against the cartCheckoutSession record, which tracks where the buyer is in the process. Salesforce ships a default checkout flow you can use as-is, then customize in Flow Builder when you need different steps, a custom payment integration, or extra tasks like purchase-order entry for B2B buyers.
How a Salesforce checkout flow is built and runs
Subflows: the building blocks of checkout
A B2B or D2C checkout flow is not one monolithic flow. It is a parent flow that calls a series of subflows, and that structure is what makes the checkout easy to change. You can reorder a step, drop one you do not need, or swap in your own version without touching the rest. Subflows come in two kinds. Screen flows ask the buyer for input or show them information, such as the shipping address screen or the payment screen. System flows run actions in the background with no UI, such as checking inventory or converting the cart to an order. The default flow strings these together in a sensible order, but Salesforce expects you to edit it. Common customizations include adding a promotion subflow so buyers can enter a coupon code, inserting a purchase-order field for B2B accounts, or replacing the stock payment screen with one wired to a different processor. Because each piece is a discrete subflow in Flow Builder, a change to one step rarely breaks the others, which keeps an otherwise complex flow maintainable.
cartCheckoutSession: the state record
Every checkout is driven by a cartCheckoutSession record that tracks the buyer's progress through the flow. Intermediate stages depend on this object. When a stage finishes, the session advances to the next stage, and the UI reads the session to know what to render. Several fields carry the live state. BackgroundOperation and IsProcessing tell the storefront whether an asynchronous task, like an inventory check or the cart-to-order conversion, is still running, so the page can show a spinner instead of letting the buyer click ahead. OrderId is populated once the order is created, which is how the confirmation screen knows which order to display. Treating the session as the single source of truth keeps the multi-step flow consistent even when integrations run at different speeds. If you build a custom subflow, you read and update the session rather than inventing your own state. This design also makes asynchronous steps safe: a long-running call can flip IsProcessing on, do its work, then flip it off and move the stage forward, all without losing the buyer's place.
Shipping, billing, and payment steps
The buyer-facing core of checkout is three screen subflows. The Shipping Address subflow asks the buyer where the order goes, pulling saved addresses from the buyer account so returning customers do not retype them. Capturing the shipping address matters beyond delivery, because tax is calculated from it and shipping rates depend on it. The Payments and Billing Address subflow collects the billing address and the payment method, again offering addresses already on the account. This step integrates with the Salesforce Payments API to authorize the payment, which holds the funds without capturing them until the order ships. Tokenization keeps raw card numbers out of Salesforce; the flow stores a token and an authorization reference, not the card itself. Between these screens, the cart totals update so the buyer sees tax and shipping reflected before they commit. For B2B stores, this part of the flow often gains a purchase-order entry field, because business buyers frequently pay against a PO rather than a card. Getting these screens right on mobile is where most conversion is won or lost.
Inventory check and cart-to-order conversion
Two system subflows do the heavy lifting near the end. The Inventory subflow triggers a check-inventory request for each cart line item, confirming the items are still available before the buyer pays. It runs as a background operation and updates BackgroundOperation and IsProcessing on the session while it works. Catching an out-of-stock item here, rather than after payment, avoids the worst kind of order: one you charged for but cannot fulfill. The Cart to Order subflow then converts the cart into an Order record in Draft state, pending activation. As it runs, it updates the session's BackgroundOperation and IsProcessing flags and, on success, writes the new order's ID into CartCheckoutSession.OrderId. The conversion maps each cart line to an order line, carrying over products, quantities, and prices. Once the order exists, it replaces the cart as the operational record. Everything downstream, including fulfillment, billing, returns, and customer service, happens on the Order, not the cart. Keeping this conversion reliable is why it runs as a discrete, monitored step rather than a side effect of clicking a button.
Synchronous versus asynchronous subflows
Each subflow can run synchronously or asynchronously, and choosing correctly is the main performance lever in checkout. A synchronous subflow blocks the buyer until it returns, which is right when you need an immediate answer, such as authorizing a payment or confirming the cart still calculates. An asynchronous subflow kicks off work and lets the flow continue, which suits slower integrations that call external services. The tradeoff is direct. Synchronous steps give instant feedback but freeze the screen while they wait, so a slow tax or fraud service stalls the whole checkout. Asynchronous steps keep the experience moving but need the session flags, BackgroundOperation and IsProcessing, to tell the buyer something is still happening. Salesforce lets you change a subflow from synchronous to asynchronous in Flow Builder, so you can tune behavior per integration. There is also a safety property in how integrations execute. If a runtime exception occurs during an Apex integration, the execution rolls back and the platform fires an error event, which preserves data integrity and marks the task as failed instead of leaving a half-finished order.
Idempotency and avoiding double orders
Checkout has to survive retries without charging a buyer twice or creating duplicate orders, which is why idempotent execution is built into the integration model. A buyer might double-click Place Order, a network blip might resend a request, or an asynchronous task might be retried after a timeout. Without care, any of these could fire the cart-to-order conversion or a payment capture more than once. The checkout architecture guards against this by keying work to the cartCheckoutSession and the stage it is in, so repeating a request for a stage already completed does not redo the side effect. The OrderId on the session is part of this: once it is set, the system knows the order already exists and does not create another. When you write custom subflows or integration handlers, you are expected to keep them idempotent in the same way, checking session state before acting. This is also why platform error events matter. A failed integration marks itself failed and can be retried safely, rather than leaving the buyer stuck or the data inconsistent. Designing for repeatable, side-effect-safe steps is what keeps a high-traffic checkout trustworthy.
B2B, D2C, and B2C checkout differences
The word checkout covers a few different implementations across Salesforce Commerce, and the right one depends on the store. On Aura-template B2B and D2C stores, checkout is the subflow-based Lightning Flow described here, customized in Flow Builder. B2B checkouts lean toward business buying patterns: purchase orders, approval-aware ordering, and accounts with many saved addresses and contacts. D2C and B2C checkouts lean toward consumer speed, where fewer taps and options like express digital wallets lift conversion. Salesforce B2C Commerce also offers the Storefront Reference Architecture, a separate JavaScript and MVC framework whose checkout is built in code rather than Flow, and which ships features aimed at reducing checkout friction. Whichever model you use, the job is the same: move the shopper from cart to confirmed order while running payment, tax, shipping, and inventory in the right order. The implementation details differ, but the stakes do not. Friction in any of these checkouts costs revenue directly, so the same discipline around speed, mobile testing, and reliable order creation applies regardless of the storefront technology underneath.
Configure a checkout flow on a B2B or D2C store
On an Aura B2B or D2C store, you start from the default checkout flow Salesforce provides, then customize it in Flow Builder. Here is the high-level path to put a working, tailored checkout on a store.
- Add the Checkout component to the page
In Experience Builder, open the Checkout page of your store and confirm the Checkout component is present. It is what hosts the running checkout flow for buyers.
- Choose a checkout flow
Point the Checkout component at a flow. Use the default checkout flow to launch quickly, or select your own cloned and customized flow once you need different steps or integrations.
- Customize subflows in Flow Builder
Clone the default flow, then add, remove, or reorder subflows. Common edits include a promotion subflow for coupon codes or a purchase-order field for B2B buyers.
- Tune synchronous versus asynchronous steps
For slower integrations such as tax or fraud screening, switch the subflow to asynchronous so the buyer is not blocked, and rely on the session flags to show progress.
- Test the full flow before going live
Run a buyer through every step, including shipping, payment authorization, inventory, and order creation, and confirm an Order record is created with the right line items.
The Salesforce-provided flow that works out of the box; the fastest way to get a functional checkout before customizing.
Screen subflow that captures where the order ships, pulling saved addresses from the buyer account and feeding tax and shipping calculations.
Screen subflow that collects billing details and authorizes payment through the Salesforce Payments API using tokenized card data.
System subflow that checks availability for each cart line before payment and reports progress through the session flags.
System subflow that converts the cart into a Draft Order and writes the new order ID back to CartCheckoutSession.OrderId.
- Slow third-party calls (tax, fraud, payment) freeze a synchronous checkout and quietly drop conversion; make those steps asynchronous and monitor latency.
- Always test on real mobile devices, not just browser dev tools; a checkout that breaks on small screens is among the most expensive defects in commerce.
- Keep custom subflows idempotent: check cartCheckoutSession state before acting so a retry or double-click never creates a duplicate order or double charge.
- Do not let a downstream failure roll back a created order; once CartCheckoutSession.OrderId is set, build safe retries rather than undoing the order.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Checkout.
Hands-on resources to go deeper on 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. What does Checkout cover in Commerce Cloud?
Q2. Why is Checkout one of the most-tuned parts of a commerce experience?
Q3. What is a checkout best practice?
Discussion
Loading discussion…