x402: HTTP-native payments for agents and APIs

The x402 exchange

A client requests a protected resource. The server returns HTTP 402 with payment requirements. The client evaluates those requirements, creates a signed payment payload with its wallet, and retries the request. The server or an optional facilitator verifies and settles the payment, then returns the resource with settlement information.

The flow removes pre-created accounts and API keys from the payment path. The wallet becomes the client’s payment capability, while the resource server describes price and accepted network or scheme at request time.

Why facilitators exist

A facilitator can verify payment payloads and submit the onchain transaction so the resource server does not operate chain infrastructure. The facilitator does not need the buyer’s private key; it acts on signed authorization supplied by the client.

This simplifies integration but creates a service dependency and policy boundary. Evaluate facilitator network support, screening, availability, pricing, gas sponsorship, verification semantics, and what happens if settlement succeeds but the response path fails.

The wallet is part of the policy architecture

An agent needs programmatic signing capability, but the model runtime should not hold an unrestricted private key. Use an isolated wallet or signer with per-agent budgets, destination controls, transaction simulation where available, key rotation, and an approval hook.

Match the signed payload against the 402 challenge and the agent’s internal order. Reject mismatches in recipient, asset, network, amount, expiry, or resource. The seller’s challenge is untrusted input until policy validates it.

Settlement is fast; recourse is a separate design

A direct onchain payment is not a card authorization. The common exact and upto schemes are push payments; a refund generally requires a new transfer from seller to buyer unless a future scheme adds conditional settlement or escrow.

Products must explain this before purchase and preserve merchant identity, offer terms, order state, and a return address or support path. Do not treat a chain transaction hash as a complete commercial receipt.

Onchain finality does not create fulfillment, refund eligibility, or legal recourse by itself.

Where x402 fits best

x402 is especially natural for APIs, paid resources, MCP tools, model inference, data access, and machine-to-machine services where pricing can be expressed per request and delivery follows payment immediately.

Consumer retail can use the same primitives, but shipping, tax, inventory, cancellation, refund, and dispute state make the surrounding commerce system more complex. Pair x402 with an order model and an authority layer rather than stretching it into every responsibility.