Grateful Merchants API
- Name: Grateful Merchants API
- URL: https://docs.exodus.com/checkout
- Category: hosted stablecoin checkout / subscription / payout API / merchant control plane
- Tags: ethereum-ecosystem
- Summary: Grateful Merchants API is now best read as the older project label for Exodus’s current Checkout API rather than as a standalone category anchor. Keep this note on the merchant-facing product surface — hosted checkout pages, subscriptions, payouts, settlement addresses, webhook delivery, and merchant signer workflow — while the broader operator boundary now lives in exodus.
- What it does:
- Lets merchants create hosted stablecoin checkout pages for one-time payments and subscription signups
- Exposes API-key-authenticated endpoints for checkouts, payments, subscriptions, reports, and webhooks
- Supports merchant settings for signer registration, settlement-address management, branding, webhook configuration, and business-mode control
- Supports customer and beneficiary objects for payout flows where crypto is off-ramped and delivered as fiat to a bank account
- Requires signed requests for fund-moving actions such as direct payments, captures, refunds, and merchant-driven subscription actions
- Packages the merchant flow inside Exodus’s broader docs and dashboard shell rather than as an independent protocol or neutral payment standard
- Key claims:
- Exodus’s docs
llms.txtnow present this surface asCheckout API, not as an isolated Grateful microsite, and place it alongside Passkeys, XO Swap, and other Exodus developer resources, which is the main taxonomy clue that the stronger operator boundary is Exodus rather thanGratefulas a separate ecosystem object - The Checkout overview says merchants can accept stablecoin payments, manage subscriptions, handle refunds, and build hosted checkout experiences across multiple blockchain networks
- The Checkout docs expose a much broader workflow than the older
create payment requestframing: checkouts, subscription checkouts, subscriptions, payments, payouts, beneficiaries, customers, reports, settings, and webhooks all live in one merchant API surface - The settings docs say merchant settings include business mode, per-chain signer status, checkout branding, PaymentFactory address, settlement address, and dashboard-managed webhook configuration, which is a more concrete control surface than generic payment-processing copy
- The signed-requests docs index in
llms.txtsays fund-moving actions require cryptographic signatures, including direct payments, captures, refunds, and merchant-driven subscription actions, which makes the merchant signer path part of the product’s practical authority boundary - The payout docs indexed in
llms.txtshow Exodus has stretched this surface beyond basic hosted checkouts into beneficiary registration, customer KYC flow, payout creation, and off-ramp delivery status
- Exodus’s docs
- Whitepaper: No canonical standalone Grateful Merchants API whitepaper or litepaper is the point here. The clearest current source of truth is Exodus’s live Checkout documentation, with the earlier local source bundle in
../whitepapers/grateful-merchants-api-primary-sources-2026-05-04.mdstill useful as background on the older naming. - Sources:
- https://docs.exodus.com/checkout
- https://docs.exodus.com/checkout/api-reference/settings
- https://docs.exodus.com/llms.txt
- ../whitepapers/grateful-merchants-api-primary-sources-2026-05-04.md
Internal linkages
- Company / operator boundary above the merchant surface: exodus.
- Adjacent wallet-onboarding boundary inside the same broader company shell: passkeys-foundation.
- Best hosted-stablecoin-flow comparisons at the operator-shell layer: coinflow and bridge-xyz.
Protocol / company boundary
- Keep this note on the merchant-facing product surface: hosted checkout pages, subscription flows, payout objects, webhook delivery, settlement-address handling, and signed-request requirements.
- Use exodus when the sharper question is who issues API keys, runs the dashboard, packages the docs shell, controls signer and settlement workflow, and decides how this merchant surface is bundled alongside Exodus wallet and Passkeys products.
- That split matters because this is not a neutral checkout standard. It is a hosted merchant workflow operated inside a broader Exodus company shell.
Control surface
-
Authority sits in API-key issuance, merchant-signer registration, PaymentFactory and settlement-address workflow, hosted-page behavior, branding defaults, webhook truth, payout and beneficiary handling, and which chains or stablecoin flows are supported.
-
Read it as hosted merchant middleware with a real company-run control plane above it, not as a base payment rail.
-
Last reviewed: 2026-08-10 UTC