Accepting payments with @cai.com: adding CAI checkout to your website or SaaS

A SaaS developer wants to accept payments without a merchant account, without chargebacks, and without asking customers to leave the checkout flow. A marketplace needs to collect payments from buyers and settle them to sellers. An AI agent needs to pay for API access programmatically. All three scenarios converge on the same problem: how does money move from payer to payee without a Plaid link, a Stripe onboarding, or a wallet address pasted in chat?

The @cai.com payment path covers two sides. The payer side (an agent paying from a CAI wallet, or a human tapping a hosted confirmation page) has been covered elsewhere. This post covers the merchant side: how to accept payments through CAI, what the API looks like, and where the honest limits are.

The two payment paths for merchants

CAI exposes two distinct receive paths, and the choice between them depends on how the customer pays.

Card (fiat) path: create_onramp_url returns a MoonPay-hosted URL where the customer pays by credit card. The funds land in the merchant's custodial EVM address as USDC (or the selected stablecoin). The merchant needs a CAI API key with pay or full scope.

Crypto path: create_deposit_link returns a CAI-hosted page (/act/<token>) showing the merchant's custodial addresses and QR codes. The customer sends crypto from their own wallet, and the deposit is indexed by CAI's activity feed.

The two paths are not interchangeable. Card works for customers who hold fiat. Crypto works for customers who hold USDC or other supported tokens. The merchant can offer both, or one, depending on their customer base.

The card path: create_onramp_url

The card path routes through MoonPay, which handles the fiat-to-crypto conversion, compliance checks, and card network processing. The merchant does not need a separate MoonPay account. The CAI API key is the only credential.

curl -X POST https://api.cai.com/functions/v1/create-onramp-url \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_usd": 50.00,
    "default_currency_code": "usdc_eth"
  }'

The response includes a url that the merchant redirects (or links) the customer to. The customer fills in their card details on MoonPay's hosted page, and the crypto lands in the merchant's custodial EVM address. The walletAddress is set server-side to the API key owner's custodial address, so the merchant does not need to specify a destination.

This is not a full payment processor. There is no cart abstraction, no order webhook, and no inventory management. The receipt is the MoonPay payment intent. The merchant confirms the payment by polling GET /payment-intent-status with the intent id, or by checking GET /wallet-activity-list for the incoming deposit.

Honest limit: MoonPay is a third-party provider. KYC requirements and regional availability apply. If MoonPay is unavailable for a given region (the API returns a 503 with GAP_ONRAMP_V1), the card path is unavailable for that customer. The honest fallback is the crypto deposit path.

The crypto path: create_deposit_link

For customers who already hold crypto, the deposit path is simpler. The merchant calls create_deposit_link and gets a CAI-hosted page.

curl -X POST https://api.cai.com/functions/v1/create-hosted-action \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "deposit"
  }'

The response is a url like https://cai.com/act/<token>. The merchant sends this URL to the customer. The customer opens it, sees the merchant's custodial addresses and QR codes for each chain, and sends crypto from their wallet. The deposit is indexed by CAI's activity feed and appears in GET /wallet-activity-list.

The deposit link is single-use and short-lived. The customer has a window to complete the deposit before the URL expires. The merchant can verify the deposit by polling GET /wallet-deposit-activity or GET /wallet-activity-list with the customer's name or reference.

For the crypto path, the merchant's custodial address is printed on the page. The customer sends from their own wallet, whether that is a CAI wallet, a MetaMask, a Ledger, or any other wallet that supports the target chain. The merchant does not need to know which wallet the customer uses.

The hosted action pattern

Both paths build on the same hosted action infrastructure. A hosted action URL is a CAI-hosted page that the payer or the customer opens in a browser. The page is HTTPS, the token is single-use, and the URL expires in a short window (typically 15 minutes). The page does not require the visitor to have a CAI account.

The hosted action is the user-confirmation surface. The payer sees the recipient, the amount, the chain, and taps once. The merchant sees the confirmation on the other side. The hosted action pattern is the same regardless of whether the flow is a deposit, a transfer, a login, or a wallet connect.

Confirming the payment

After the customer completes the payment (card or crypto), the merchant needs to confirm it landed. The confirmation tool depends on the payment method.

For card payments via MoonPay, the merchant polls GET /payment-intent-status with the payment intent id returned by the MoonPay flow. The response includes the status, the on-chain tx hash, and the confirmation count.

For crypto deposits, the merchant reads from the activity feed. GET /wallet-activity-list with direction: "in" and category: "deposit" returns the indexed deposits. If the deposit is not yet indexed, GET /wallet-deposit-activity or POST /wallet-deposit-confirm (with the tx hash) can surface it.

The distinction matters: card payments are confirmed through the payment intent API, not through the transfer status API. Crypto deposits are confirmed through the activity feed, not through the transfer status API. The transfer status API is for outbound custodial transfers, not for incoming deposits.

Guardrails and honest limits

CAI's receive path is designed for daily spending, not for treasury-sized balances. The $200/day auto-limit applies while the security audit completes. New recipients and new devices always require confirmation. Think of it like cash in your pocket, perfect for daily spending. The vault product (multi-sig, time-locks) is coming for larger balances.

The card path routes through MoonPay, which is a third-party provider. KYC and region limits apply. The crypto path is self-service: the customer sends from their wallet, and the merchant confirms on the activity feed.

The receive path is not a full payment processor. There is no cart, no order webhook, no inventory management, and no chargeback handling. The merchant handles the business logic of linking a payment to an order, and CAI handles the settlement.

---

If you tried the receive flow and hit a bug

Comment below with:

1. What you ran -- the API call, the hosted action URL, the curl command. Copy the actual request or the page URL.
2. What you expected -- one sentence.
3. What you got -- the error message, the empty response, the unexpected behavior. Paste it verbatim.
4. Your environment -- OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.