x402: The paywall handshake that lets agents pay the web

Breaking: agents can now see a price tag

This week, a set of live demos showed something many builders have been asking for. When an artificial intelligence agent requests a page or an application programming interface call and the server wants to charge for it, the server replies with Hypertext Transfer Protocol status 402, Payment Required, along with a small, machine readable offer. The agent reads the offer, checks the price and the license, pays for the scope of access it needs, receives a signed receipt, then retries the request and gets the content. No scraping, no mystery paywalls, no human typed checkout.

People are calling the emerging pattern x402. It is not a monolithic standard, it is a simple handshake built around a status code the web has had for decades and never quite used. What is new is the focus on agents, the inclusion of clear license terms, and the pragmatic attention to receipts and budgets. It turns a blocked request into a conversation about price and permission.

If you have ever watched an agent bump into a subscribe wall, you know why this matters. The agent does not understand what it is allowed to do, it cannot attach a card, and it has no memory of what it already paid for. The result is either brittle workarounds or a full stop. x402 gives agents a way to ask, how much, for what, and for how long.

What x402 is, in plain English

x402 is a convention for what a server includes when it answers with Payment Required and what a client sends back after it pays. You can think of it as a storefront window for machines. The server lists a price and a policy. The client shows a wallet and a budget. They meet in the middle with a receipt.

Under the hood, the server uses Hypertext Transfer Protocol status 402 as a signal that says, you can get this if you pay, here are the terms. The 402 response includes a small JavaScript Object Notation body with a few fields:

An offer identifier, so the server knows which terms the client accepted
A clear price, currency, and any volume discount
A scope, which names the resource, the allowed uses, and the duration
One or more payment methods, with a place to send the payment
A suggested receipt format, along with a short expiry and a nonce to prevent replay

The client, which can be a browser, a phone app, or an artificial intelligence agent framework, reads this offer. If it agrees and has budget, it sends money using a supported rail and receives a signed receipt. That receipt can be a token or a short license document the server can verify quickly. The client retries the original request, now including the receipt in a header such as Authorization or a dedicated x402 header. The server verifies the receipt and returns the content.

It is a clean, two step dance. The first response says here is the menu. The second request says here is the check, please bring the dish.

A quick refresher on Payment Required

Hypertext Transfer Protocol status 402, Payment Required, has been in the specification since the early days but was mostly reserved for future use. The web grew up with subscriptions, paywalls, and cookies. Machines, however, do not like browser popups and full screen interstitials. 402 is a natural fit for agents because it is already part of the request response life cycle. x402 leans into that by making the 402 body predictable for machines and the follow up predictable for servers.

What the “x” adds

The “x” in x402 is not branding, it is a reminder that this is a profile, not a reinvention of the web. The additions are practical:

A compact, standard offer schema in the response body
Consistent headers for receipts in follow up requests
An explicit license field that states what the client is allowed to do
Tight time windows, nonce values, and deterministic verification to keep it safe and fast
A place for a client identifier that does not reveal a person but still lets the server rate limit and audit

The result is a protocol that feels boring in the best way. It is a price tag and a store receipt, formatted for machines.

Why agents need it

Humans can decide to subscribe, explore a trial, or ignore a paywall. Agents need rules. Without a machine readable offer, agents either skip content entirely or they scrape content they are not allowed to use. Both outcomes are bad. Publishers do not get paid. Users do not get what they asked for. Everyone spends time on brittle workarounds.

x402 gives agents three things they were missing:

Price clarity. An agent can compare offers and pick the cheapest way to accomplish a task, just like a human shopper.
License clarity. The agent knows if it can quote, summarize, remix, or train on the material, and for how long.
Accountability. The agent keeps receipts tied to specific tasks and can explain spend after the fact.

For builders, this means a new primitive. You can now write agent code that says, get me the cheapest verified source that allows quotation, with a price cap of ten cents, and if nothing matches, ask the user.

A real world walk through

Imagine you ask an assistant to plan a weekend in Kyoto. The assistant needs to read a few travel guides, check train times, pull a restaurant list, and create a walking map. Today, that involves a mixture of free sites, subscription walls, and terms that say no automated access. Here is how the same request might run with x402.

The assistant requests a guide article about Kyoto neighborhoods. The server returns Payment Required with an x402 offer: three cents to read and quote up to two hundred words for twenty four hours, no training use, retries allowed for one hour.
The assistant checks your budget policy. You have set a cap of two dollars for travel planning, with a per site limit of twenty cents. Three cents is fine, and the license allows quotation. The assistant pays, receives a receipt, retries the request, and gets the article text.
The assistant requests train schedules from a timetable service. That service is free for human browsing but charges one cent per query for automated access. It responds with an x402 offer. The assistant bundles five queries into one payment and proceeds.
The assistant requests restaurant listings from a local magazine. That publisher offers a five cent fee for a structured list of open hours and addresses for a single district, with a license that allows remixing the data but not reproduction of full reviews. The assistant pays, fetches, and caches the result for the duration of the license.
The assistant generates your itinerary with quotes and links, plus a small spend report that shows where the ten cents went, with receipts attached.

The important part is not the pennies. It is the structure. The agent never had to guess, and the publishers never had to choose between being scraped or being invisible to machines.

The moving parts

x402 is simple, but real systems need a few supporting pieces.

Identity for machines. Servers want to know that a repeat request is actually the same client, without fingerprinting a person. The x402 offer can include a request for a client identifier issued by a wallet or platform. Think of it as a pseudonym that carries spending limits and anti abuse checks.
Wallets and rails. The client needs a way to move small amounts quickly and cheaply. This can be card on file with batched settlement, a network that supports micro amounts, or credits managed by a platform. The point is not the rail, it is the speed and the cost relative to the price.
Budgets and policies. Users must be able to say, spend up to five dollars this week on news, never more than ten cents per site, and ask me if a single request will cost more than twenty five cents. Agents enforce these policies automatically.
Receipts and caching. A receipt is a compact proof that the client paid for a specific scope. The client should remember receipts and reuse them until they expire. Servers should accept valid receipts without extra checks.
License vocabulary. The offer should include simple, testable terms such as read only, quote up to N characters, no training, no redistribution, derivative allowed or not. Lawyers can write long terms. Agents need yes or no flags.

Here is a sketch of a 402 response body in JavaScript Object Notation that shows the idea:

{
  "offer_id": "guides-kyoto-2025-04-12-1",
  "price": { "amount": "0.03", "currency": "USD" },
  "scope": {
    "resource": "/guides/kyoto/neighborhoods",
    "duration_seconds": 86400,
    "allow": { "read": true, "quote_chars": 200, "train": false, "redistribute": false }
  },
  "payment": {
    "methods": ["card_batch", "wallet_token"],
    "pay_url": "https://pay.publisher.example/checkout",
    "nonce": "J8Zfx...",
    "expiry": "2025-09-16T12:00:00Z"
  },
  "receipt_format": "x402-r1"
}

And here is a follow up header a client might send after paying:

Authorization: X402 receipt="eyJhbGciOi...", offer="guides-kyoto-2025-04-12-1"

The details will vary by implementation. What matters is that both sides know where to look.

Safety rails and policy questions

New power needs guardrails. x402 raises design choices for security, privacy, and fairness.

Consent. Users must control whether agents can spend, on what, and how much. Good defaults matter. Start with zero spend, ask for permission with clear numbers, let users change their mind later.
Transparency. Every agent task that spends should produce a short log that explains what was bought, for how much, and why. Logs should be easy to export and audit.
Price caps. Agents should refuse offers above a set limit unless a user approves. Servers should include a clear unit price and avoid surprise add ons.
Abuse and fraud. Attackers could flood a client with fake 402 offers or try to drain a budget. Clients should only consider offers from the server that holds the content, and should verify pay endpoints against known trust roots. Wallets should enforce rate limits and daily caps.
Privacy. A naive wallet leaks identity. Use privacy preserving tokens where possible, such as blind signatures or group credentials that prove spend limits without exposing a person. Keep receipts scoped and short lived.
Fair access. Small publishers may rely on agents for traffic and revenue. Large platforms could try to dictate terms. An open, simple protocol reduces lock in. It makes it easier for small players to participate without joining a proprietary program.

None of this is hypothetical. It is the same set of issues we dealt with in web payments and subscriptions, tuned for machines that act on a person’s behalf.

How to try it today

If you run a site or a service, you can experiment with x402 with a weekend of work.

Server side steps:

Identify a resource that agents often hit but you would like to meter, such as a structured feed or full text view.
Add a branch in your request handler. If the client does not present a valid receipt, return status 402 with an x402 offer body.
Set a small, sensible price and a tight scope. Example, one cent for a structured list of the ten most recent items, no training, valid for one hour.
Integrate a simple pay method. If you already run on a platform, you can create one time tokens and settle in batches. Keep fees below the price.
After payment, issue a signed receipt that binds the offer identifier, the scope, the client pseudonym, and an expiry. Use a signature that can be verified without a database lookup.
Accept follow up requests that present a valid receipt. Log usage for audits.

Client side steps:

Build a budget manager that sits in front of your network library. It reads 402 offers and decides to pay, ask, or decline.
Keep a receipt cache keyed by resource and scope. Only pay when you have to.
Enforce user policies. For example, never pay for sites not on an allow list, or never pay for training rights.
Send a clear spend report with task outputs. If your agent wrote a memo, include a line item list of what it bought to write it.

This is enough to unlock value. You do not need to wait for a committee. You can ship a demo that pays a cent for a high quality chart or a verified data point and shows the receipt.

The economics of tiny payments

Micropayments have a long history of hype and disappointment, usually for human use. The novelty here is not asking people to click a two cent pay button. It is letting agents make dozens of tiny, purposeful purchases that sum to a worthwhile outcome.

The keys to making that economical are simple:

Batch where possible. One payment can cover multiple requests if the scope allows it.
Keep verification cheap. Receipts should be easy to check without hitting a database on every request.
Be realistic about price. If the transaction cost is one cent, do not set a price of half a cent. Start at a few cents and see how demand responds.
Offer tiers. Free for human browsing, metered for automated use, subscription for heavy users. Let agents choose what fits the task.

If this works, we will see a new class of inventory. Not subscriptions, not ads, but specific slices of content and capability that agents can buy on demand.

Failure modes to anticipate

No system is perfect. Here are the obvious ways x402 can go wrong, and how to blunt them.

Dark patterns. A server could present a low price for a narrow scope, then immediately force a second payment. Clients should track effective cost per useful result and down rank bad actors.
Fragmentation. If every site invents its own fields, agents will not understand them. Stick to a small core vocabulary for early pilots, and push bespoke details into free form text that humans can read.
Paywall loops. A misconfiguration could cause infinite 402 redirects. Clients should stop after one unsuccessful attempt and report the loop.
Privacy leaks. If a receipt carries a stable identifier across sites, it can be used for tracking. Keep identifiers local to a site or a payment provider, and rotate often.
Overreach. Do not 402 everything. Leave humans a path to browse, and leave basic facts free. Use 402 for high value slices that cost money to produce.

What this means for people

For people who use agents, x402 is a safety feature. It turns invisible scraping into accountable spending. It turns vague terms into explicit permissions. It gives you a dial to set how much you are comfortable paying to get better answers.

For people who publish or host services, x402 is a new revenue path that does not require joining a single platform or redesigning your site. You can expose a price and a license in the place where machines already listen, the protocol itself. You can meter, experiment, and tune.

For people who set policy, x402 is a lever. It allows machine readable licensing that can encode rights like no training or quota limits. It also creates logs that can be audited. None of this replaces copyright or contract law, but it makes compliance tractable for machines.

Clear takeaways

x402 turns Payment Required into a machine readable offer and a receipt, which lets agents pay for specific access safely.
The win is not the price, it is the clarity. Agents know what they can do, publishers know what was granted.
You can pilot this now with a simple offer body, a receipt, and a budget manager. Start small, keep fees below price, and log everything.
Design for people first. Budgets, consent prompts, and spend reports make this trustworthy.
Expect rough edges. Use a small set of fields, protect privacy, and measure effective cost per useful result.

What to watch next

Will major agent platforms ship built in budget managers and receipt caches that speak x402 by default
Will large publishers and service providers expose x402 offers for automated access alongside human subscriptions
Will browser teams add wallet support that is private by design, so agents on devices can pay without leaking identity
Will standards bodies converge on a shared offer and receipt schema, or will the market find a de facto core
Will regulators encourage machine readable license fields that make fair use and training rights testable at request time

The web grew up around people holding the mouse. x402 is a small but meaningful step toward a web where your software can ask for a price, agree to a license, and bring back exactly what you asked for, with a receipt you can understand.