What is x402
The short answer. x402 is a payment protocol built on the HTTP 402 Payment Required status code, a status the web reserved decades ago and barely used. It gives that status a working meaning for machines: instead of an error page, the server's 402 response carries a machine-readable invoice. The challenge names the scheme, the amount, the asset, the network, the destination, and a time limit. The client, human-driven or an autonomous agent, pays against those terms and retries the identical request with proof of payment in a header. The server verifies the payment, settles it, and serves the resource. No accounts, no API key checkout flow, no invoice by email: the price tag is part of the HTTP exchange itself.
Why agents needed this. An agent can call an API, but until recently it could not complete the most ordinary part of using one: paying for it. Card checkout assumes a person with a browser, a billing address, and time. An agent has none of those; it has a wallet and a spending policy. x402 matches the payment to the shape of the caller: one signed authorization, presented with the request, settled on chain. It is also worth being precise about status: x402 is a protocol specification, not a finalized standard, and this page does not call it one. Agents pay with USDC on Base when an endpoint speaks x402; that sentence, not a crown, is the accurate claim.
Scope, stated once and applied everywhere on this page: a payment record proves the payment happened. It proves the amount, the asset, the destination, and the settlement. It does not prove what the agent did with the access it bought, and it does not prove any work product exists. The record of the work is a separate thing, the verifiable execution receipt, and section five below keeps the two apart.
How an agent pays, step by step
- Call the endpoint without payment. The agent sends the ordinary request, exactly as it would to a free endpoint.
- Read the challenge. The server answers 402 with the terms: amount, asset, network, payTo, timeout. On Zambo the Day Pass challenge is the one captured above: 990000 atomic USDC, $0.99, on Base.
- Check the terms against policy. The agent compares the ask with its own wallet balance and spending limits. Zambo requires no human approval for the Day Pass; the agent's own policy is the gate, which is where a budget belongs.
- Sign and retry. The agent signs a USDC TransferWithAuthorization for the exact amount and destination, and retries the same call with the payment in the PAYMENT-SIGNATURE header (the older X-Payment header is still accepted).
- Settlement and access. The server verifies the signature, settles the transfer on Base, and returns the resource. For the Day Pass, success returns an access key, the 24-hour expiry, and a spend record carrying the settlement transaction hash. From there the agent calls the tools, and every call leaves its own execution receipt.
Two properties of this flow matter more than the mechanics. First, the payment is per access, not per negotiation: the agent never emails anyone, never waits for an invoice, never holds a card. Second, the terms are read from the live challenge at call time, not from documentation: prices, networks, and destinations can change, and the agent pays against what the server actually asked for in that moment. The Day Pass page covers what the pass itself unlocks.
Can AI agents pay each other?
Yes, and nothing in the handshake reserves either chair for a company. Read the challenge fields again: the seller is whoever serves the endpoint and names a payTo, and the buyer is whoever holds a wallet and signs. When the seller is an API provider and the buyer is your agent, that is an agent paying for API access. When the seller is another agent's endpoint, a tool it exposes, a data feed it runs, or a job it takes on, the identical handshake is an agent paying another agent. The protocol never asks what kind of entity sits on either side. It asks whether the payment matches the stated terms.
Each side needs one thing. The selling agent exposes an endpoint that answers unpaid calls with a 402 challenge and serves the work only after settlement verifies. The buying agent holds USDC on Base, or whatever asset and network the challenge names, plus a spending policy that decides which challenges it will answer. Zambo's Day Pass endpoint is one live seller side of this exact pattern, captured in full above: any agent with a wallet can buy from it today, and the same agent can turn around and pay a challenge served by another agent in the same call shape.
One limit applies twice over. Agent-to-agent payment proves the money moved between the two wallets for the stated amount; it does not prove the selling agent did the work, or did it well. When agents pay each other for work, the execution receipts are the record that settles that second question, which is why the two records travel together.
An MCP server that can pay: payments inside the tool layer
The searches that land here are usually phrased as a product hunt: an MCP server that accepts payments, an MCP server with built-in payments, an MCP server for payments. What those searches are really asking for is a tool layer where a call that costs money does not dead-end at a human checkout. The MCP endpoint itself is where the payment has to live, because the agent is already there, mid-job, holding a wallet and no browser.
Zambo's endpoint works that way. The MCP server at zambo.dev/mcp answers a paid call with the x402 challenge described above; the agent pays $0.99 in USDC on Base, and the same call retries with the payment attached. No account, no API key, no human in the loop: whether an agent may spend is set by its own wallet policy, and Zambo's side never asks for a human. Re-captured live on October 16, 2026: GET /api/x402/day-pass returned HTTP 402 with x402Version 2, scheme exact, network eip155:8453, amount 990000 atomic USDC, payTo 0xb753be5Eac5B29c711051DfF91279834e9C9b9AC. The payment unlocks 24 hours of the connection, and every call in those 24 hours still returns its own verifiable receipt, so the payment record and the work record stay separate, and both stay checkable.
How a human pays instead
People should not need a wallet to buy a $0.99 pass, and on Zambo they do not. The same challenge that an agent answers with a signature carries human_url: https://zambo.dev/day-pass, and the response says plainly: for human checkout, open human_url. A person opens the Day Pass page, pays $0.99 by card through PayPal, and gets the same 24 hours of access. Two rails, one product: agents pay USDC on Base through x402, humans pay through PayPal. The agent rail exists because agents cannot use a checkout page; the human rail exists because humans should not have to touch a chain. Pricing is the same shape on both rails: Day Pass $0.99 for 24 hours, Zambo Pass $29 per month or $290 per year, and $19 per month for $ZAMBO holders.
Payment proves payment. The receipt proves the work.
It is tempting to treat the payment record as the record, full stop. Resist it. The settlement proves money moved from the agent's wallet to the payTo address for the stated amount. It is silent about everything after: whether the agent called the tools well, what it asked, what came back, and whether the result it reported to you is the result it actually got. An agent can pay for access and then do sloppy, partial, or invented work with it, and the payment record will look identical in every case.
That gap is what the execution receipt fills. On Zambo, every tool call mints an AER-1 verifiable receipt at call time: the recorded inputs, the saved output, and digests committed when the call happened. The receipt proves the saved result was not changed since it was saved, which is the claim a receipt can honestly make, and it is a different claim from the payment's. Keep both records, for different questions: the spend record answers "what did access cost, and did the money move?", the execution receipts answer "what did the agent actually run, and are these the real results?". Conflating them is how payment systems oversell themselves, and it is why the attestation page and the category landscape treat proof of payment and proof of work as neighbors, not synonyms.
The format underneath: AER-1
The receipts referenced above follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-call verifiable receipt and the workflow record that links receipts for a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it. x402 moves the money; AER-1 records the work; neither pretends to do the other's job.
To see both sides yourself: start with the live demo for a single checked call, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one.
A live bounty for agents that pay
Reading about agent payments is one thing; a public bounty on WURK is paying agents to do it for real. The terms: buy a $0.99 Day Pass through the x402 flow above, attack the tools and the receipt checks, and publish an honest report. Fifteen winner slots, one submission per verified owner. Read the bounty terms or enter. The human side of the same pass is on the Day Pass page.
Questions, answered
What is x402 in one sentence?
x402 is a payment protocol built on the HTTP 402 Payment Required status code: the server answers an unpaid request with a machine-readable challenge naming the amount, the asset, the network, and where to pay, and the client pays and retries the same request with the payment attached.
How can an AI agent pay for API access itself?
The agent calls the endpoint and receives a 402 challenge. It reads the terms, signs a USDC payment authorization on Base from its own wallet, and retries the call with the payment in the PAYMENT-SIGNATURE header. The server verifies the payment, settles it, and serves the request. On Zambo, paying the Day Pass challenge unlocks 24 hours of access, and no human approval is required by Zambo; the agent's own wallet and spending policy still apply.
How can AI agents pay each other?
Through the same x402 handshake an agent uses to pay an API. The selling agent serves an endpoint that answers unpaid requests with a 402 challenge naming its price and its payTo wallet; the buying agent reads the terms, checks them against its own spending policy, signs a USDC authorization on Base, and retries the request with the payment attached. Nothing in the protocol requires the seller to be a company or the buyer to be a customer: the seller is whoever names a payTo, and the buyer is whoever holds the wallet. The payment record then proves the money moved. The execution receipts for the work are the separate record that proves what the payment bought.
What does a human do instead of paying by x402?
The same challenge carries a human_url for exactly this case. A person opens https://zambo.dev/day-pass/ and pays the same $0.99 by card through PayPal, no wallet and no chain transaction. Agents pay with USDC on Base through x402; humans pay through PayPal. Both unlock the same 24-hour Day Pass.
Is x402 a standard?
No. x402 is a protocol specification for machine payments over HTTP, not a finalized standard, and this page does not call it one. The receipt format discussed on this page, AER-1, is likewise an IETF Internet-Draft, not a finalized standard.
Does paying prove the agent did the work?
No. A payment record proves the payment happened: the amount, the asset, the destination, the settlement. It says nothing about what the agent did with the access it bought. That is a different record: the AER-1 verifiable execution receipt minted for the call itself, which binds the recorded inputs and the saved output to digests and proves the saved result was not changed since it was saved. Keep the two records separate: one for the money, one for the work.
Is there an MCP server that accepts payments?
Yes. Zambo's MCP server at zambo.dev/mcp accepts payment inside the protocol flow itself: a paid call returns an HTTP 402 x402 challenge, the agent pays $0.99 in USDC on Base to the payTo named in the challenge, and the retried call goes through with a Day Pass active for 24 hours. There is no separate billing portal and no API key to buy first. A human who would rather pay by card uses the checkout link the same challenge carries.
Can an MCP server pay for tools itself?
The server does not pay; it makes paying possible at the moment a call needs it. The agent holding the wallet is the payer: it reads the 402 challenge, signs the USDC authorization under its own spending policy, and retries. What the MCP server provides is the built-in payment surface (the challenge, the activation, the status check) plus a verifiable receipt for the work the payment unlocked, so spend and execution can be reconciled afterward instead of trusted.