Streamlined Place Order
The streamlined place order feature improves checkout performance and scale, and prevents orphaned payments. This enhanced design consolidates order placement API calls, processes payments asynchronously, and provides greater flexibility for modular customization. Streamlined place order is enabled by default in B2B and D2C Lightning Web Runtime (LWR) stores created in Summer ’25 and later releases.
Streamlined place order triggers when a customer clicks the Place Order button from checkout. Then, the system prepares the order and payment before capturing a payment and creating the order asynchronously. If an error occurs during asynchronous order or payment processing, the Commerce admin receives a process exception to resolve.
- Prepare Order—First, calls to the Prepare Order API reserve the order’s required inventory and, if applicable, redeem any coupons. To confirm that the cart can be converted into an order, this step includes cart validations. For example, validations check that a cart delivery group exists and that the checkout session hasn’t expired.
Streamlined place order reduces the default checkout time-to-live (TTL) for D2C stores from 48 to 4 hours. Reducing the time limit for active checkouts helps prevent orphaned payments, inventory, and coupons. The default checkout TTL for B2B stores is 48 hours. If a checkout expires, the checkout status is set to Canceled and the cart status is reverted to Active.
- Prepare Payment—Next, calls to the Payment APIs get the order ready for payment collection. Based on the input information, the system creates the necessary payment group object and calls the Commerce Payment Gateway. If streamlined place order is successful up to this point, the customer sees a pending transaction on their account. However, the payment isn’t captured yet.
- Asynchronous Processing—After a payment is prepared, asynchronous payment processing begins. Calls to the Commerce Payment Gateway from the previous step create and confirm the payment intent object. Asynchronous processing also performs the payment capture, transferring funds from the customer to your store, and creates the order and order summary.
If an issue arises during this step, the store generates a process exception. For more information, see Resolving Asynchronous Order Failures in B2B and D2C Stores.
The pending closed checkout TTL setting determines how long a store waits for payment confirmation from the payment gateway. If the payment confirmation doesn’t arrive in time, a process exception occurs. If payment confirmation arrives after the pending closed checkout TTL has expired, the order and order summary are still created, unless the Commerce admin changed the WebCart status to Closed while resolving the process exception. You can set the pending closed checkout TTL in minutes by using the Checkout.pendingClosedCheckoutTTL configuration.
-
Submit Order—The system once again validates the inventory and coupons, confirms that the payment amount covers the full cart amount, and attaches the payment group to the cart. If the cart isn’t paid in full, the system returns a checkout service exception. If the checks pass, the payment group is attached to the cart.
The system updates the cart status to Pending Closed and the customer is sent to the order confirmation page. Because payment processing is asynchronous, the payment method isn’t displayed on the confirmation page.
Streamlined place order introduces new and updated APIs for order orchestration. New APIs:
- To prepare an order, make a POST request to the Commerce Webstore Checkout Order Actions API with the action set to prepare.
- To submit an order, make a POST request to the Commerce Webstore Checkout Order Actions API with the action set to submit.
- To prepare a payment, make a POST request to the Prepare Payment API. Updated APIs:
- If you use a custom payment integration and make a PostAuth request to Commerce Webstore Checkout Payments while streamlined place order is enabled, no payment gateway calls or credit card storage (CCS) entities are created. The call returns a successful 200 response code without performing any additional actions.
This table describes the state of relevant objects at the end of each stage in the streamlined place order flow.
| Object | Prepare Order | Prepare Payment | Process Payment (Asynchronous) | Submit Order |
|---|---|---|---|---|
| WebCart | Checkout | Checkout | Closed | PendingClosed |
| InventoryReservation | Reserved if inventory is available. Not reserved if unavailable. | Reserved | Reserved | Reserved |
| Coupon (if applicable) | Redeemed | Redeemed | Redeemed | Redeemed |
| Order | Not created | Not created | Active | Not created |
| OrderSummary | Not Created | Not created | Created | Not created |
If you develop customizations on top of the simplified order processing flow, keep these recommendations in mind.
To reduce the likelihood of reversed payments, make sure that your store follows the intended sequence of API calls: Prepare Order, Prepare Payment, and Submit Order. This order also applies to headless implementations.
If your store uses Salesforce Payments, the native payment service, note that customizations must be implemented differently when using streamlined place order. For example, in stores created prior to Summer ’25, the legacy order processing flow supported direct calls to the create payment intent API. Instead, for streamlined place order, use the Prepare Payment API to create payment intents.