x402 Protocol Explained: How HTTP 402 Payments Work

By Owen Thurm Published November 6, 2026 5 min read

Quick answer. x402 is an open payment standard built on HTTP's 402 Payment Required status. A server answers an unpaid request with 402 and its price; the client retries with a signed payment, which a facilitator verifies and settles onchain.

Watch: x402 Protocol Explained: How HTTP 402 Payments Work 1:42

Video transcript

HTTP has a payment status code that never got a standard use. x402 puts it to work, so an API or agent tool can charge per request.

x402 has three parties. A client, any app or agent, requests a paid resource. A resource server charges, and a facilitator verifies and settles the payment onchain.

The client asks without paying, and the server answers 402 with its price. The client signs a payment and retries. A facilitator verifies and settles it, and the server returns 200.

Facilitators are optional but recommended, and do not hold funds. The client's signed authorization fixes payer, recipient and amount, so the facilitator cannot change either.

x402 started at Coinbase, and Cloudflare partnered with it to create the x402 Foundation. The Linux Foundation launched it in July 2026, with 40 members including Visa, Google and Stripe.

The risks sit in what the signature leaves open. One payment can pass two requests, a facilitator can report false success, anyone holding a leaked authorization can submit it, and agents can overspend.

In July 2026, researchers tested 15 major facilitators against eight security rules and found violations in all of them. The affected parties adopted mitigations.

Guardian's API pentest checks x402 endpoints for replay protection, rate limiting and out of order flows. Read the full article, or talk to Guardian at guardian.security.

HTTP has a payment status code that never got a standard use. MDN lists 402 Payment Required as nonstandard and "reserved for future use", created for digital cash and micropayments.

x402 puts it to work. An API, a page or an MCP tool can charge per request, and the client pays inside the same exchange.

Coinbase's docs describe it as "no checkout page, card form, or signup flow". That suits AI agents buying a tool call mid-task.

x402 in Brief

The specification calls x402 "an open payment standard that enables clients to pay for external resources". Version 2 dates from December 9, 2025.

It has three parties:

Client: "any application or agent" that requests a paid resource.
Resource server: the API, content or data service that charges.
Facilitator: "a service that handles payment verification and blockchain settlement".

The project's README lists six principles. Among them: an open standard; network, token and currency agnostic; and trust minimizing.

Trust minimizing has a precise meaning. No scheme may let the facilitator or server move funds "other than in accordance with client intentions".

HTTP is the original transport. The spec also maps x402 onto MCP for agent tools, and onto A2A for direct agent-to-agent payments.

The Payment Flow

The version 2 HTTP transport uses three headers, each carrying base64-encoded JSON. The default flow runs like this:

The client requests a resource with no payment.
The server returns 402 with a PAYMENT-REQUIRED header listing what it accepts.
The client picks an option, signs a payment and retries with a PAYMENT-SIGNATURE header.
The facilitator verifies the payment.
The server runs the request.
The facilitator settles the payment, typically by broadcasting a transaction.
The server returns 200 with a PAYMENT-RESPONSE header.

If settlement fails, the server can return 402 instead, with a PAYMENT-RESPONSE that reports the failure and a reason.

What a 402 asks for

Each accepted option names:

scheme: how the payment works, such as exact.
network: the chain in CAIP-2 form, such as eip155:8453 for Base.
amount and asset: the price in the token's smallest unit, and the token.
payTo: the address that receives the money.
maxTimeoutSeconds: the most time allowed to complete the payment.

Schemes and flows

The spec names four schemes, including:

exact: a fixed price the server knows in advance.
upto: a signed maximum, with the charge set by what the request consumed.

The other two are batch-settlement and auth-capture.

The order of payment and work can change too:

Flow	Order	Effect
authorization (default)	verify, resource, settle, respond	Funds move only after the request succeeds
upfront	settle, resource, respond	The server gets finality first
escrow	settle, resource, settle, respond	A deposit or ceiling first, the final charge after

What the client signs

On EVM chains, the exact scheme defaults to EIP-3009: the client signs a transferWithAuthorization for the token. Permit2 and ERC-7710 delegations are the alternatives.

An EIP-3009 authorization fixes the payer, recipient, amount, validity window and a nonce. The scheme states that "the Facilitator cannot modify the amount or destination".

The facilitator submits the transaction and pays the gas.

Facilitators and Settlement

The x402 docs call the facilitator "optional but recommended". It "does not hold funds or act as a custodian".

It exposes three endpoints:

POST /verify: checks the payment. It is read-only.
POST /settle: commits the payment, typically as an onchain transaction.
GET /supported: the schemes, networks and signer addresses it handles.

There are three ways to get one:

Option	Use it for
Public x402.org facilitator	Testnets and local development, not production mainnet
Hosted facilitator	Managed production, from a provider on your network
Self-hosted	Full control, run separately or inside your server

Coinbase's CDP facilitator is one hosted option. Its docs list:

Networks: Base, Polygon, Arbitrum, Monad, World and Solana, plus testnets.
Price: 1,000 onchain transactions a month free, then $0.001 each. Verification is free.
Screening: OFAC and Know Your Transaction (KYT) checks that decline sanctioned or high-risk addresses.

Coinbase says it has processed "more than 100 million transactions and $28 million in payment volume" across Base and Solana. The page gives no date.

Who Backs x402

x402 started at Coinbase. In September 2025, Cloudflare announced it was "partnering with Coinbase to create the x402 Foundation".

Cloudflare also let its Agents SDK pay with x402, let MCP servers charge for tools, and proposed a deferred payment scheme.

On July 14, 2026, the Linux Foundation announced the operational launch of the x402 Foundation. Coinbase has contributed the protocol, and the release lists 40 member organizations.

Premier members include Visa, Mastercard, American Express, Google, AWS, Stripe, Circle, Shopify and Cloudflare.

The specification now lives in the x402 Foundation's GitHub organization. Coinbase's repository is a development fork.

Coinbase, Cloudflare and Stripe sit on the foundation's technical steering committee.

Where x402 Breaks

The signature fixes the amount and the recipient. The risks sit in what it leaves to the server, the facilitator and the client.

Risk	Where	Why it happens
Double delivery	Server, facilitator	Verify is read-only, so two requests can pass with one payment
Unbound resource	Server	The signed authorization does not name the resource
False success	Facilitator	Success reported for a payment that never lands
Leaked payment	Logs, proxies	Anyone holding a signed authorization can submit it
Gas drain	Facilitator	It pays the gas on every settlement it submits
Overspending agent	Client	Spending rests with whoever holds the signing key

Refunds are a separate gap. Under the upfront flow, a failed handler leaves the client "charged with nothing delivered", and the spec "defines no refund".

In July 2026, Wang et al. tested 15 major facilitators against eight security rules and found violations in all of them. The affected parties adopted mitigations.

Our x402 facilitator security checklist covers the fixes, from atomic claims to finality and monitoring.

Building agent payments at a bank or fintech? Read agentic payments security for mandates, limits and the regulatory view.

How Guardian Helps

x402 puts payment inside your API calls. Guardian's API pentest tests those endpoints, including replay protection, rate limiting and flows "driven out of order".

For fintechs, Guardian "tests your platform like an attacker, secures your operations over time, and gives you a trust center to prove it".

After launch, Managed Security watches onchain and offchain systems around the clock, and a Guardian engineer responds when something fires.

Frequently Asked Questions

What is the x402 protocol?

It is an open payment standard built on HTTP 402 Payment Required. A server answers an unpaid request with its price, the client retries with a signed payment, and a facilitator verifies and settles it onchain.

Who created x402?

x402 began at Coinbase. The x402 Foundation, launched under the Linux Foundation in July 2026, now stewards it, with Coinbase, Cloudflare and Stripe on its technical steering committee.

Do I need a facilitator to accept x402 payments?

No. The x402 docs call it optional but recommended. You can use a hosted facilitator such as Coinbase's, run your own, or settle inside your server. The public x402.org facilitator is for testnets and development.

Can x402 payments be refunded?

Not by the protocol. The exact scheme defines no refund, and clients must not assume a return path exists. Any remedy is the resource server's own arrangement.

Sources

Test your x402 payment path

Guardian pentests the APIs that verify, settle and serve x402 payments, then keeps them under watch after launch.

Talk to Guardian Explore security for fintechs