X402 for AI Agents: HTTP Payments Without API Keys

X402 lets AI agents make HTTP payments directly, without needing per-service API keys, by embedding payment instructions in the request itself and settling via Web3 wallets. Instead of signing up for each API and storing separate keys, an agent sends a standard HTTP request with a payment header, and the server responds with a 402 Payment Required status that includes a payment request. The agent then pays, and the server fulfills the original request.

Background: Why API Keys Don’t Work for Agents

Traditional API access relies on per-service keys: you register with each provider, get a secret key, and send it in every request. That works for a human managing a few services, but it breaks down for AI agents that need to call many services dynamically. Agents can’t pre-register with every possible API, and storing hundreds of keys creates security risks. X402 solves this by making payments the authentication mechanism—if you pay, you get the data, no key required.

How X402 Payments Work Over HTTP

The core flow is simple and mirrors the HTTP protocol’s existing status codes:

Agent sends a request to a server, e.g., GET /data, with no API key.
Server responds with 402 Payment Required, including a Payment-Request header that specifies the amount, currency, and a payment URL (usually a Web3 wallet address or a payment processor endpoint).
Agent parses the header, sees the cost, and decides to pay.
Agent sends a payment transaction to the specified address (e.g., via a crypto wallet or a smart contract).
Agent re-sends the original request, now including a proof of payment (a signed receipt or transaction hash).
Server verifies the proof and returns the requested data.

This is a simplified version; in practice, the payment proof is often embedded in a header like Payment-Proof, and the server may verify it against a blockchain or a trusted payment processor.

Why Use 402 Status Code?

The 402 status code has been part of HTTP since 1998 but was never standardized for practical use. X402 revives it because it’s semantically perfect: it tells the client that payment is required. Using a standard status code makes the protocol interoperable—any HTTP client can recognize it, and any server can implement it without custom extensions. It also keeps the payment flow transparent: the client knows exactly why the request was rejected and what to do next.

Payment Verification Without API Keys

The key question is: how does the server trust the payment proof? X402 leverages public-key cryptography and blockchain or payment-processor APIs. The agent signs a message with its private key, and the server verifies the signature against the public key associated with the payment. For crypto payments, the server can check the transaction on-chain. For fiat, it can call a payment processor’s API to confirm the payment. In both cases, no per-service API key is needed—the server just needs to know the payment address or processor endpoint.

Common Problems and Misconceptions

Misconception: X402 requires a crypto wallet. While many implementations use crypto, the standard is agnostic. Payment processors (like Stripe or PayPal) could also issue payment requests and verify proofs, so an agent could pay with a credit card. However, current implementations lean heavily on crypto because it’s fully automated and doesn’t require human interaction.

Problem: Double-spending or replay attacks. If an agent pays once and reuses the proof, the server should reject it. X402 addresses this by including a nonce (a unique request ID) in the payment proof, so each proof is valid only for a single request. The server stores used nonces to prevent replay.

Problem: How does the agent know the price before paying? The 402 response includes the price in the Payment-Request header, so the agent can decide whether to proceed. Some servers might also offer a range or a subscription option, but the basic flow is per-request pricing.

How to Choose an X402 Implementation

When evaluating X402 libraries or services, consider:

Payment rails: Does it support the payment methods your agents will use (crypto, fiat, etc.)?
Verification method: Does it verify on-chain, via API, or both? On-chain is more decentralized but slower; API is faster but requires a trusted processor.
Ease of integration: Does it work with your existing HTTP stack? Most implementations are middleware for popular frameworks.
Security features: Does it handle nonces, signatures, and replay protection out of the box?
Cost: Some implementations charge a fee per transaction; others are open-source and self-hosted.

Costs and Safety Considerations

Costs: X402 itself doesn’t add a fixed fee—the cost is whatever the server charges for the data, plus any network fees (e.g., gas fees for crypto transactions). For high-frequency calls, per-request payments can add up, so some providers offer batch or subscription options. Always check the pricing model before integrating.

Safety: The main risks are sending payments to the wrong address and leaking payment proofs. Always verify the payment URL comes from a trusted server (HTTPS, valid certificate). Never log payment proofs or private keys. For crypto, use a dedicated wallet with a small balance for each agent, and consider using a payment processor that handles custody.

Alternatives to X402

Several alternatives exist for agent payments:

API keys with metering: Traditional but requires pre-registration and key management.
OAuth with billing: More complex, but allows scoped access and usage-based billing.
Stripe Payment Links: Human-friendly but not automated for agents.
Cryptocurrency direct payments: Agents can send payments manually, but without a standard protocol, each service needs custom logic.
Smart contract-based access: Agents pay a smart contract to unlock data, but this requires the service to be on-chain.

X402’s advantage is its simplicity and universality—it’s just HTTP.

Frequently Asked Questions

Do I need a crypto wallet for X402?

Not necessarily. While most current implementations use crypto, the standard allows any payment method. A server could issue a payment request to a Stripe checkout URL, and the agent could pay via a card. However, for fully automated agent-to-agent payments, crypto is the most practical because it doesn’t require human interaction.

How does the server verify the payment proof?

It depends on the implementation. For crypto, the server checks the transaction on the blockchain (e.g., via an RPC node). For fiat, it calls the payment processor’s API to confirm the payment. The proof is usually a signed message or a transaction hash that the server can verify independently.

Can X402 prevent replay attacks?

Yes, by including a unique nonce in the payment proof. The server stores used nonces and rejects any proof with a duplicate. This ensures that a single payment can only be used once.

What if the agent doesn’t have enough funds?

The agent will receive a 402 response and can decide to skip the request or try another service. The agent’s wallet or payment processor will reject the transaction if funds are insufficient, and the agent can then fall back to a free alternative or wait for the user to add funds.

Is X402 production-ready?

As of now, X402 is still evolving. There are working implementations and a growing ecosystem, but it’s not yet a formal standard. It’s suitable for pilot projects and early adopters, but for critical production systems, you should test thoroughly and have a fallback plan.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →