Which product do I need?
One API, two products — the wallet service for platforms that hold balances for their users, and hosted checkout for merchants who sell things.
Both live under one base URL, one authentication scheme and one set of conventions — money as strings, idempotency, cursor pagination, the error envelope, webhook signing — so integrating both never feels like integrating twice. What differs is which resources you use and which kind of key you carry.
The wallet service
For a platform that keeps a balance per user: an exchange, a marketplace, a game, a broker. Every customer gets a permanent deposit address on every chain you enable; deposits credit their ledger balance; you pay out on request.
- Resources:
/v1/customers,/v1/wallets,/v1/deposits,/v1/balances,/v1/payouts - Key kinds:
walletfor addresses and reads,payoutfor money out - Start with the Quickstart
Hosted checkout
For a merchant who sells something and wants to be paid in crypto: an invoice with a price, a deadline and
an address per chain, a hosted page the payer lands on, and invoice.paid when the money is final.
- Resources:
/v1/invoices,/v1/billing - Key kind:
checkout— the key your storefront carries cannot move money out, whatever scopes it holds - Create a payment link from the dashboard with Create and share an invoice, or integrate the Invoices API.


Both
A key's kind fences which routes it reaches, so an integration that does both holds two keys: a checkout
key in the storefront and a wallet (and, when needed, payout) key on the backend. Keys are minted in
the console, where the limit for each kind is displayed, and shown once. Authentication has the details.
The payout kind is the one to guard
Everything that moves money out — payouts, their approvals, the destination allowlist — sits behind the
payout kind. Hold that key on your backend only, pin it to your server's IP addresses, and never let
it near a browser.