Hosted Checkout
Recommended. Pre-built cart, authentication, addresses, fulfilment, discounts, payment, and order confirmation inside an embeddable checkout.
Custom checkout
Advanced. Use the Storefront SDK when the business requires complete control over the checkout UI and payment experience.
Hosted Checkout path
Install the checkout package and use the framework-specific integration.@commercengine/storefront, use authMode: "provided" and two-way token synchronization. This preserves one user, cart, and analytics journey.
Hosted Checkout handles:
- cart review and quantity updates
- OTP login/registration
- saved and new addresses
- delivery and collect-in-store options where configured
- coupons, promotions, loyalty, and credit features
- payment-provider UI
- order completion and callbacks
onReady, onError, onSessionError, and onComplete, and keep cart/checkout controls disabled until checkout is ready.
Custom checkout prerequisites
A custom checkout requires:- an active cart with at least one item
- a logged-in customer session
- billing and shipping addresses as applicable
- a valid fulfilment preference for physical goods
- an available payment method unless
to_be_paidis zero
register_if_not_exists: true for a single login/register path.
1. Review the current cart
- ensure the cart is active and not expired
- revalidate item availability
- display
to_be_paidas the final payable amount - show promotions, coupons, loyalty, credit, tax, and shipping separately
2. Authenticate
Ifsdk.isLoggedIn() is false, complete OTP or password authentication before entering the protected checkout steps.
3. Create or select an address
For a custom checkout, create addresses on the customer profile and link their IDs to the cart. This preserves them for later orders.createAddress body type from the LLM-first reference. Address fields can vary by country and operation version.
Link the selected addresses:
Pincode lookup
For supported countries, use the helper operation to suggest city/state after the customer enters a valid-length pincode. Debounce the lookup and allow manual correction if no result is found. Do not treat an address lookup as a deliverability check.4. Check deliverability
unserviceable_items where returned to explain whether the whole cart or only specific items cannot be delivered.
Do not use legacy shipment serviceability endpoints or guess a path; retrieve the exact current operation contract.
5. Retrieve fulfilment options
- summary availability and recommendation
- delivery shipments and shipping methods
- courier options for an aggregator method
- collect-in-store locations
6. Set fulfilment preference
Delivery example:Address, deliverability, and fulfilment
7. Apply discounts
Coupons, loyalty points, and credit balance update the cart. Use the returned cart after every operation and display the newto_be_paid.
A 100% discount or sufficient credit can produce to_be_paid: 0; order creation may then complete without a payment redirect.
8. Discover and validate payment methods
For a custom payment UI, retrieve the store’s available methods rather than hardcoding cards, UPI, banks, or wallets.juspay. Retrieve the exact method and schema contracts from the LLM-first reference.
For express payment UIs:
- use card BIN lookup before declaring a network supported
- validate UPI VPA before submission where applicable
- do not store or log raw card/OTP data
- prefer provider-hosted surfaces when PCI scope and complexity are not justified
9. Create the order
Hyper Checkout example:10. Verify payment status
Do not trust redirect query parameters as the authoritative payment result. Commerce Engine processes provider callbacks asynchronously. Poll the order status after the customer returns:11. Retry a failed payment
Only show Retry whenis_retry_available is true.
Order creation, payment verification, and retry
Payment-return resilience
The return page should recover from:- missing query parameters
- browser refresh
- a new tab
- delayed provider callback
- network failure during polling
- customer navigating away and returning through order history
Error handling
Do not blindly retry order creation. An ambiguous response can still mean an order was created.
Accessibility and UX
- preserve checkout step state after recoverable errors
- focus the first invalid field
- announce total and fulfilment changes
- prevent accidental double submission
- show progress without trapping keyboard focus
- provide clear processing, success, failed, and pending states
- keep order confirmation accessible after refresh through account history
Analytics in a custom checkout
@commercengine/analytics is not tied to Hosted Checkout. A custom checkout built with the Storefront SDK or direct REST can map the same canonical Commerce Engine Cart, CartItem, Order, and user entities into Segment/RudderStack-compatible events.
The application owns the semantic trigger—for example, emit Checkout Started when the customer actually begins checkout—while the package owns the event schema and entity normalization.
Commerce analytics
Use the vendor-neutral mapper package with Hosted Checkout, custom SDK checkout, direct REST, any compatible CDP, or a custom analytics pipeline.
Production checklist
Custom checkout skills
The cart-checkout skill contains detailed cart queues, address/fulfilment selection, payment discovery, payload, polling, and retry references.