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.