Disclaimers:
The views and opinions expressed in this article or video are my own in an individual capacity and do not reflect views or opinions of my current or previous employers.
This article is intended as a high level overview to help busy payments professionals gain an understanding of the protocol quickly. Check these resources for a deeper dive into the protocol: Coinbase, x402.org, Github.
HTTP Status Codes
You’ve probably seen “https://” in your internet browser at some point. The HTTP part is Hypertext Transfer Protocol, the core communication protocol of the web. It defines how a “client” i.e. such as a browser, mobile app, API client, or AI agent, requests information or actions from a server, and how that server responds. A server can also be a client.
A critical component of HTTP is its status codes, some of which you might have also seen if you’ve used the internet long enough. The infamous 500 (Internal Server Error); 404 (Not found), 200 (OK) and 400 (Bad request) are common examples of the 64 HTTP status codes that exist today. They are sent by the server in its response, and tell the client in a standardised way what happened to its request. In case it isn’t obvious, codes like this make it easy for machines/programming to react to specific scenarios. If the code is 200, then do this (show success banner), if the code is 500, then do that (show sad emoji).
A lesser-known HTTP status code, 402 (Payment Required) was defined and reserved for future use in HTTP’s first standardisation in 1997. It envisioned a scenario where a server would require payment in some form, before giving a client access to a resource. However, the web didn’t adopt this status code, leaving it largely dormant.
Coinbase appears to be the first major industry-backed attempt to turn HTTP 402 into a widely adopted, developer-facing payment protocol.
An x402 Payment, Step by Step
x402 is an open protocol by Coinbase that operationalises the 402 Payment Required HTTP Status Code, for internet-native, machine-readable payments. Let’s see how it works step by step with an example of an AI agent client trying to access a premium PDF report.
1. Initial Request
Client sends a standard HTTP request to a server requesting paid-for Premium PDF report via the report’s URL.
2. 402 Response
Server returns HTTP status 402 response with a Payment-Required header. In this header is an encoded payload with details of how to make payment to access the PDF. The structure of the payload and the payment details is defined by the x402 protocol. Here’s a snippet.
{
"x402Version": 2,
"resource": {
"url": "https://api.example.com/premium-report"
},
...
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"amount": "10000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"extra": {
"name": "USDC",
"version": "2"
}
}
]
...
}As of this writing, the most mature and common x402 implementations are crypto/stablecoin focused, especially around USDC-style flows. These details might not be familiar for those purely in traditional Fintech so I’ve included comparable equivalents. Think of the details like a machine-readable payment request or digital invoice. It specifies:
Asset & Amount: What ‘currency’ is required (e.g., USD, USDC, USDT, BTC) and the exact micro-value expressed in lower minor units.
payTo: The recipient’s (merchant) destination payment address (similar to a bank account number or IBAN).
The Network: The rails being used (similar to SEPA, FedNow, or a card network).
3. Authorising Payment
Client chooses one of the available payment options specified in the “accepts” block in step 2. The Client then generates a payment authorisation payload for that specific payment option, based on the provided recipient payment details… and cryptographically signs it.
4. Re-requesting with Payment Proof
Client encodes the payment authorisation payload and makes a new HTTP request to the server requesting for the premium PDF. This request is identical to the one in step 1, but this time with the base64 encoded payment authorisation payload (from step 3) in the PAYMENT-SIGNATURE header.
5. Server Handles Request
The server (merchant) receives the new request and verifies the payment authorisation in the signature header. To reduce infrastructure overhead, the server can optionally pass this payload to a non-custodial third party called a Facilitator. However, the merchant itself is entirely capable of building out capability to verify and settle stablecoin payments directly.
6. Facilitator Verifies Payment
The Facilitator functions similarly to a PSP-like infrastructure layer, but it is narrower than a traditional card PSP/acquirer. It verifies the payment authorisation and can help settle, but it does not necessarily custody funds, underwrite merchants, manage chargebacks, or connect to card schemes.
7. Access Granted
Once the payment is validated, the server immediately returns an HTTP 200 OK status code and delivers the requested premium content back to the client. The value exchange is complete in seconds, entirely machine-to-machine.
Commerce in an AI Agent Economy
You can see how Coinbase with this Protocol is positioning itself for a world in which AI agents autonomously interact and transact with other AI agents.
By upgrading the web’s foundational communication layer rather than stacking more software on top of legacy banking networks, protocols like this show us what a friction-free, machine-executable economy may look like.
For example, an AI Agent trained and fine-tuned on translating and converting imagery of Egyptian hieroglyphs to their English text equivalent could offer its services on the web to other AI agents for $0.0001 per megabyte of imagery or API call. An educational AI agent used by a student doing a paper on African writing scripts could interact with the hieroglyph-expert agent and exchange value through a series of micropayments of under $0.10 upon every usage.
Let’s see how this exact scenario would play out on x402 versus typical e-commerce
x402 + Stablecoins vs Traditional eCommerce
In a traditional e-commerce or API monetisation setup, the hieroglyph-expert service would likely create a paywall, pricing page, account system, API key flow, and card or bank payment integration through a PSP. The student or their software would sign up, choose a plan, enter payment details, possibly complete a 3DS challenge, and receive API credentials. The merchant would rely on its PSP/acquirer stack for payment acceptance, authorization, settlement, reporting, and dispute handling. Settlement may take one or more business days, and card-style chargebacks remain part of the operating model.
In an x402 + stablecoin model, the student could give their AI agent software a wallet, USDC balance, and spending rules. When the agent needs the hieroglyph translation service, it requests the resource, receives a 402 Payment Required response, signs a payment authorization, and retries the request with the payment payload attached. The service provider can verify and settle the payment directly, or delegate that work to a facilitator. The result is a much more automated, request-level payment flow, especially suited to one-off API calls and micro-value machine-to-machine transactions.
This is an over-simplification but one isn’t necessarily better than the other. However, in a world of one-time, micro-value payments, the x402-Stablecoin combo has an edge in that it allows for a more friction-free human-free exchange, perfect for an agentic economy.
x402 is open and evolving, later versions could see TradFi payment methods like cards become part of the protocol. However the only way that would work would be if the cards are specifically issued for use-cases the protocol powers e.g. without 2FA. The Facilitator role is an interesting one. It is worth noting that buyers can also leverage facilitators to abstract away the complexity of authorising and cryptographically signing payments. We will see more PSPs participating in this paradigm as facilitators bringing the reach of TradFi payment methods and their legacy characteristics.
.......
That is the core promise of x402. It turns payment from a separate checkout journey into a native part of the web request itself. For human shoppers, that may feel abstract. For AI agents, APIs, and machine-to-machine commerce, it could be foundational.
As always, I’m keen to hear your feedback and thoughts in the comments. If you found this useful, feel free to share it.
Until the next one, Paul
