What is x402
Introduction
x402 is an open payment standard launched in 2025, aimed at officially activating the HTTP 402 status code and transforming it into an internet-native payment mechanism.
A technical standard jointly promoted by the internet infrastructure company Cloudflare and the cryptocurrency exchange Coinbase.
Compared to traditional models that require creating accounts, binding credit cards, or pre-loading funds, x402 embeds payment requests directly into HTTP responses, allowing clients (whether human, robot, or AI agent) to automatically recognize payment information and complete transactions.
x402 allows an HTTP request to simultaneously possess the attributes of 'data transfer' and 'value transfer'.
As long as the payment is completed, access permissions can be opened immediately, without the need for accounts or manual operations.
Original intention of the design
Solve the need for machine-to-machine (M2M) and AI agents (AI Agent) to make high frequency, small amount, automated payments when accessing network services (like APIs).
For example, an AI program may need to call thousands of data APIs per second, each time paying 0.001 dollars. Traditional payment methods (like credit cards) cannot handle such scenarios, while x402 aims to provide a standardized solution.
Historical background
The HTTP protocol has reserved the 402 'Payment Required' status code since early standardization, but it has not been utilized.
The reason lies in the joint effect of technology, business, and user habits
There is no unified specification, no unified settlement methods, etc. (such as supporting fields), what to write in the message format, who to pay, how much to pay, how to prove it, etc., all unknown.
Without a public track, like a blockchain, everyone cannot reach a consensus.
Micro-payments are not economical, for example, transactions at a few cents level still require paying a fixed fee of thirty cents, which is a loss (design of credit card companies).
Traditional transactions have chargebacks, refunds, compliance checks, etc., which are prone to issues.
x402 participants
Client (Client): The user, application, or AI agent that initiates the request.
Server (backend)/Provider: The entity providing data or services (API, website, etc.)
Facilitator (settlement party): responsible for verifying whether the payment is completed. Most current implementations are based on blockchain, but theoretically any system with verifiable settlement capability can be integrated.
Narrow and broad roles
Narrow sense Provider: Resource provider, understood as the server that issues the 402 bill
In the broad sense: supporting service providers, micro x402 provides basic and supporting stakeholders.
Tools: SDKs, wallet plugins, etc.
Platform: Agent deployment, hosting, etc.
Infrastructure: RPC, indexing, etc.
Facilitator
Considered a middleware, serving as a bridge between web and blockchain.
Assuming the server sends a 402 bill to an AI, requesting payment of 1 USDC, then on which chain to pay? How does the server know the payment was actually made?
Facilitator is equivalent to an outsourcing entity that checks on-chain data and confirms that the transaction is real.
Generate credentials and send them to the server.
The server trusts this designated facilitator, thus completing the transaction.
The role of the Facilitator generally includes Coinbase CDP, CloudFlare may embed.
web3 payment gateways, such as USDC
Node service providers
Payment giants: Paypal, Visa
Self-hosted: API providers themselves
In practical use, it may conduct KYT or risk control targeted at Facilitators.
Basic process
Client (Client) → Server (Provider): Request resources. For example, AI Agent requests a paid resource (API interface) from the server.
Server (Provider) → Client (Client): The server returns HTTP 402, along with payment conditions (payment asset, amount, receiving address, etc.), equivalent to a standardized bill, indicating the required payment amount, quantity, currency, address, etc.
Client (Client) → Blockchain: The client initiates payment using stablecoins (like USDC), and the blockchain completes it, along with proof.
Client (Client) → Facilitator: The client takes the txHash to request the Facilitator's verification address (the address specified in step 2).
Facilitator → Blockchain: The Facilitator checks whether the txHash is real, valid, and the amount is correct.
Facilitator → Client (Client): After the Facilitator verifies, it issues a time-sensitive 'new credential' (for example, a JWT Token) to the client.
Client (Client) → Server (Provider): The client re-requests the resource and attaches this 'new credential' issued by the Facilitator in the request header.
Server (Provider): The server only verifies whether this credential is issued by a trusted Facilitator.
The entire process is programmable and can be done without human involvement or account systems.
Comparison and distinction
Why is it mentioned at this time
AI agents need to pay per use, meeting the demand for high frequency, small amounts, and automation.
Mature technology: blockchain, stablecoins
Other status codes
401: Unauthenticated, identity verification, such as account password
403: Forbidden, insufficient permissions
404: Content not found
500: Internal server error
Problems to be solved
Payment issues for AI agents
High frequency, high friction micro-payment issues
Before x402, assuming AI needed to call 100 different APIs to complete tasks.
Then you need to first manually register 100 API service websites.
Add payment information to 100 websites.
Bind according to payment requirements, such as monthly or per instance.
Receive 100 bills.
Related ERC
EIP-3009: "Transfer ERC-20s with a signature
First implemented and promoted by USDC (v2)
Allow token holders to sign an 'authorization to transfer' offline first, and any relay or counterpart can put this authorization on-chain to complete the actual transfer. The goal is to allow for Gas payments, atomic settlement, and to avoid allowance loopholes, suitable for 'push' payments per instance.
The Agent (client) locally signs an EIP-3009 formatted message with its own private key (or session key), stating: 'Authorize the transfer of 0.01 USDC from my wallet to the Provider's wallet'. This process is instantaneous and does not cost Gas. The Agent sends this signature as 'payment proof' to the Facilitator.
Normal transactions are: the agent creates, signs, and broadcasts a transaction while holding ETH as Gas. If the Agent only has USDC, it will be troublesome. EIP 3009: Locally generate a signature: I authorize 100 USDC to transfer to B.
Agent does not need Gas, can be paid by the Facilitator
The result of the payment is that the Facilitator will take a compensation from this payment: a commission
Or the Provider may pay to seize the market and improve the experience
Core advantage: AI Agent's wallet does not need to hold ETH to pay for Gas, nor does it need to manage complex on-chain transactions (like Nonce, Gas Price). It only needs to be able to sign.
EIP-2612: Permit: Signature-based ERC-20 Approvals (ERC-20 authorization by signature)
Allow users to complete the ERC-20 approve() operation through **'off-chain signature'** without separately paying for Gas.
Before 2612:
USDC—ETH exchange: authorization—exchange, requiring two operations and signatures, while paying for two gas fees.
After 2612:
Authorization transforms into an off-chain signature: free, fast 'I authorize Uniswap (Spender) to take 100 USDC (Value) from me (Owner), this signature is valid before (Deadline)'.
After Uniswap receives the signature, it executes two things in order: sends the signature to USDC, and upon USDC's verification, the authorization is complete
Call the transaction, complete the exchange
EIP-2612 tells the contract: 'You are allowed to take money from me.'
For example, signing an authorization letter allowing the courier (DApp) to pick up a package tomorrow.
EIP-3009 tells the contract: 'Please transfer my money to B immediately.'
For instance, sending a red envelope, anyone (relay) who takes it can cash it immediately.
In the x402 scenario, applications of 3009 are generally broader because they are direct and efficient. But if certain stablecoins are restricted, 2612 may be used.
Privacy issues
x402 Since the payment occurs on the blockchain, everything is essentially public, including the payer, payee, amount, time, etc.
For the Facilitator, it can see the IP address, verify the hash. To put it bluntly, the Facilitator is able to associate the off-chain IP with the on-chain identity.
For the Provider, it can also see the client's IP address and the specific resources requested by the client (such as specific APIs, etc.)
If the Facilitator and Provider collude (or they are the same company, which is likely to happen in the Cloudflare/Coinbase ecosystem), they have complete monitoring capability: who (IP/wallet) paid how much for what (API path) at what time.
How to solve the problem
ZK: For example, paying on a private Layer 2, like Azetc?
For example, private payment channels: similar to the lightning network—avoiding public chain identification, only the final result will be recorded on-chain.
Centralized, not very meaningful, but there will definitely be this solution, for example, clients pre-deposit 100 dollars into their 'Coinbase Agent account' (which can be done on-chain or via credit card).
Whenever the Provider returns a 402, the Facilitator simply deducts the client's balance in its internal database and credits the Provider's balance.
FHE:
Encrypt the resource to be obtained and send it to the Provider. The Provider can perform calculations directly on the encrypted data.
And return the 402 bill
Encrypted: Data-related information
Not encrypted: Payment-related information
Personal opinion
x402 is useful, but not that useful, more like a vertical solution rather than a general paradigm
Currently, the development of x402 is more in web3, but achieving a big result requires more support from web2
AI agents actually have clear boundaries and can focus, essentially belonging to the payment domain, but with no significant effect; payment and privacy are more fundamental.
However, based on the concept of 'fat applications, thin protocols', it is very likely to produce a few leaders.
Short-term outlook is optimistic, but long-term reservations; it is not that the concept is unsuitable, but the implementation (suspended).
Reference: https://mp.weixin.qq.com/s/gEu1c7WYx2oOFF5uyludpQ
