Quickstart

Integrate the Checkout API in a few steps. This guide is split into three parts:

1. Prerequisites (this page) — what you need before writing code, and the three credentials every integration uses.
2. Payments — accept one-time payments in direct or two-step mode.
3. Subscriptions — recurring stablecoin billing.

Before you begin

You’ll need:

1. An Exodus Business account - Contact [email protected] to create your account and complete onboarding (including KYB verification).
2. A settlement address - The wallet address where you’ll receive stablecoin payments. Configure it in your dashboard.
3. A server-side environment - Node.js, Python, Ruby, or any language that can make HTTP requests. Always call the API from your server, never the browser.

Your three credentials

A Checkout integration uses three distinct credentials, each with a different job. Don’t mix them up: the API key says who you are, the signing keys authorize moving funds, and the webhook secret lets you trust events we send you.

1. API key

Authenticates your account on every API request. Sent as a bearer token: Authorization: Bearer sk_live_....

• What it’s for: identifying your business on every call to the Checkout API.
• How to get it: open your Exodus dashboard → Settings → API keys and copy the key. Test keys are prefixed sk_test_, live keys sk_live_.
• Keep it secret: server-side only. Never ship it to the browser or commit it to source control.

See Authorization for the full reference.

2. Signing keys

A separate cryptographic key-pair that authorizes fund movement — creating direct checkouts, capturing or refunding two-step payments, and charging subscriptions. Your API key alone cannot move funds: those actions require a signature from your signing key, which the API verifies before executing.

• What it’s for: signing fund-moving actions so the API and the on-chain contracts can verify you authorized them.
• How to get it: generate a Signing Key in your dashboard under Settings → Signing key. The dashboard issues one sgk_… secret (shown once) that derives a signer for every chain family, and registers those signer addresses for you (set your settlement addresses first). The key is generated in your browser — Exodus never sees it — so store it securely as SIGNING_KEY; it can’t be recovered if lost.
• Keep it secret: the Signing Key derives every chain key. Treat it like an API key.

Alternatively, generate one yourself with the @exodus/checkout-signer SDK’s CheckoutSigner.generate() — handy for regenerating, or generating outside the dashboard:

import { CheckoutSigner } from '@exodus/checkout-signer'
 
const { signingKey, addresses } = CheckoutSigner.generate()
 
console.log('Signing Key:', signingKey) // store securely as SIGNING_KEY (shown once)
console.log('EVM signer address:', addresses.evm) // register with Exodus
console.log('Solana signer address:', addresses.solana) // register with Exodus

See Signed Requests for how signing works per action.

3. Webhook secret

An HMAC-SHA256 secret used to verify that incoming webhook events genuinely came from Exodus. Every webhook carries an X-Signature header you check against this secret.

• What it’s for: authenticating the payment and subscription events we POST to your server.
• How to get it: in your dashboard, register your webhook endpoint URL; the dashboard then shows the signing secret for that endpoint. Store it as WEBHOOK_SECRET. The secret stays the same if you later change the URL; use Regenerate secret in the dashboard to issue a new one.
• Keep it secret: anyone with it can forge events.

See Webhooks for verification code and the full event list.

Test and live businesses

There’s no separate sandbox environment. Test and production run through the same dashboard; what differs is the business your API key belongs to. Every business is either test or live:

• Test business - has testnets enabled, so you build and verify the full flow on testnet networks without moving real funds. Its API keys are prefixed sk_test_.
• Live business - operates on mainnet and processes real payments. Its API keys are prefixed sk_live_.

The sk_test_ / sk_live_ prefix is determined by the business that issued the key; it isn’t a per-request toggle. Build against your test business, then use your live business for production.

When you’re ready for production:

1. Use your live business’s sk_live_ API key - ask your account manager to set one up if you don’t have a live business yet.
2. Set your mainnet settlement address on the live business.
3. Register your production webhook URL and use that business’s webhook secret.
4. Run the full flow once on mainnet before taking real payments.

Next steps

• Payments Quickstart
• Subscriptions Quickstart
• Explore the full API Reference