Skip to main content

Overview

A checkout session token is a short-lived secret that lets the embedded checkout iframe authenticate against the Caibo payment API without ever seeing your merchant apiKey. Your backend mints the token using your apiKey, hands it to the browser, and the SDK passes it to the checkout page in the paymentUrl.
Never embed your merchant apiKey in the iframe URL, in client-side code, in browser history, or in any URL that leaves your server. The apiKey is a long-lived bearer secret with full merchant access. Always exchange it for a checkout session token on the server.

Security model

A leaked checkout token can only act on the bound payment request, and only for the next 15 minutes. A leaked apiKey can drain the account.

Endpoint

The request body is empty ({}). The token derives its scope entirely from the path id and the authenticated merchant.
This call MUST originate from your backend. The browser must never see your apiKey. The whole point of this endpoint is to keep the long-lived secret on the server.

Response

Using the token

As a URL parameter (iframe src)

The iframe must boot from a URL — it cannot set a custom header on its initial document load — so the SDK accepts the token as a ?token= query parameter. The Caibo checkout page consumes the value on bootstrap, stores it in sessionStorage, then sends it on every subsequent request as X-Checkout-Token.
Notice there is no apiKey and no merchantId in the URL. The token already binds the merchant and the request server-side.

As a header (server-to-server calls from a non-browser client)

If your integration calls a permitted endpoint outside the iframe SDK, send the token as a header instead:

What a token is allowed to do

A request bearing a checkout session token is authorised for a small, fixed allow-list of endpoints, and every endpoint that carries a paymentRequestId (in the path or query string) must match the bound id exactly. Anything else returns 403 Forbidden. A checkout token explicitly cannot call POST /payment-requests/{id}/checkout-session — tokens cannot mint additional tokens. Use your apiKey to re-mint when one expires.

Lifecycle

1

Create the payment request (server, apiKey)

POST /payment-requests with X-API-Key. Save the returned id.
2

Mint the token (server, apiKey)

POST /payment-requests/{id}/checkout-session with X-API-Key. Save token and expiresAt.
3

Deliver the token to the browser

Return the token (and requestId) to your frontend via your own authenticated endpoint. The browser must not see the apiKey.
4

Open the iframe (browser, token)

Construct paymentUrl = .../main?requestId=…&token=… and call CaiboCheckout.init({ paymentUrl, ... }).
5

Token expires after 15 minutes

If the customer is still on the page when the token expires, mint a fresh one server-side and re-open the iframe. The token is not auto-refreshed.

Error responses

Once issued, errors when using a token surface as:

Backward compatibility

Legacy integrations that still pass ?apiKey= in the paymentUrl continue to work, but the checkout page emits a console.warn deprecation notice on every load. Plan a migration to the token flow — leaking an apiKey through the browser history or Referer header is a serious incident.

Next Steps