Transaction, Checkout
A Checkout Transaction in Salesforce B2B Commerce is the financial event that runs when a buyer submits a cart for purchase.
Definition
A Checkout Transaction in Salesforce B2B Commerce is the financial event that runs when a buyer submits a cart for purchase. It wraps payment authorization, order creation, order summary generation, and the confirmation handoff back to the storefront, and treats the full sequence as one logical unit even though several subsystems take part.
The term covers both the runtime sequence that a Checkout Flow executes when a buyer clicks Place Order and the underlying records that get written, including CartCheckoutSession, Order, OrderItemSummary, and any Payment or PaymentAuthorization rows the configured gateway returns. A Checkout Transaction is considered complete only when the Order record has been created and the buyer has received an order confirmation. Until then, the buyer can recover the cart and retry without losing progress.
How a Checkout Transaction actually executes on the platform
What the Checkout Flow does on submit
When a buyer hits Place Order on a B2B Commerce storefront, the Checkout Flow runs a fixed sequence of steps. It validates the cart, recalculates shipping and tax, runs any final pricing rules, calls the payment gateway for authorization, writes the Order record, transitions cart line items into order line items, fires the order confirmation event, and clears the cart. Each step is a node in the Checkout type Flow that ships with B2B Commerce, and each node can be replaced or extended with an internal subflow, an Apex extension, or an external service call. The runtime keeps a CartCheckoutSession record so that if a step fails mid-flow, the buyer can resume from the last step rather than starting over.
CartCheckoutSession and where the state lives
Behind every Checkout Transaction sits a CartCheckoutSession record. This is the recovery anchor for the buyer and the audit trail for support. The session holds the cart id, the buyer id, the current checkout state, the last successful step, and any errors thrown by the flow nodes. If the buyer closes the browser before paying, the session stays put, and the storefront will resume from the last step on the next visit. After successful order creation, the session is closed and the order id is linked back to it for traceability. Reporting on stuck checkouts almost always starts here, since the session is the only place that records why the flow stalled.
Payment authorization and the gateway contract
B2B Commerce calls the configured payment gateway during the payment step. The gateway returns an authorization token, an amount, and a result code. If the result is approved, the flow continues. If the gateway declines the transaction or returns an error, the flow stops and the session captures the failure for the buyer to retry. The record that holds the authorization is a Payment or PaymentAuthorization row, depending on the gateway adapter you use. Capture (turning the hold into an actual charge) usually happens later, when the order is fulfilled, not at the moment the buyer clicks Place Order. This split is why B2B checkout looks atomic to the buyer even though no money has moved yet.
Order creation and the handoff to fulfillment
Order creation is the step that turns a successful authorization into a real Order record. The Checkout Flow copies the cart header into an Order record and the cart items into OrderItem rows, with prices, taxes, and adjustments locked in. Order Summary and OrderItemSummary records are created at the same time to support post-purchase changes, returns, and asynchronous fulfillment events. From that point on, the order is the source of truth, and any downstream system (ERP, warehouse, accounting) consumes the Order record rather than the cart. The Checkout Transaction is considered complete when the Order record exists and the buyer has received the confirmation event.
B2B-specific payment methods and approvals
B2B checkout is not only credit cards. Most B2B Commerce orgs let buyers pay by purchase order, net terms, prepaid balance, or a contract-tied billing account, and the Checkout Flow branches on the method the buyer selects. Purchase order payments validate the PO number against an account-level credit limit instead of calling a card gateway. Net-terms payments may require an approval step from the buyer company accounts payable user before the order is released. Contract-tied billing skips payment authorization entirely and books against an existing agreement. Each path is a different fork in the Checkout Flow, and each writes a slightly different set of records on the order. Treat the Checkout Transaction as a family of variants, not one fixed sequence.
Atomicity, rollback, and what happens when a step fails
A Checkout Transaction looks atomic to the buyer but is not a single database transaction underneath. The cart, the payment authorization, and the order each live on their own commit boundary, and the Checkout Flow uses CartCheckoutSession to track which boundaries have been crossed. If the payment step succeeds but order creation fails, the platform does not unwind the authorization automatically. The session records the partial state and either the next retry or an admin tool has to release the hold. This is where most production incidents in B2B Commerce checkout originate. Build a monitoring dashboard against CartCheckoutSession state and alert when sessions sit in an intermediate state past the SLA you commit to.
Post-order events and downstream integration
After the Order record is created, B2B Commerce fires a set of platform events and Flow triggers that downstream systems hook into. Order Confirmation Email, Order Summary creation, Fulfillment Order generation, and any external integration (ERP, warehouse, accounting) all listen on this layer. Some of these run in the same database transaction as order creation, some run minutes later, and the Checkout Transaction is considered complete the moment the buyer sees the confirmation page, regardless of whether the downstream systems have acknowledged the order yet. This eventual-consistency window is a common source of buyer confusion when the storefront shows the order but the ERP has not yet received it.
Configuring a Checkout Transaction in B2B Commerce
Configuring a Checkout Transaction in B2B Commerce is mostly configuring the Checkout Flow that drives it. The flow is a Salesforce Flow of type Checkout that ships with the storefront template, and each step in the flow is a subflow you can replace with your own. You will spend most of your time on the payment step, the validation step, and the post-order step, since those three nodes are where org-specific behavior almost always lives.
- Clone the standard Checkout Flow as your starting point
Open Setup, type Flows, and find the standard Checkout Flow that came with your B2B Commerce template. Save As Flow to create a writable copy. Do not edit the standard flow directly. You will lose your changes the next time a Commerce release updates it. Name the clone after your storefront so different storefronts can run different checkout sequences without interference. Activate the cloned flow only after you have validated it in a sandbox, since switching the active Checkout Flow on a live storefront mid-day will fail any in-progress sessions.
- Replace the payment step with your gateway subflow
The standard Checkout Flow calls a placeholder payment subflow that does not call a real gateway. Replace this node with the subflow shipped by your payment adapter (Salesforce Payments, Stripe, Adyen, Cybersource, etc.) or your own custom subflow if you have a private gateway. The subflow has to return an authorization id, an amount, and a result code. The Checkout Flow reads these to decide whether to advance. If you support multiple payment methods, branch on Cart.PaymentMethod before this node so each method calls its own subflow.
- Add validation nodes for B2B-specific business rules
B2B checkout almost always has business rules that B2C does not. Examples are credit-limit checks against the buyer account, PO-number uniqueness checks, minimum order quantity enforcement, hazardous-material approvals, and country export controls. Add each rule as a Decision element or an Apex action before the payment node so a failure does not result in a paid order that has to be canceled. Each validation node should write a clear error message to CartCheckoutSession so the storefront can surface a useful message to the buyer.
- Wire the post-order subflow to your fulfillment system
The post-order step in the Checkout Flow is where you call your downstream systems. Hook the order creation event to a platform event subscriber that pushes the order to your ERP, your warehouse management system, or your accounting backend. Keep this step asynchronous. Do not block the buyer confirmation page on the ERP response. Add a retry policy and a dead-letter queue so transient ERP outages do not leave orders in limbo. Subscribe an admin alert to the dead-letter queue so support can intervene before buyers start calling.
- Do not edit the standard Checkout Flow in place. Save As, edit the copy, and activate the copy. A Commerce release will overwrite the standard flow without warning.
- Authorization is not capture. The gateway holds the funds when the buyer clicks Place Order, but the money does not actually move until your fulfillment step captures the authorization.
- CartCheckoutSession does not clean itself up on partial failure. If the payment step succeeds and order creation fails, the authorization stays open. Build a sweeper job that voids stale holds on a schedule.
- The order confirmation email is fired by a Flow trigger on Order creation, not by the Checkout Flow itself. If buyers report missing confirmation emails, check that Flow trigger first.
- Switching the active Checkout Flow on a live storefront fails any sessions currently mid-checkout. Always switch during a maintenance window and notify affected buyers in advance.
Trust & references
Straight from the source - Salesforce's reference material on Transaction, Checkout.
- B2B Commerce OverviewSalesforce Help
- Configure the Checkout FlowSalesforce Help
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 is a Checkout Transaction?
Q2. How does B2B differ from B2C checkout?
Q3. What does a transaction encompass?
Discussion
Loading discussion…