Checkout Flow
This guide walks you through the process of converting a customer’s shopping cart into a placed order, including address validation, shipping checks, payment processing, and handling payment retries. It utilizes endpoints primarily from the Carts, Orders, Payments, Shipping, and Common modules.Prerequisites
- A valid
cart_idrepresenting the customer’s cart with items added. - A valid user session token (
access_token), which can be for an anonymous or logged-in user.
- Review Cart: Display the final cart contents and totals.
- Collect Addresses: Gather or confirm billing and shipping addresses.
- Validate Pincode Serviceability: Check if shipping is available to the destination.
- (Optional) Apply Discounts/Credits: Allow final application of coupons, loyalty points, or credit balance.
- Create Order & Initiate Payment: Send the cart details to create an order and get payment instructions.
- Process Payment: Redirect user or use SDKs to complete payment via the chosen gateway (Juspay recommended).
- Handle Payment Callback/Redirect: User returns to your site from the payment gateway.
- Verify Payment Status: Poll the Commerce Engine API to confirm the final payment status.
- Display Confirmation/Failure: Show the appropriate order confirmation or payment failure/retry screen.
1
Review Cart
Before proceeding, ensure the customer can review their cart. Fetch the latest cart state:
GET /carts/{cart_id}orGET /carts/users/{user_id}- Display
cart_items, pricing breakdown (subtotal,tax,shipping,grand_total), applied discounts (coupon_code,loyalty_points_redeemed, etc.), and the finalto_be_paidamount.
2
Collect & Update Addresses
Accurate addresses are required for tax calculation, shipping cost determination, and delivery.
-
Logged-in Users:
-
Fetch saved addresses using
GET /customers/{user_id}/addresses. -
Allow the user to select existing billing and shipping addresses or add a new one (
POST /customers/{user_id}/addresses). -
Update the cart with the selected address IDs using
POST /carts/{id}/address:Update Cart with Saved Address IDs
-
Fetch saved addresses using
-
Anonymous / Guest Users:
- Provide forms to collect billing and shipping address details.
-
Use
GET /common/countries,GET /common/countries/{country_iso_code}/states, andGET /common/countries/{country_iso_code}/pincodes(with querypincode=...&limit=1) to potentially provide dropdowns or validate inputs for Country, State, and City based on Pincode. -
Update the cart with the collected address details using
POST /carts/{id}/address:Update Cart with New Address Objects
Cart UpdateThe
POST /carts/{id}/address call returns the updated Cart object, which will now include potentially recalculated shipping_amount_including_tax and grand_total based on the destination. Re-render the cart summary if these values changed.3
Validate Pincode Serviceability (Optional)
Provider DependencyThis step requires an integration with a shipping provider that supports pincode serviceability checks through Commerce Engine.
GET /shipment/pincode-serviceability/{pincode}- Path Parameter:
pincode(from the shipping address). - Response:
200 OKwithsuccess: true: Delivery is available.4xxError (e.g., 404 or specific error code if defined): Delivery is not available. Display an appropriate message to the user, preventing them from proceeding with this address.
Pincode Serviceability Check Flow
4
Apply Final Discounts/Credits (Optional)
Provide options for the user to apply any last-minute coupons, loyalty points (logged-in only), or credit balance (logged-in only) using the respective
POST /carts/{id}/... endpoints described in the Carts module documentation. Remember to handle potential errors (e.g., coupon requires login). Update the cart summary after each successful application.5
Create Order & Initiate Payment
This is the core transition from cart to order.
-
POST /orders - Authentication: Bearer Token
-
Request Body:
cart_id: Required. The ID of the finalized cart.payment_gateway: Required."JUSPAY"or"PAYU". (Juspay recommended).payment_gateway_params: Required. An object containing parameters specific to the chosen gateway.
Example for PayU (Requires more setup):Create Order Request (Juspay Hyper-Checkout)Create Order Request (PayU)Advanced Use CasesFor Juspay Express Checkout or other complex integrations, consult the specificJuspayPaymentGatewayParamsandPayuPaymentGatewayParamsschemas and potentially use helper endpoints likePOST /payments/juspay/create-orderorPOST /payments/generate-hash(PayU) before this step if required by your chosen integration pattern. Hyper-Checkout simplifies this significantly. -
Response (Success -
200 OK):message,successcontent:order: The newly createdOrderDetailobject (initial status likely ‘draft’ or similar,payment_status: 'pending'). Contains theorder_number.payment_required: Boolean (usuallytrue).payment_info: An object containing instructions for the payment gateway. The structure depends on the chosen gateway (PayuPaymentInfoorJuspayPaymentInfo).
payment_infofor Juspay Hyper-Checkout:ExampleCreate Order Response (Juspay Hyper-Checkout)payment_infofor PayU:Create Order Response (PayU)
6
Process Payment
Based on the
payment_info received:- Juspay Hyper-Checkout: Redirect the user’s browser to the
payment_info.payment_links.webURL. Juspay handles the payment method selection and processing. - PayU: Typically requires submitting the fields from
payment_infoas a form POST to the PayU payment URL. - Other Integrations (Juspay Express, SDKs): Follow the specific integration guide for the chosen method, using data from
payment_info(e.g.,sdk_payloadfor mobile SDKs).
7
Handle Payment Callback/Redirect
Once the user completes (or cancels) the payment on the gateway’s page/interface, the gateway redirects them back to the
return_url (for Juspay Hyper-Checkout) or surl/furl (for PayU) that you provided during order creation.- This callback URL is on your storefront application.
- The URL might contain query parameters added by the gateway (e.g., transaction status, IDs).
Verify Status via APIDO NOT rely solely on callback/redirect parameters to determine the final order status. They are informational and can sometimes be unreliable or manipulated. You must verify the definitive status with the Commerce Engine API in the next step.
8
Verify Payment Status
On your callback/return page (
return_url), the crucial step is to poll the Commerce Engine API to get the authoritative payment status for the order.-
Endpoint:
GET /orders/{order_number}/payment-status - Authentication: Bearer Token
-
Path Parameter:
order_number(obtained in Step 5 response). -
Polling Logic:
- Make the first call immediately when the user lands on the
return_url. - Check the
content.statusin the response. - If
statusissuccess: Payment is confirmed. Proceed to Step 9 (Confirmation). - If
statusisfailed: Payment failed. Checkcontent.is_retry_available. Proceed to Step 9 (Failure/Retry). - If
statusispendingorpartially_paid: The payment outcome is not yet final. Wait for a short interval (e.g., 5 seconds) and repeat the API call (poll again). Continue polling until the status becomessuccessorfailed, or until a reasonable timeout (e.g., 1-2 minutes) is reached.
- Make the first call immediately when the user lands on the
-
Response (
200 OK):Payment Status Response
Why Polling is NecessaryPayment gateway notifications can be delayed or asynchronous. Polling
GET /orders/{order_number}/payment-status ensures you get the confirmed status directly from Commerce Engine, which manages gateway webhooks and status updates reliably on the backend.9
Display Confirmation / Failure / Retry
Based on the final status obtained from polling:
- If
status==success:- Display an Order Confirmation page showing order details (you can fetch full details again using
GET /orders/{order_number}). - Thank the customer!
- Display an Order Confirmation page showing order details (you can fetch full details again using
- If
status==failed:- Check
is_retry_available:- If
true: Display a “Payment Failed” message and offer a “Retry Payment” button. See “Handling Payment Retries” below. - If
false: Display an “Order Failed” message, explaining that payment could not be processed and potentially advising the customer to try again later or contact support. Do not offer an immediate retry.
- If
- Check
- If Polling Times Out (Status remains
pending): Display a message indicating the payment is still processing and advise the customer to check their order history later or contact support. Avoid confirming the order prematurely.
Handling Payment Retries
If payment failed butis_retry_available was true:- When the user clicks “Retry Payment”:
-
Call
POST /orders/{order_number}/retry-payment. - Authentication: Bearer Token
-
Path Parameter:
order_number. -
Request Body: Similar to
POST /orders, requirespayment_gateway_paramsto potentially re-initiate the gateway flow (e.g., providingreturn_urlagain for Juspay).Payment Retry Request Body (Juspay Example) -
Response: Similar to
POST /orders, provides newpayment_info(e.g., a new Juspaypayment_links.webURL). - Redirect the user to the new payment URL (Step 6).
- The process continues from Step 7 (Handling Callback) and Step 8 (Verify Payment Status).
Checkout & Retry Flow (Juspay Hyper-Checkout)