Transaction, Checkout
A Checkout Transaction is the run of work Salesforce Commerce performs between the moment a buyer starts checkout and the moment an Order plus its order summary exist.
Definition
A Checkout Transaction is the run of work Salesforce Commerce performs between the moment a buyer starts checkout and the moment an Order plus its order summary exist. It bundles cart validation, shipping and tax calculation, payment authorization, and order creation into one sequence the buyer experiences as a single act. The same Checkout APIs serve B2B and B2C stores; the rules below are written for B2B.
The Commerce Checkout APIs drive it. A call to /checkouts starts the run and creates the CartCheckoutSession record that carries its state. Then /checkouts/{id}/payments sets a payment method, and /checkouts/{id}/orders places the order.
Despite looking like one indivisible operation, it is not one database transaction, and parts of it do not finish before the call that started them returns.
In plain English
“Think of a checkout counter in a shop. The cashier totals your items, works out shipping and tax, checks that you can pay, and prints a receipt. Salesforce does all of that in one run, and the receipt it prints is your order. If something fails halfway, it remembers where it stopped so you can pick up from there.”
Worked example
A buyer at Northwind Fasteners, a fictional industrial distributor, loads a cart of 240 hex bolts and 18 spools of stainless wire worth 4,812.50 USD, then starts checkout. Salesforce opens a CartCheckoutSession against the WebCart, confirms every SKU is still purchasable, calls the shipping service for a 62.00 USD freight quote, and calls the tax service for 431.63 USD. She picks Purchase Order as the payment method and enters PO number NW-2026-4471, so no card gateway authorization runs. She submits, Place Order converts the cart into an Order for 5,306.13 USD, and the matching order summary is created for Order Management. The confirmation page appears, and the session closes with the order id attached.
What actually happens between Checkout and order confirmation
The stages a checkout session moves through
Checkout is a sequence of API calls, never a single one. The storefront opens a session against /checkouts, patches contact and delivery details onto it, sets a payment method, then places the order. Salesforce recommends PUT over POST to start checkout, without giving a reason, so treat it as a default rather than a rule. Each stage recalculates something downstream: delivery groups drive the shipping quote, the quote feeds tax, and tax feeds the total the buyer authorizes against. A stage is not done when the call returns. An API still working answers 202 rather than 200. Hide custom components until that changes, and poll GET /checkouts until you get 200 OK before running your own logic. Modify the cart while a checkout call is in flight and you get a cart is currently in use error. That is a state mismatch, not a validation failure.
CartCheckoutSession holds the state, and only one thing should create it
The session record sits in the Cart data model next to WebCart, CartItem, CartDeliveryGroup, and CartTax. One row per run, holding the cart reference and the stage reached. That is what lets a buyer who closed the tab resume instead of starting over. It is also the first record to open when support asks why an order never appeared. One rule matters more than the rest: let the Checkout API create it. The documented misconfiguration is custom Apex inserting session rows while the storefront also calls POST /checkouts. The API does not expect an existing session, so the two conflict and you get unexpected behaviour instead of a clean error. Whichever verb you send, session creation belongs to the API.
Authorization reserves money, capture takes it
The payment step tokenizes the card and asks the gateway to authorize, and neither of those is taking payment. Salesforce defines the authorization as reserving funds from the available credit of the credit card and says it is not a payment. To the shopper it can display as pending. Capture is the request that later consumes what was reserved, a reversal releases it instead, and a Sale runs both halves in one request. Where Order Management is licensed, it owns the capture and refund flows, so capture timing follows your fulfillment setup rather than a fixed rule. Purchase order buyers skip the gateway and type a PO number. With neither a payment authorization nor a purchase order attached to the cart, the order cannot be placed.
Place Order turns the cart into an Order and an order summary
Place Order is where the cart stops being editable. The call validates user information, processes payment, and generates order summaries for the buyer and the merchant. What it does not do is finish all of that before it answers. Order creation runs asynchronously, and Apex that queries the order the instant the call returns races the process still writing it. Salesforce ties that race to record locking and failed order creation. The summary matters more than its name suggests. Cancellations, returns, and partial fulfillment hang off it, leaving the original Order as an unchanging snapshot of what the buyer agreed to. An ERP subscribes downstream and gets the order after the buyer already saw a confirmation page. That gap produces the support call about an order nobody downstream has heard of.
It looks indivisible to the buyer and is nothing of the sort underneath
Cart edits, the gateway hold, and order creation each commit on their own boundary. The worst case has a name in the docs. Place Order Actions succeeds, asynchronous Order Summary creation then fails, and the transaction is left inconsistent: payment captured, no automatic refund. There is a switch for it, off by default. The CheckoutReverseAuthEnabled org permission reverses payments when checkout fails or is cancelled. Turn it on before you need it; refunds can incur extra charges from the provider. Leave it off and a stranded hold sits against a buyer's credit with nothing on record explaining it. Alerting on sessions parked mid-stage is the cheap half of this. The org permission is the half that unwinds the money.
The buyer-facing surface moved from Flow Builder to Experience Builder
For years the answer to a checkout change request was short: edit the Checkout type Flow. Aura stores ran a managed Flow of screen and system subflows, and you swapped nodes to change behaviour. That era has closed in the documentation. The Aura checkout pages now redirect to one archived PDF, replaced by a B2B Commerce Aura to LWR Migration Guide. On LWR the checkout page is assembled in Experience Builder from a Checkout component with layout, section, and child components. Custom behaviour is a Lightning web component extending the useCheckoutComponent mixin and calling helpers like dispatchUpdateAsync and dispatchPlaceOrderAsync. The menu behind this is short. Managed checkout brings Salesforce merchant services and automatic UI updates, and supports no customization. Custom checkout uses third-party providers and lets you change the UI. For B2B stores, Salesforce Help says custom checkout is the only option for configuring checkout.
How organizations use Transaction, Checkout
Accepts purchase orders only, so buyers type a PO number instead of a card and that number reaches the ERP for invoicing against agreed net terms.
Watches CartCheckoutSession records that sit mid-stage for more than fifteen minutes and has support call the buyer before the cart goes stale.
Adds a hazardous materials acknowledgement as a child checkout component built on the useCheckoutComponent mixin, so Place Order stays blocked until the buyer confirms.
Trust & references
Cross-checked against the following references.
- Salesforce Commerce Checkout APIs (opens in new tab)Salesforce
- Avoid Common Misconfigurations (opens in new tab)Salesforce
- Payment APIs (opens in new tab)Salesforce
- Commerce Payment Component Options (opens in new tab)Salesforce
- UseCheckoutComponent Interface (opens in new tab)Salesforce
- B2B Commerce Aura to LWR Migration Guide (opens in new tab)Salesforce
Straight from the source - Salesforce's reference material on Transaction, Checkout.
Hands-on resources to go deeper on Transaction, Checkout.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
+5 pts / dayQ1. Custom Apex queries the new Order immediately after the Place Order API returns. What is wrong with that?
Q2. Payment is captured, then asynchronous Order Summary creation fails and leaves the transaction inconsistent. What does Salesforce recommend?
Q3. A B2B store built on an LWR template needs an extra confirmation step during checkout. What is the supported way to build it?
Discussion
Loading discussion…