Protocol guide
x402: HTTP-native payments for agents
A practical explanation of x402, the open protocol that uses HTTP 402 Payment Required to let clients pay for APIs and digital resources programmatically.
GET /resourceclient → server402 + PAYMENT-REQUIREDrequirementsPAYMENT-SIGNATUREscheme payload200 + PAYMENT-RESPONSEresource + settlementTL;DR
x402 is an open payment protocol built around HTTP 402 Payment Required. In x402 V2, a server sends encoded requirements in PAYMENT-REQUIRED, the client constructs a scheme-specific payload and retries with PAYMENT-SIGNATURE, and the server returns the resource with settlement details in PAYMENT-RESPONSE after verification, fulfillment, and settlement.
What to remember
- x402 keeps payment inside the familiar HTTP request-response loop.
- The seller states requirements; the client chooses a compatible payment option.
- Facilitators can verify and settle payments, but servers may also self-facilitate.
How an x402 request works
- 01HTTP
Request
The client requests an API endpoint, file, model output, or other HTTP resource.
- 02header
Challenge
The server responds with 402 Payment Required and a base64-encoded PaymentRequired object in PAYMENT-REQUIRED.
- 03payload
Authorize
The client selects an entry from accepts and constructs its scheme-specific PaymentPayload, often including a signature.
- 04header
Retry
The client repeats the request with the encoded payload in PAYMENT-SIGNATURE.
- 05200
Verify, fulfill, and settle
The server verifies the payload, performs the work, settles directly or through a facilitator, and returns the resource with PAYMENT-RESPONSE settlement details.
Client, resource server, and facilitator
The client is the buyer: an agent, application, or human-operated tool that can understand the payment requirements and authorize a supported payment. The resource server is the seller: it protects a route and describes the price and accepted payment schemes.
A facilitator is an optional verifier and settler that can reduce the network-specific work a resource server performs. Servers can also verify and settle directly. Compatibility depends on the registered scheme and network plus the selected client, server, and facilitator implementations; current official documentation covers multiple EVM and non-EVM networks.
Current x402 payment schemes
- exact: a fixed-price payment for a resource.
- upto: the buyer authorizes a maximum and the seller settles actual usage up to that limit; current documentation describes an EVM Permit2 implementation.
- batch-settlement: the buyer funds escrow and signs offchain vouchers that sellers redeem later in batches.
- Support is defined by a scheme and network pairing; it is not guaranteed across every facilitator or SDK.
Where x402 fits
- Pay-per-request APIs and model inference.
- Programmatic access to datasets, reports, or content.
- Agent tools that are discovered and purchased at runtime.
- Microservices that settle usage without a monthly account.
- Proxy or routing services that compose multiple paid capabilities.
Implementation questions to answer first
Choose which routes require payment, how the amount is calculated, which networks and assets are accepted, and whether the payment binds to the method, URL, body, or an idempotency key. Decide how long requirements remain valid and how duplicate retries are handled.
On the buyer side, enforce policy before signing. On the seller side, return clear errors, record the settlement result, and keep business authorization separate from payment verification. Payment proves that the required transfer occurred; it does not automatically prove that every caller may access every resource.
Sources and further reading
Protocols change quickly. We reviewed the primary sources below on July 23, 2026.