Skip to main content

Overview

The embedded checkout SDK is framework-agnostic. The snippets below show idiomatic integrations for the three most common frontend frameworks. The pattern is the same in each: your backend creates the payment request and mints a checkout session token, the frontend asks your backend for { requestId, token }, then lazy-loads the SDK and calls CaiboCheckout.init() with a paymentUrl that carries the token. Your merchant apiKey never reaches the browser.

1) Backend: mint the token

The frontend frameworks below assume an endpoint on your own server that creates the payment request, mints the token, and returns both. A minimal Node.js sketch:
Never expose process.env.CAIBO_API_KEY to the browser. The whole purpose of the token is to keep the apiKey server-side.

2) Frontend: open the iframe with the token

Common Patterns

Mint server-side, on demand

Mint the token the moment the user clicks Pay, not on page load. The token is valid for 15 minutes; minting it lazily avoids wasted tokens for users who never check out.

Lazy-load the SDK

Inject the script tag only when the user clicks Pay, so first-page-load performance is not affected.

Re-mint on token expiry

If the customer leaves the iframe open past 15 minutes, mint a fresh token server-side and re-open the iframe. The SDK does not auto-refresh.

Reuse the SDK global

The script exposes window.CaiboCheckout once. Guard against duplicate <script> injection by checking for it before loading.

Next Steps