Technical Audit

Before you enable UCP, audit your existing checkout. UCP is not a second checkout to build: a checkout session is a headless view on a standard Commerce Cloud Basket, and completing it creates an Order. Storefront UI, SFRA/SiteGenesis controllers, and other SCAPI resources you use today do not run in this flow.

Use this page to decide what you must move or bridge. How to write the hooks is in Implementation Considerations. Transaction boundaries are in Transaction Management.

What runs — and what does not

These standard hooks do run on UCP checkout sessions, because they operate on the Basket and Order:

dw.order.calculate
dw.order.calculateTax
dw.order.calculateShipping
dw.ocapi.shop.basket.validateBasket
dw.order.createOrderNo

If your pricing, tax, shipping, and validation already live in those hooks, that logic is reused.

These do not run:

SFRA or SiteGenesis controllers
Shopper Baskets, Shopper Orders, and other SCAPI before / after / modifyResponse hooks registered for those resources
OCAPI resource hooks other than validateBasket (for example basket beforePOST / afterPOST on Shopper Baskets)

UCP calls the Checkout Session APIs (POST/GET/PUT /checkout-sessions, complete, cancel), not the Shopper Baskets or Shopper Orders APIs. Logic you attached to those endpoints must be copied or bridged onto the UCP checkout-session hooks. See the extension hooks reference.

Enable Salesforce Commerce API Hook Execution

UCP checkout hooks only run when this feature toggle is on in Business Manager. If it is off, none of the UCP-specific hooks execute — including third-party payment hooks. Enable it before you rely on custom code in this flow.

Note

Path chooser

Every merchant should complete the hook inventory below. The path only changes how much you expect to move.

Your storefront checkout today	What to expect
SCAPI Shopper Baskets / Shopper Orders	Native Basket/Order hooks still run. Anything in resource-specific SCAPI hooks for those APIs must be remapped to UCP checkout-session hooks.
SFRA or SiteGenesis	Controllers are bypassed. Move tax, shipping, address verification, loyalty, custom fields, and similar logic out of controllers into the standard Basket/Order hooks or UCP hooks.
Custom OCAPI or other non-SCAPI order APIs	Write a bridge: call your existing Script API logic from the UCP checkout-session hooks. Confirm that logic does not require storefront-only or UI-only input.

Hook inventory

Walk your current checkout and ask, for each behavior:

Does it already live in calculate, calculateTax, calculateShipping, validateBasket, or createOrderNo? If yes, verify it with a UCP checkout session — do not assume a SCAPI basket test covers it.
Does it live on Shopper Baskets, Shopper Orders, or another SCAPI/OCAPI resource? If yes, copy or bridge it to the matching UCP hook (beforePOST / afterPOST / modifyPOSTResponse, and the PUT/GET/complete/cancel equivalents).
Does it live in an SFRA/SiteGenesis controller? If yes, move it into a server-side hook. The platform never calls that controller.
Does the hook require extra input the UCP payload cannot provide (form fields, browser cookies, client-side payment setup)? If yes, redesign it for a headless, server-side session or handle it with Continue URL handoff. See Continue URL.

For hook names, arguments, diagrams, and samples, see Implementation Considerations.

Payment path

A UCP checkout is paid with a single payment instrument. Choose a path in Business Manager (Merchant Tools > AI & Social Integrations > UCP):

Path	Audit questions
Salesforce Payments (default)	Is the Salesforce Payments SKU provisioned? Is Google Pay configured for your gateway? If the same Adyen merchant account also serves your storefront cartridge, you must filter webhooks so that cartridge ignores UCP/SFP orders. See Adyen Webhook Filtering.
Third Party Provider (DIY)	You must advertise handlers on the business profile and authorize in `sfcc.app.ucp.payment.authorize`. Any PSP flow that assumes a shopper browser (for example a client-created payment intent) must be rewritten to complete server-side. See Third-Party Payment Providers.

Google Pay is the payment method the native Salesforce Payments handler advertises. DIY merchants supply their own handlers; Google as a platform still expects Google Pay today.

Headless side effects

Because no storefront controller runs, work that today happens “after place order” in the storefront can be missing:

If you do this on the storefront today	What to plan for UCP
Send the order confirmation email from a controller	Salesforce Payments can use `dw.extensions.payments.sendOrderConfirmationEmail`. DIY merchants can send it from `complete.afterPOST` (the order is already placed) or from a job. See Post-Placement Actions.
Export the order to an OMS from a controller	Same: hook or job. Salesforce OMS and third-party OMS are optional but required if you want lifecycle events on the platform.
Offer store pickup	Filter pickup methods in `modifyResponse` hooks if the platform should not show them. See Filtering Store Pickup.
Handoff to the storefront (age checks, complex promotions)	Configure Continue URL. Without a storefront plugin, the buyer can land with an empty cart. See Continue URL.

Next steps

Close the gaps you found — Implementation Considerations for hooks and samples, Transaction Management before you put callouts or Transaction.wrap() in complete-flow hooks.
Enable UCP and publish the business profile — Configuration & Discovery.
Create a SLAS private client for Checkout Session APIs — Checkout Session Authentication.
If you are transacting with Google, complete Enabling Google as a Platform.