Hosted checkout

Every checkout session comes with a ready-to-share URL. Send the buyer there and ShiftxPay hosts the payment page for you — no SDK, no front-end build, no PSP script wiring. The hosted page mounts the same PSP surfaces the SDK does and runs the same confirm flow.

The checkout URL

When your server creates a session with POST /v1/checkout-sessions, the response includes a checkout_url whenever a hosted-checkout origin is configured:

{checkout-origin}/{id}#{session_secret}

For example:

https://pay.lite.shiftxpay.com/cs_3Nf.../#cs_secret_8s2k...

Two things to note about the shape:

• The session id (cs_...) is the path; ShiftxPay looks the session up by it.
• The session secret (cs_secret_...) rides in the URL fragment (after #). A fragment is never sent to the server in the request line and never appears in server logs or the Referer header, so the secret stays out of access logs while still being available to the page's JavaScript.

Use it

Redirect the buyer to checkout_url, or render it as a link or button:

<a href="https://pay.lite.shiftxpay.com/cs_3Nf.../#cs_secret_8s2k...">
  Pay Rs 1,250.00
</a>

That is the whole integration on the buyer side. The hosted page resolves the session, mounts the PSP surface, collects the card inside the PSP iframe, and finalizes the payment. For redirect-based methods and 3-D Secure it also handles the return and the poll-confirm loop — see 3-D Secure & redirects.

Hosted page or embedded SDK?

Both consume the same session object, so you can create a session and decide per buyer whether to redirect them to checkout_url or mount the SDK. The server step is identical either way.

Lifetime

A checkout session expires 30 minutes after it is created (expires_at in the create response). Generate a fresh session if the buyer returns after the link has expired.