Skip to main content
A checkout session is a page we host and you brand. It lists the wallets the payer’s browser exposes, lets them pick a network you accept, and states in words what they are approving before anything is signed.
Your server creates a session. The payer opens the page and picks a wallet. The wallet signs a bounded approval and today's payment. The chain confirms. Your server receives the events.Your server creates a session. The payer opens the page and picks a wallet. The wallet signs a bounded approval and today's payment. The chain confirms. Your server receives the events.

One checkout, from your server to the chain and back

Creating a session

Response
Send your customer to url. That is the whole integration on your side.

The parameters that matter

What the payer sees

The page carries your logo, tint and button colour from your branding settings. For a recurring price it explains two things before anything is signed:
  1. The amount charged today.
  2. The spending limit being approved, which covers about twelve periods, and that it is a cap rather than a charge.
The page lists wallets the browser actually exposes, and offers a QR code to continue on a phone when the wallet lives there instead. It never asks for a seed phrase or a private key.

After the payment

A completed session produces events. Subscribe to these rather than polling:

Sessions that are interrupted

A closed tab does not lose the payment. Reopening the link shows the session where the payer left it, and a session that already settled opens on its receipt rather than on a form. Sessions expire. After that the link stops accepting payments, and you create a new session if the customer still wants to pay.

Building your own page

If you would rather host the payment experience yourself, the API returns everything your page needs: the amount, the networks, the token addresses and the authorization to sign. Reclack keeps doing the billing underneath. See the checkouts reference for the payer-facing endpoints.