You can open the Cashier without the Web SDK by redirecting to, or embedding, the URLs returned when you create a session: checkoutUrl, depositUrl or withdrawalUrl.
ℹ️ Note: Use the Web SDK unless a technical constraint prevents it. It's the recommended way to open the Cashier — see what you lose below.
Opening is only authorized with the Cashier token from the create-session response. Append it to the returned URL as the omCashierToken query parameter, URL-encoded. ct is an accepted alias for the same parameter.
<checkoutUrl>?omCashierToken=<url-encoded-token>The Cashier reads the token on load, stores it server-side, and strips it from the address bar — so it doesn't linger in browser history or Referer headers. Treat the token as a credential and never log it.
// checkoutUrl / depositUrl / withdrawalUrl come from POST /v3/public/cashier/session
window.location.href = `${checkoutUrl}?omCashierToken=${encodeURIComponent(token)}`;
// `ct` works as an alias: `${checkoutUrl}?ct=${encodeURIComponent(token)}`<iframe
src="<checkoutUrl>?omCashierToken=<url-encoded-token>"
width="900"
height="800">
</iframe>Use the checkoutUrl, depositUrl or withdrawalUrl exactly as returned by the create-session response, with the token appended.
Opening the raw URL works but drops the SDK's payment, KYC and analytics events, close/overlay handling, dynamic language, device detection and mobile sheet, styling, paymentAction, containerId, and the utility methods. See Web SDK → Methods and Events.
⚠️ Warning: The hosted Cashier's redirect or on-screen result is not authoritative. Determine the final status from a webhook or a GET on the transaction.