
x402 is an open, neutral payment standard for internet-native transactions built on the HTTP protocol. It repurposes the long-unused HTTP 402 “Payment Required” status code to enable peer-to-peer payments directly within HTTP request-response cycles. Payments can be made in supported cryptocurrencies like USDC and through supported fiat money facilitators like payment cards.[1]
History
The HTTP 402 status code has existed since the early days of the World Wide Web, originally conceived as a mechanism for servers to charge clients per request. However, the status code remained largely unused for decades due to infrastructural limitations: payments were slow, expensive, and required accounts, sessions, and chargeback-heavy intermediaries.
x402 was developed by Coinbase to revisit this original concept with modern cryptographic primitives, including stablecoins, fast blockchain settlement, and programmable authorization. The protocol leverages EIP-3009 (permit-style authorization) to enable direct payment verification without external payment gateways.
Technical specification
Protocol overview
x402 introduces a minimal extension to standard HTTP flows, enabling payment verification before resource access is granted. The protocol maintains full HTTP compatibility while introducing payment negotiation as an integral part of the request–response cycle.[2]
Three-phase payment flow
Phase 1: Request and quote
A client makes a standard HTTP request to a resource server. If the resource requires payment, the server responds with an HTTP 402 status code along with a JSON payload specifying:
- Price (typically in USDC or similar stablecoins)
- Supported blockchain network (e.g., Base)
- Cryptographic requirements
- Wallet address for payment destination
Phase 2: Authorization and verification
The client generates a signed payment authorization using the EIP-3009 standard (transferWithAuthorization) via their cryptocurrency wallet. The client resubmits the HTTP request, attaching the signed payment payload in an HTTP header (typically X-PAYMENT or PAYMENT-SIGNATURE). A facilitator service (or the server itself) verifies the cryptographic signature and confirms that payment parameters match the initial quote.[3]
Phase 3: Settlement and resource delivery
Once the facilitator validates the payment authorization off-chain, the signed transaction is submitted to the blockchain for settlement. After on-chain confirmation, the server returns the requested resource with an HTTP 200 status code and an X-PAYMENT-RESPONSE header containing the transaction hash for verification.
Key design features
- HTTP-native: Built directly into HTTP requests with no additional communication protocol required
- Stateless: No user accounts, sessions, API keys, or persistent credentials needed
- Cryptographically verifiable: All payment authorization is signed and verifiable on-chain
- Instant settlement: Uses stablecoins and fast blockchains for near-immediate verification
- Backend-agnostic: Any server capable of returning an HTTP 402 response can adopt the protocol
Applications and use cases
The x402 protocol facilitates instant, programmatic transactions for environments where traditional payment systems are inefficient. Enterprise platforms such as Amazon Web Services have demonstrated how financial institutions can integrate autonomous AI agents with x402 payments infrastructure, enabling agents to access premium APIs and data services with instant, on-chain settlement without account setup or intermediary involvement.[4] Primary applications include:
- Micropayments: Real-time, low-fee processing for high-volume, fractional-cent transactions.
- Agentic payments: Programmatic negotiation and settlement of transactions by autonomous software agents without human intervention.
- Pay-per-API call: Programmable, pay-per-call billing that replaces traditional API keys and subscription tiers.
- Machine to machine (M2M) transactions: High-velocity financial exchanges between automated systems, such as Internet of Things (IoT) devices.
- Pay as you go access: Pay-as-you-go models for cloud resources, media, and data, billed strictly per use rather than through fixed subscriptions.
- Subscriptions and renewals: Autonomous execution of recurring payments by software agents on behalf of users.
Implementation
Code example
A simple Node.js example using x402 middleware:
app.use(
paymentMiddleware(
{
"GET /weather": {
accepts: [...], // As many networks / schemes as you want to support
description: "Weather data", // What your endpoint does
},
},
)
);
If a request arrives without payment, the server responds with HTTP 402. Upon receiving the 402, the client’s wallet signs a payment authorization and resubmits the request.
Technical standards and compliance
x402 conforms to:
- RFC 9110 – HTTP Semantics and Content
- EIP-3009 – Permit extensions for ERC-20
- EIP-712 – Typed structured data hashing and signing
Advantages and criticisms
Advantages
- Eliminates payment intermediaries and associated fees
- No account setup or identity verification required
- Cryptographically secure and verifiable on-chain
- Fully compatible with existing HTTP infrastructure
- Suitable for micropayments where traditional processors are inefficient
Challenges
- Requires wallet adoption among clients
- Dependent on Blockchain network availability and speed
- Limited mainstream awareness compared to traditional payment methods
- Regulatory uncertainty surrounding cryptocurrency-based payments in various jurisdictions
References
- ^ “x402 – Payment Required”. x402.org. Retrieved 2026-04-04.
- ^ “How x402 Works”. Coinbase Developer Documentation. Retrieved 2026-04-04.
- ^ “x402 Protocol Integration – Browserbase Documentation”. Browserbase. Retrieved 2026-04-04.
- ^ “x402 and Agentic Commerce: Redefining Autonomous Payments in Financial Services”. Amazon Web Services Blog. Retrieved 2026-04-04.