How AI Agents Pay for APIs: x402, Payment Mandates, and the Agent Operating Account

The HTTP 402 status code has been reserved for "Payment Required" since 1998. For most of the web's history, it sat unused. But AI agents making API calls autonomously are finally giving it real traffic.

When an agent hits a paid API endpoint, the question shifts from "can it pay?" to "how does it pay without waking a human for every dollar?" That breaks into two parts: a protocol for agent-to-API payment (x402) and a delegation mechanism (payment mandates) that lets agents spend within user-defined limits without asking permission each time.

The x402 flow

The x402 protocol is straightforward. An agent calls an API endpoint. The API responds with HTTP 402, including a payment challenge in the response body. The challenge specifies the recipient address, amount, chain, and token. The agent forwards this challenge to a payer service, which checks the user's balance and executes the transfer.

CAI's implementation uses three endpoints.

First, POST /x402-payment-prepare takes the challenge from the API and checks whether the user has sufficient balance and whether an active mandate covers this merchant. It returns an attempt_id and a requires_user_confirm flag. When the user has set up a payment mandate for this domain, the flag is false and the agent can proceed.

Second, the agent calls POST /x402-payment-execute with the attempt_id and user_confirmed: true (or skips confirm when the mandate covers it). CAI executes the custodial transfer on the requested chain and returns a tx_hash as proof.

Third, the agent re-requests the paid API resource, attaching the tx_hash or x402_retry_hint from CAI's response. The API verifies the on-chain payment and serves the resource.

The retry is the agent's responsibility. CAI returns the proof of payment. The agent presents it to the seller.

Payment mandates: spending limits for autonomous agents

The mandate system is the more interesting piece. A payment mandate is a user-created permission that lets an agent spend up to certain limits on a specific merchant domain without asking for confirmation every time.

The flow starts with POST /payment-mandate-create. The user specifies the merchant_domain, a max_amount_per_payment_usd, a daily_cap_usd, optional allowed_resource_patterns, and an expires_in_hours value. The user approves the mandate through CAI's hosted verification page. Once active, the agent can call x402_payment_prepare for any charge on that domain, and the response sets requires_user_confirm: false as long as the charge stays within the mandate's limits.

The user can revoke the mandate at any time with POST /payment-mandate-revoke or inspect active mandates with GET /payment-mandate-status.

This follows the same pattern as the AP2 (Authorization Protocol for Payments) concept, but CAI's implementation is a CAI-native version. The system enforces spending caps per payment and per day, and the domain pattern matching limits which API endpoints the mandate covers.

Where the agent gets its wallet

Before any of this works, the agent needs a wallet to pay from. CAI's model is a custodial multi-chain wallet accessed via API key. The agent calls GET /get-identity to confirm the account exists, then POST /get-wallet-balances to check balances on the relevant chain.

If the balance is insufficient, the agent can generate a deposit link with POST /create-hosted-action (with action_type: "deposit") or use the fiat on-ramp via MoonPay (third-party KYC applies). The agent does not handle private keys. It calls the CAI API, and CAI executes the custodial transfer.

The full sequence is documented in the skill.md contract at https://api.cai.com/functions/v1, which is the single source of truth for all endpoints, scopes, and gap IDs.

The MCP path

For agents that use the Model Context Protocol, the @cailab/mcp npm package provides a stdio transport that exposes the same set of tools. The agent sets CAI_API_KEY as an environment variable and the MCP server handles the authentication and routing. The same x402 endpoints, mandate tools, and wallet operations are available through the MCP interface.

Early access guardrails

Since this is early access, CAI applies a $200 per day automatic spending limit. New recipients and new devices need user confirmation before the first transfer. The vault product for storing third-party site credentials is also available, which lets agents store and retrieve login credentials for platforms they interact with.

The honest label

The capabilities page at cai.com/capabilities.html marks x402 as Live and payment mandates as Live. Both carry gap IDs (GAP_X402_V1, GAP_PAYMENT_MANDATE_V1) that signal the implementation is operational but may not cover every edge case. The gap IDs are part of the API response, so agents can check them and adjust their behavior accordingly.

WeChat Pay is listed as Planned. Bridge and cross-chain transfers are Live (with GAP_BRIDGE_V1). The fiat on-ramp via MoonPay is Live with third-party KYC limits.

What this means for agent developers

Agent-to-API payment is no longer a design problem you need to solve from scratch. The x402 protocol gives you a standard way to handle HTTP 402 challenges. The mandate system lets agents operate autonomously within user-defined limits. The custodial wallet model means the agent never touches a private key.

The API contract lives at cai.com/skill.md. The MCP package is on npm. The capabilities matrix is at cai.com/capabilities.html. The agent calls get_identity, checks balances, and pays when it needs to.

The 402 status code has been waiting for a use case since 1998. AI agents might be the one that finally makes it stick.