What is x402 protocol: HTTP 402 payments for per-request access

X402 protocol is an open, HTTP-native payment standard that uses the HTTP 402 “Payment Required” response plus standardized headers to make a client pay before a server returns a resource. It turns a normal API call into a deterministic quote → pay → verify/settle → receipt flow, with optional third-party services to handle verification and settlement across networks.

Key Takeaways

• x402 uses http 402 “Payment Required” plus standardized headers so a server can demand payment before serving an API response or web resource.
• The core handshake is 402 + PAYMENT-REQUIRED (quote) → retry with PAYMENT-SIGNATURE (payment payload) → verify and settle → 200 + PAYMENT-RESPONSE (receipt).
• x402 stays network-agnostic by pairing a payment scheme with a specific network implementation, and it can outsource verification and settlement to a facilitator.
• Solana markets x402 with chain-specific stats, including ~400ms finality, ~$0.00025 transaction costs, and 35M+ x402 transactions and $10M+ volume since launch on Solana.

X402 as an HTTP payment standard

The key move in what is x402 protocol is that payment becomes a first-class HTTP response pattern, not an app-specific billing system bolted on later. A resource server can answer an unpaid request with http 402 and machine-readable payment requirements, and the client can respond with a signed payment payload in headers. That is why “x402 explained” reads less like a crypto product pitch and more like a missing piece of web plumbing getting filled in.

This matters for the agent economy explained because agents do not want to “sign up” for every endpoint they touch. Traditional API monetization forces accounts, API keys, invoices, and a separate authentication story. x402 flips the sequence: the server quotes the payment terms inside the same HTTP flow, and the client proves payment authorization the same way it proves any other request property, by sending a header.

x402 is specified as an open standard for “internet native payments,” intended to be network, token, and currency agnostic. The spec’s center of gravity is the x402 Foundation repository, which is the compatibility target builders should track. Coinbase x402 exists too, but its own README flags it as a development fork after the project moved under the x402 Foundation, which is the practical governance reality behind “coinbase x402.”

How an x402 request gets paid

Between a client hitting an endpoint and the server returning a 200 OK, x402 forces the interaction into a predictable microstructure: quote, fill, clearing, receipt. The protocol does that with status codes and headers, not with a bespoke SDK handshake.

A typical flow, as documented in the x402 Foundation spec, runs like this:

1. Client requests a resource from a resource server over HTTP. 2. Resource server returns a 402 Payment Required response with a PAYMENT-REQUIRED header containing a base64-encoded PaymentRequired object that lists acceptable PaymentRequirements. 3. Client selects one PaymentRequirement and constructs a PaymentPayload that matches the chosen (scheme, network) pair. 4. Client retries the request with a PAYMENT-SIGNATURE header carrying the PaymentPayload. 5. Resource server verifies the payload either locally or by POSTing the payload and requirements to a facilitator /verify endpoint. 6. If verification is valid, the resource server fulfills the request, then settles either directly onchain or by POSTing to a facilitator /settle endpoint. 7. If settlement succeeds, the resource server returns 200 OK with the resource in the body and a PAYMENT-RESPONSE header containing a base64-encoded settlement response.

Two details drive most integration outcomes. First, steps 1 and 2 are optional if the client already knows the payment details for that resource, which is how teams avoid an extra round trip at scale. Second, the spec explicitly allows trading off speed of response against guarantee of payment, which is why “http 402 payment” is not automatically synonymous with “instant final settlement.”

Networks, schemes, and facilitators

x402’s chain-agnostic claim lives or dies on one constraint: clients and facilitators must support explicit (scheme, network) pairs. A scheme is a logical way of moving money, but the implementation of that scheme differs by network. “Exact on Ethereum” and “exact on Solana” are not the same engineering problem, even if the HTTP surface looks identical.

The x402 Foundation repository describes schemes including exact, upto, and batch-settlement (EVM). The distinctions are execution-style choices. exact is a fixed transfer for a request. upto is an authorization up to a cap, with the seller settling actual usage up to that maximum. batch-settlement (EVM) uses escrow and off-chain vouchers so many small charges can be redeemed onchain in batches instead of settling every HTTP request individually.

The facilitator role is the other big design lever. A facilitator is a server that facilitates verification and execution of payments for one or many networks. Concretely, it gives the resource server a /verify and /settle surface so the server does not need to implement every chain integration itself. That convenience comes with a new dependency: the facilitator becomes part of the reliability and trust boundary, even if the standard’s stated goal is trust minimization and not letting facilitators move funds outside client intent.

This is where “x402 protocol crypto” evaluations often go wrong. The right question is not “is x402 fast or cheap,” because x402 is a negotiation and proof layer. Latency, fee profile, and settlement guarantees come from the (scheme, network) pair and whether verification and settlement are handled locally or outsourced to a facilitator.

Why x402 matters for AI agents

AI agents change the shape of demand because they generate lots of small, frequent requests that are hard to monetize with subscriptions and awkward to gate with account onboarding. x402 is built to make agentic payment feel like normal HTTP: the agent calls an endpoint, gets a 402 quote, and can decide whether to pay based on its own rules.

Solana’s x402 page frames this as “internet-native payments” for autonomous tools, and it leans on stablecoin settlement as the economic rail that makes per-request pricing sane. That page claims stablecoin payments on Solana exceed $11B in circulation and account for 200M+ transactions per month, positioning the network as a high-throughput settlement layer for pay-per-request services.

The mechanism maps cleanly to agent workflows because it removes the need for a separate identity and billing channel. A client that can speak HTTP can learn to pay by reading standardized headers, rather than integrating a different billing SDK for every API. That is the killer feature for machine to machine payment: the payment negotiation is legible to generic clients, not just to humans clicking a checkout page.

The tradeoff is that “payment is authentication” only works as smoothly as the scheme and facilitator choices allow. If an agent is making thousands of calls, the difference between “exact settled every time” and “batch-settlement redeemed later” is the difference between a tight loop and a system that spends its time waiting on confirmations.

Adoption signals and practical tradeoffs

The cleanest traction datapoint in the provided sources is chain-specific: Solana’s x402 page claims that since x402 launched on Solana “this summer,” it has processed 35M+ transactions and $10M+ volume over x402. The same page claims Solana has ~400ms finality and ~$0.00025 transaction costs. Those are useful as adoption and performance signals for that deployment, but they are not proof that every x402 integration inherits those numbers.

The spec itself pushes a more sober framing: x402 is flexible, and implementations can trade off response speed against payment guarantees. That is why broad claims like “settles within ~2 seconds” from ecosystem explainers should be read as network- and design-dependent, not as a property of the HTTP handshake.

Builders also need to separate “standard” from “ecosystem marketing.” Solana’s page asserts that major platforms like Cloudflare, Google, and Vercel support x402, but the provided sources do not define what “support” means at the product level. Without a concrete integration surface, that line is not actionable.

The practical posture is to start narrow and measure. One (scheme, network) pair in production gives a single happy path to instrument end-to-end. From there, teams can add more schemes or networks, and decide whether to keep verification and settlement local or to rely on a facilitator. That is the difference between a demo that works and a payment layer that survives retries, timeouts, and partial failures in the agent economy.

The Take

I’ve watched teams treat x402 like “a crypto paywall” and then get surprised by the part that actually determines user experience: the (scheme, network) pair and where verification and settlement live. The HTTP handshake is deterministic. The clearing layer is not. If a facilitator’s /verify is fast but /settle stalls, the client sees it as an API that randomly hangs, even though the headers are perfectly standardized.

The mental model that sticks is microstructure. 402 + PAYMENT-REQUIRED is the quote, PAYMENT-SIGNATURE is the order, verify and settle is clearing, and 200 + PAYMENT-RESPONSE is the receipt. Once that clicks, the evaluation stops being “is x402 cheap” and becomes “what execution style did this endpoint choose, and what dependencies did it introduce,” which is exactly the right lens for the agent economy explained.

Sources

• Solana Foundation
• x402 Foundation (GitHub)
• Coinbase (GitHub)
• thirdweb