AI agents have started to spend money. On 29 July 2026, MoonPay launched PayBox, which lets agents execute crypto payments on a user's behalf, and it is one signal of a wider shift: software that acts on its own now needs a way to pay for the services it calls. The problem is that the web was built for humans with credit cards and login screens, not for autonomous programs. x402 is the pattern closing that gap, and it does it by reviving an HTTP status code that has sat unused for decades.
Why agents cannot use your current billing
Think about how a customer reaches a paid API today. A person signs up, confirms an email, adds a card, waits for approval, and copies an API key into their code. Every step assumes a human with an identity, a payment method, and patience.
An AI agent has none of that. It cannot fill in a signup form with a real name, it cannot hold a credit card, and it should not be trusted with a long-lived secret key that it might leak or misuse. When an agent needs to call ten APIs it has never seen before to finish a task, the human-onboarding model breaks down completely. You cannot ask a founder to pre-register their agent on every service it might ever touch.
What agents need is machine-native payment: the ability to discover a price, pay it, and get a result in a single automated exchange, with no account and no stored credential. That is exactly what x402 provides.
What x402 actually is
The HTTP specification has always reserved status code 402 for "Payment Required." For years it was a placeholder, defined but effectively unused, because there was no standard, low-friction way for a server to charge a client mid-request. x402 puts that code to work.
The idea is simple. When an agent calls a protected endpoint without paying, your server does not return the data. It returns HTTP 402 Payment Required along with a machine-readable challenge that says, in effect, "this costs a set amount, pay it to this address on this network, then try again." The agent pays on-chain in stablecoin, retries with proof of payment, and receives the response. No account, no dashboard, no key.
How a paid request flows
Here is the full round trip, step by step:
- The agent makes a normal request to your endpoint with no payment attached.
- Your server responds with HTTP 402 Payment Required. The response carries a challenge: the price, the accepted token and network, the destination address, and a unique invoice reference.
- The agent reads the challenge and pays on-chain, sending the stablecoin amount to the address named in the challenge.
- The agent retries the same request, this time attaching proof of payment (a signed authorization or a transaction reference) in a request header.
- A facilitator, or your own server, verifies that proof against the challenge, confirming the right amount reached the right address.
- Your server returns the real response, the data the agent asked for, now that payment has settled.
A minimal exchange looks like this:
GET /v1/forecast?city=lagos HTTP/1.1
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"price": "0.01",
"asset": "USDC",
"network": "base",
"payTo": "0xA1b2...c3D4",
"invoice": "inv_7fa9"
}
The agent pays, then repeats the request with an X-Payment header carrying the proof, and the server answers 200 with the forecast. The whole loop can complete in seconds and needs no human in the middle.
The facilitator: who settles the payment
You could verify every payment yourself, but most teams do not want to run chain infrastructure, watch for confirmations, and guard against double spends. That is the job of a facilitator, a settlement layer that sits between your API and the blockchain.
The facilitator does the awkward parts: it validates the payment proof, confirms the funds moved, handles the on-chain settlement, and hands your server a clean yes or no. Your API stays close to stateless. It issues a challenge, asks the facilitator to verify, and serves the response. You keep your business logic; the facilitator absorbs the payment plumbing, which is where settlement, refunds, and chain edge cases would otherwise cost you weeks.
Stablecoin rails: USDC on Base and Solana
Agents pay in stablecoins because a call that costs a fraction of a cent cannot ride on a volatile asset or a slow, expensive chain. USDC is the common choice, and the networks that matter are the fast, cheap ones: Base and Solana. Both settle in well under a second of practical finality for these amounts, and fees are small enough that charging a tenth of a cent per call actually makes sense.
That combination, a dollar-pegged token on a low-fee network, is what makes per-call pricing viable. On a slow or costly chain, the fee would dwarf the price of the call and the whole model would collapse.
Pricing models: per call, per token, per compute
x402 does not lock you into one price shape. The challenge you return is just a number, so you can meter however your service actually costs you:
- Per call. A flat price for each request. Simplest to reason about, and a good default for lookups, data endpoints, and predictable operations.
- Per token. For language and generation endpoints, price the response by the tokens it produces. The agent may pay a deposit up front and settle the exact amount once the work is done.
- Per compute. For heavy jobs (rendering, inference on large models, batch processing), price by the resources consumed, so a big request costs more than a small one.
The right model mirrors your own cost curve. If output size drives your bill, meter by output; if every call costs about the same, a flat per-call price keeps things clean.
x402 vs API keys and monthly billing
x402 does not replace subscriptions everywhere. It wins where the old model is weakest: unknown callers, one-off usage, and machine traffic that will never create an account.
| API keys + subscription | x402 pay-per-call | |
|---|---|---|
| Onboarding | Human signs up, gets a key | None; the agent just calls the endpoint |
| Billing | Monthly invoice or prepaid credits | Settled per request in stablecoin |
| Credential to manage | Long-lived secret key | No stored secret; proof per call |
| Best fit | Steady, known consumers | Unknown, one-off, or machine callers |
| Revenue capture | Misses casual and automated traffic | Captures value from every call |
| Main downside | Key leaks, seat sprawl, unused credits | Wallet setup, on-chain fees |
A healthy API can run both. Keep subscriptions for your enterprise accounts and offer an x402 endpoint for the long tail of agents and casual callers you would otherwise never bill at all.
A practical integration checklist
If you want to add x402 to an existing API, this is the shape of the work:
- Pick the endpoints to meter. Start with the high-value or high-cost routes, not everything at once.
- Choose your rails. Decide on the stablecoin and network (commonly USDC on Base or Solana) and set up a receiving wallet.
- Define the challenge. Settle on your price per route and the exact fields your 402 response returns.
- Add the 402 middleware. Intercept unpaid requests, return the challenge, and let paid requests through.
- Wire up a facilitator. Use a settlement layer to verify proofs and confirm funds, so your API stays simple.
- Set pricing logic. Implement per-call, per-token, or per-compute metering to match your costs.
- Handle the edge cases. Underpayment, retries, expired invoices, and refunds all need defined behavior.
- Log and reconcile. Record every challenge, payment, and settlement so your books match the chain.
If you are weighing the broader design, we cover the surrounding patterns in AI agent payment systems, paid MCP tools, and metered API billing with crypto.
How we build this at Anointed Coder
We integrate x402 and agent payment rails into APIs, both new builds and existing services that need a machine-native way to charge. The work usually spans two of our practices: API integration services for the metering, middleware, and reconciliation, and blockchain development for the stablecoin settlement, wallet handling, and facilitator setup. When the API is part of a larger product, SaaS and fintech development ties the billing into the rest of the system.
We run engagements in milestones, so you fund the next block of work only after you have reviewed the last one. You get a weekly staging environment to test against real flows, not a black box that appears at the end. You own the complete source at every step, with no lock-in and no dependency on us to keep it running.
If you are ready to let agents pay for what your API does, reach us through contact us or WhatsApp, and we will scope the smallest useful first milestone.
The short version
x402 turns the long-dormant HTTP 402 Payment Required status into a working payment layer for machines. An agent calls your endpoint, gets a 402 challenge with a price and a destination, pays on-chain in stablecoin, retries with proof, and gets the response, all with no account and no stored key. A facilitator handles settlement, USDC on Base or Solana keeps fees tiny, and you can meter per call, per token, or per compute. It does not replace subscriptions; it captures the traffic subscriptions miss. As agents start spending on their own, the APIs that can accept a payment mid-request are the ones that get used, and paid.