# What Is the x402 Protocol? HTTP 402 Payments for AI Agents

> A technical guide to the x402 protocol: how the HTTP 402 payment handshake works, the PAYMENT-REQUIRED and PAYMENT-SIGNATURE headers, facilitators, payment schemes, and where x402 fits next to card rails.
- **Author**: Ayush Agarwal
- **Published**: 2026-09-08
- **Category**: AI, Payments
- **URL**: https://dodopayments.com/blogs/x402-protocol

---

An autonomous agent is mid-task. It needs one call to a paid market-data API, one call to a paid geocoder, and one call to a paid image model. Each of those endpoints wants an API key, and each API key sits behind a signup form, a credit card on file, and a monthly invoice addressed to a human.

The agent has none of those things. It has a wallet and a task.

That gap is the entire reason the x402 protocol exists. Traditional API access control assumes a human signed a contract at some point in the past and that billing reconciles at the end of the month. Machine-to-machine traffic breaks both assumptions: the consumer may be ephemeral, the amount may be a fraction of a cent, and the decision to pay has to happen inside a single request cycle.

This guide walks through what x402 is, how the handshake actually works at the header level, what a facilitator does, and - honestly - what it does not solve for a company that also sells software to humans.

## What Is the x402 Protocol?

x402 is an open payment standard, originally developed by Coinbase, that revives the long-reserved HTTP 402 "Payment Required" status code so a client can pay for a single request without accounts, API keys, sessions, or subscriptions. The server answers an unpaid request with a 402 and a machine-readable description of what payment it will accept. The client signs a payment, retries the request with that signature attached, and gets the resource.

The important design choice is that payment becomes a property of the request itself rather than a property of a pre-existing relationship. There is no onboarding step, no key rotation, no plan tier. If the client can pay, the request succeeds.

Three roles participate:

- Client: the party that wants the resource. This can be a human-driven application or an AI agent acting on its own.
- Resource Server: the seller. This is the API or endpoint that holds something worth paying for.
- Facilitator: an optional third party that verifies payment payloads and settles them on the resource server's behalf, so the seller does not have to run chain infrastructure.

x402 is also transport agnostic. HTTP is the original transport, but the same handshake runs over MCP (Model Context Protocol) and over A2A (agent-to-agent) transports. If you are already thinking about how [agents discover and call paid tools over MCP](https://dodopayments.com/blogs/mcp-payments-ai-agents), x402 slots into that same conversation.

## How the x402 Payment Flow Works

The flow is a retry loop with a payment step in the middle. The client's first request is expected to fail, and the failure carries the instructions needed to succeed on the second attempt.

Here is the full sequence:

1. The client requests a resource with no payment attached.
2. The server returns HTTP 402 with a `PAYMENT-REQUIRED` header carrying a base64-encoded `PaymentRequired` object.
3. The client picks one of the offered `PaymentRequirements` entries and signs a `PaymentPayload`.
4. The client retries the same request, now with a `PAYMENT-SIGNATURE` header.
5. The server verifies the payload locally, or POSTs it to the facilitator's `/verify` endpoint.
6. On successful verification, the server does the actual work.
7. The server settles the payment, either directly on-chain or via the facilitator's `/settle` endpoint.
8. The server returns 200 OK with a `PAYMENT-RESPONSE` header containing a base64-encoded `SettlementResponse`.

```mermaid
sequenceDiagram
    participant C as Client (AI agent)
    participant S as Resource Server
    participant F as Facilitator

    C->>S: GET /resource (no payment)
    S-->>C: 402 Payment Required
PAYMENT-REQUIRED header
    Note over C: Select a PaymentRequirements
entry and sign a PaymentPayload
    C->>S: GET /resource
PAYMENT-SIGNATURE header
    S->>F: POST /verify
    F-->>S: verification result
    Note over S: Perform the requested work
    S->>F: POST /settle
    F-->>S: SettlementResponse
    S-->>C: 200 OK + resource
PAYMENT-RESPONSE header
```

Two details are worth pausing on. First, verification and settlement are separate steps, which means the server can confirm a payment is valid before spending compute, then settle after the work is done. Second, the server can skip the facilitator entirely and verify or settle on its own if it is willing to run that infrastructure.

The error surface is deliberately small. Payment Required maps to 402, Invalid Payment maps to 400, Payment Failed maps to 402, Server Error maps to 500, and Success maps to 200. A client only needs to distinguish "you have not paid yet," "your payment was malformed," and "your payment did not go through."

## The Three x402 Headers

All protocol information travels in headers, not in response bodies. That is a deliberate constraint: it means an x402-enabled endpoint can return whatever body it already returns - JSON, an image, a streamed completion - without the payment layer contaminating the payload schema.

| Header | Direction | Payload |
| --- | --- | --- |
| `PAYMENT-REQUIRED` | Server to client | Base64-encoded `PaymentRequired` object describing accepted payment options |
| `PAYMENT-SIGNATURE` | Client to server | Signed `PaymentPayload` matching one of the offered `PaymentRequirements` |
| `PAYMENT-RESPONSE` | Server to client | Base64-encoded `SettlementResponse` confirming settlement |

Keeping the negotiation in headers is what makes x402 retrofittable. You can put it in front of an existing endpoint without changing the contract that endpoint already has with its non-paying internal callers.

## Inside a 402 Response

The `PaymentRequired` object has a small, fixed shape. `x402Version` must be 2 in v2. `error` is optional and explains why the request was rejected. `resource` is a `ResourceInfo` object describing what is being sold. `accepts` is an array of `PaymentRequirements`, and `extensions` is optional.

Each `PaymentRequirements` entry carries `scheme`, `network` in CAIP-2 format, `amount` as a string in atomic token units, `asset` as either a token contract address or an ISO 4217 code, `payTo`, `maxTimeoutSeconds`, and an optional `extra`.

```json
{
  "x402Version": 2,
  "error": "Payment required to access this resource",
  "resource": {
    "url": "api.example.com/v1/forecast",
    "description": "Single forecast query",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "1000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x1234567890AbcdEF1234567890aBcdef12345678",
      "maxTimeoutSeconds": 60
    }
  ]
}
```

Because `accepts` is an array, a server can advertise several ways to pay at once - different networks, different assets, different schemes - and let the client choose whichever one its wallet and facilitator both support. That negotiation is the closest thing x402 has to a checkout page.

## Payment Schemes and Networks

A scheme defines the semantics of the payment: what "paying" actually means for that transaction. Schemes are intentionally extensible, so the protocol can grow new payment behaviours without a new protocol version.

The first shipped scheme is `exact`: transfer a specific, known amount. That covers the common case where an endpoint has a fixed price per call. On EVM chains, `exact` is implemented with EIP-3009 `transferWithAuthorization`, which enables gasless ERC-20 transfers - the payer signs an authorization rather than submitting and paying for their own transaction. Those signatures follow EIP-712, so a wallet can render the authorization in a human-readable form instead of an opaque hex blob.

A theoretical `upto` scheme would transfer up to a stated maximum based on the resources actually consumed. That maps directly onto LLM inference, where you do not know the token count until generation finishes. Anyone who has built [metered billing on top of a model wrapper](https://dodopayments.com/blogs/metered-billing-gpt-wrapper) will recognise the problem: the price is a function of the output, not the input. There is also a deferred settlement direction in the protocol's design space, where verification and settlement are pulled further apart in time.

On networks, x402 is chain agnostic. Networks are identified in CAIP-2 format, such as `eip155:84532`, and the protocol works across EVM chains and Solana. USDC is the most common asset in practice, but a seller can accept any ERC-20 on EVM or any SPL token on Solana.

One hard constraint governs all of this: the same `(scheme, network)` pair must be supported by both the client and the facilitator. A server can advertise as many combinations as it likes, but a payment only completes when the client's capability and the facilitator's capability overlap. Plan your `accepts` array around that overlap, not around what you wish were supported.

Discovery is handled by a separate layer. A "Bazaar" discovery layer lets buyers find available x402 services rather than requiring every agent to already know which endpoints accept payment. This matters more than it sounds: a payment rail with no directory is a rail that only works between parties who already found each other.

## What a Facilitator Actually Does

Running your own chain infrastructure to accept payments is a real engineering burden. You need RPC access, nonce management, settlement monitoring, and reorg handling. A facilitator exists so a resource server can skip all of that.

The facilitator exposes two endpoints that matter to a seller:

- `/verify` - the server POSTs the client's payment payload and gets back a verdict on whether the payment is valid and will settle.
- `/settle` - the server asks the facilitator to actually execute settlement and returns a `SettlementResponse`.

Splitting verification from settlement is what lets a server safely do expensive work. Verify first, generate the response, settle after. If the work fails, you have not moved funds.

Coinbase Developer Platform runs a hosted facilitator. It supports ERC-20 payments on Base, Polygon, Arbitrum, World, and Solana, using EIP-3009 for USDC and EURC, or Permit2 for any ERC-20. Pricing is a free tier of 1,000 transactions per month, then $0.001 per transaction after that.

That per-transaction cost is the number that makes x402 interesting for micropayments. At a tenth of a cent per settlement, charging a fraction of a cent per API call is arithmetically viable in a way it never is with card rails, where the fixed component of interchange sets a hard floor on the smallest sensible transaction. If you have ever tried to [charge for API access](https://dodopayments.com/blogs/charge-for-api-access) at genuinely small increments, you have run into that floor.

## x402 vs Traditional Card Rails

These are not the same product. Comparing them is useful mainly to clarify which problem each one is actually solving.

| Dimension | x402 | Traditional card rails |
| --- | --- | --- |
| Settlement | On-chain, in stablecoins, near-immediate | Fiat, batched, with a settlement delay |
| Minimum viable payment size | Fractions of a cent | Constrained by a fixed per-transaction fee |
| Chargebacks | No chargeback mechanism | Dispute and chargeback rights for the cardholder |
| Tax handling | Not addressed by the protocol | Handled by the merchant, PSP, or Merchant of Record |
| Counterparty | Can be an autonomous agent with a wallet | Assumes an identified human or business account |
| Best fit | Machine-to-machine per-request payments | Recurring human subscriptions and one-off purchases |

Read that table as a division of labour rather than a scoreboard. Card rails carry consumer protections, tax machinery, and a legal identity for the payer. x402 strips all of that out to get transaction cost low enough that a machine can pay per call. Each trade-off is deliberate.

The broader shift here is what people mean when they talk about [agentic commerce](https://dodopayments.com/blogs/agentic-commerce): software that transacts on its own behalf rather than acting as a front-end for a human's stored credentials. x402 is one concrete attempt at the payment layer for that world, and it sits alongside the wider set of questions about [how billing changes when the buyer is an agent](https://dodopayments.com/blogs/agentic-billing).

## Where x402 Fits in an AI Product's Billing Stack

Here is the part that gets glossed over in most x402 write-ups: an AI product almost never has only one kind of buyer.

You have agents making per-request calls, and you have humans on monthly plans. Those two revenue streams have different requirements and, realistically, need different rails.

x402 handles the first well. Per-request, sub-cent, no onboarding, settles in stablecoins, works between parties who have never met. If your product is an API that other machines consume, that is a strong fit, and it complements a broader [API monetization strategy](https://dodopayments.com/blogs/api-monetization) rather than replacing it.

It does not handle the second at all, and it is not trying to. x402 has nothing to say about:

- Merchant of Record duties and who is the legal seller of record.
- Indirect tax: VAT, GST, and sales tax calculation, collection, and remittance.
- Chargebacks and dispute handling.
- Invoicing and receipts that a finance team can reconcile.
- Fiat payouts into a bank account.

Those are not protocol oversights. They are simply outside the scope of a payment handshake, and they remain your responsibility no matter which rail settles the money.

To be direct about it: Dodo Payments does not implement x402. What we do is the other half of the stack. Dodo Payments is a [Merchant of Record](https://dodopayments.com/payments/merchant-of-record), which means we become the legal seller for your transactions and take on tax compliance across 190+ countries, invoicing, and analytics. Pricing is 4% + 40c per domestic US transaction, +1.5% international, and +0.5% for subscriptions, with no fixed monthly cost. We support 40+ payment methods, 80+ currencies, and 220+ countries and territories.

On the metering side, [usage-based billing](https://dodopayments.com/billing/usage-based-billing) is included, so if your product charges by tokens, calls, or compute rather than by seat, the meter and the invoice live in one place. If you are still deciding on a model, the tradeoffs are covered in our guide to [usage-based billing for SaaS](https://dodopayments.com/blogs/usage-based-billing-saas) and the more hands-on walkthrough of [implementing usage-based billing](https://dodopayments.com/blogs/implement-usage-based-billing).

There is a real adjacency worth naming. Dodo publishes an [MCP server for AI agents](https://docs.dodopayments.com/developer-resources/mcp-server), so agents can interact with billing operations through the same protocol layer they use for everything else, and we ship agent skills for coding agents working against our API. That is protocol-level support for agentic workflows. It is not x402, and we are not going to pretend otherwise.

The honest architecture for most AI companies today is two rails running in parallel: an agent-payment rail like x402 for machine-to-machine micropayments, and a fiat billing rail with Merchant of Record coverage for the humans who pay you every month. Choosing between [AI billing platforms](https://dodopayments.com/blogs/ai-billing-platforms) is really a question about the second rail, not the first.

## Limitations to Understand Before You Build on x402

None of these are reasons to avoid x402. They are the things to have answers for before it reaches production.

**Stablecoin exposure.** Settlement happens in tokens, not fiat. You now hold a stablecoin balance, and you own the conversion, treasury, and accounting workflow that follows. Our [stablecoin payments guide](https://dodopayments.com/blogs/stablecoin-payments-guide) covers the operational side of that, and the [crypto payments for SaaS](https://dodopayments.com/blogs/crypto-saas-payments-2026) piece looks at where it does and does not make sense for software businesses.

**No chargeback mechanism.** Once settled, settled. That is excellent for a seller's revenue certainty and it means you cannot offer a buyer the recourse they would get from a card. For agent-to-agent traffic that is usually fine. For consumer-facing transactions it is a meaningful gap.

**Tax and Merchant of Record duties stay with you.** The protocol moves value. It does not determine where a supply is deemed to take place, calculate the right VAT rate, file a return, or issue a compliant invoice. If you are unclear on what that entails, start with [what a Merchant of Record actually does](https://dodopayments.com/blogs/what-is-a-merchant-of-record).

**Wallet UX.** The client needs a funded wallet and a way to sign. EIP-712 makes the signature legible, which helps, but you are still asking the payer to hold and manage keys. For an autonomous agent that is a solved provisioning problem. For a first-time human customer it is friction that a card checkout does not have.

**Scheme and network support matrix.** Because a payment only works when the client and the facilitator both support the same `(scheme, network)` pair, your advertised `accepts` array is really a bet on which combinations your buyers will have. Advertise too narrowly and you lose payers. Advertise combinations your facilitator cannot settle and you fail at the `/settle` step after doing the work.

**Protocol maturity.** Schemes beyond `exact` are still developing, replay protection and trust minimisation are explicit ongoing concerns in the spec, and the standard is young. Build with the expectation that the surface will change. If you want to keep your own integration adaptable, our [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide) is a reasonable model for isolating a payment rail behind a stable internal interface.

## FAQ

### What is the x402 protocol in simple terms?

x402 is an open payment standard that uses the HTTP 402 "Payment Required" status code to let a client pay for a single request without an account, API key, or subscription. The server responds to an unpaid request with instructions on how to pay, and the client retries with a signed payment attached.

### Do I need a crypto wallet to use x402?

Yes. The client must hold and sign from a wallet with a supported asset, most commonly USDC, on a supported network. This is straightforward for an autonomous agent that you provision, but it is real friction for a first-time human customer compared with entering a card.

### Can x402 replace my existing subscription billing?

No. x402 handles per-request machine-to-machine payments and has no mechanism for subscriptions, invoicing, indirect tax, chargebacks, or fiat payouts. Most AI products run x402 alongside a fiat billing rail rather than instead of one.

### What does an x402 facilitator do?

A facilitator verifies payment payloads through a `/verify` endpoint and executes settlement through a `/settle` endpoint, so the resource server does not have to run its own chain infrastructure. Coinbase Developer Platform operates a hosted facilitator with a free tier of 1,000 transactions per month and $0.001 per transaction after that.

### Does Dodo Payments support the x402 protocol?

Dodo Payments does not implement x402. Dodo Payments is a Merchant of Record that handles fiat payments, tax compliance across 190+ countries, invoicing, and usage-based billing, and it publishes an MCP server so AI agents can work with billing operations directly.

## Final Take

x402 is a clean solution to a specific, real problem: a machine needs to pay for a single request and there is no human in the loop to sign a contract or manage an API key. Reviving HTTP 402, keeping the negotiation entirely in headers, and separating verification from settlement are all sensible engineering decisions. The facilitator model removes most of the infrastructure burden from the seller.

What it is not is a billing system. It moves value between two parties who agreed on an amount. It does not tell you whether you owe VAT in Germany, produce an invoice your customer's finance team will accept, or convert stablecoins into your operating account.

If you are shipping an API that agents consume, x402 is worth prototyping now while the cost per settlement is this low. If you are also selling that product to humans on monthly plans, you still need the other rail underneath it. That is the layer [Dodo Payments](https://dodopayments.com/pricing) handles, and the [developer documentation](https://docs.dodopayments.com) is the fastest way to see how the two fit together.
---
- [More AI articles](https://dodopayments.com/blogs/category/ai)
- [All articles](https://dodopayments.com/blogs)