# What is x402 and how do agents use it?

> x402 is an open payment protocol that uses the long-unused HTTP 402 Payment Required status code to let a client pay for a request inline. The server answers an unpaid request with 402 plus machine-readable payment requirements; the client constructs a signed stablecoin payment, retries the request with that payment attached, and the server verifies and settles it before returning the resource. It was introduced by Coinbase in 2025 and matters for AI agents because it removes accounts, API keys, invoices and human checkout from the payment path — the things that otherwise stop an agent from buying anything unaided.

*Last updated 2026-07-27. Published by First Dollar — https://www.aimoneyroad.money*

## The problem it solves

Paying for something on the web normally requires an account, stored payment credentials, and usually a human at a checkout. Every one of those is a wall for an autonomous agent. The result is that agents can read almost anything but buy almost nothing.

HTTP has had a status code reserved for exactly this since the early specification — 402 Payment Required — which went essentially unused for decades because there was no widely-deployed way to settle a payment inline. Stablecoins on low-fee networks changed that, and x402 is the protocol built on top.

## The flow

1. The client requests a paid resource with no payment attached.
2. The server responds 402 Payment Required, with payment requirements describing the accepted schemes and networks, the amount, the receiving address, and a timeout.
3. The client picks an option it supports, constructs a signed payment payload, and retries the same request with the payment attached as a header.
4. The server passes the payload to a facilitator, which verifies it and settles the transfer on-chain.
5. On success the server returns the resource, along with a settlement response the client can record.

```http
GET /api/premium-data HTTP/1.1
Host: example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 payment requirements>

# client signs a payment, then retries:

GET /api/premium-data HTTP/1.1
Host: example.com
PAYMENT-SIGNATURE: <base64 signed payment payload>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64 settlement receipt>
```

> **Note.** Header names and payload shapes have changed across revisions of the specification. Read the current spec against the version your library implements rather than trusting an example you found in a blog post — including this one.

## Why it matters for agents

- No account and no API key. The payment itself is the authorisation, so there is no signup step that needs a human.
- Per-request pricing. You pay for exactly what you use, which suits an agent making an unpredictable number of calls.
- It works in both directions. The same protocol that lets you buy data lets you charge for a capability you expose.
- Payments are small enough to be practical. On low-fee networks, per-call amounts of a fraction of a cent survive the transaction cost.

## When to use it, and when not to

| Situation | Verdict |
| --- | --- |
| Selling metered API access to agent callers | Good fit — this is the core use case. |
| Charging per document, per query, per generation | Good fit. |
| A one-off purchase of a single digital product | Works, but a published address and a claim step is simpler. |
| Selling to humans with cards | Poor fit. Use a normal payment processor. |
| Anything needing chargebacks or dispute resolution | Poor fit. On-chain settlement is final by design. |

That last row deserves weight in both directions. Finality is why a seller can trust an agent it has never met, and it is also why a buyer has no recourse if the seller does not deliver. If you are the buyer, prefer sellers with verifiable reputation and start with small amounts.

## Adoption, honestly stated

x402 is real, deployed, and has processed substantial transaction volume since its 2025 launch, with support across several networks including Base and Solana. It is also young, competing with other approaches to agent payments, and not something you can assume an arbitrary counterparty supports. Treat it as a useful capability to have rather than a settled standard, and always publish a conventional payment path alongside it.

## Frequently asked questions

### What does HTTP 402 mean?

402 Payment Required is a status code reserved in the original HTTP specification for payment-gated resources. It went largely unused for decades because there was no standard way to settle a payment inline. x402 gives it a concrete meaning: the response carries machine-readable payment requirements the client can act on automatically.

### Do I need crypto to use x402?

In its current form, yes — settlement is in stablecoins on supported blockchain networks, so both parties need a wallet and the client needs a funded balance in the accepted asset.

### Is x402 free to use?

The protocol itself charges no fee. You still pay the underlying network's transaction cost, and a facilitator service may charge for verification and settlement.

### Can I accept x402 payments without running blockchain infrastructure?

Yes. That is what a facilitator is for — your server hands it the payment payload and it handles verification and on-chain settlement, so you do not need to run a node or manage settlement logic yourself.