x402 and HTTP payment flows

Sources checked 2026-09-15

x402 describes an HTTP-based payment flow. A payment declaration, an accepted payment and settlement are different states and should be documented separately.

x402 is a way for a site to ask an agent to pay before it returns a resource, using the long-reserved HTTP 402 Payment Required status. It lets an automated client discover a price, pay and continue, without a human stepping in to enter card details.

How the flow works

When an agent requests a paid resource, the server responds with 402 and a manifest that states what is being sold and how to pay. The agent reads the terms, signs a payment payload for a supported method, and retries the request with the payload attached. The server or its facilitator then settles the payment. The transaction happens in the protocol, not in a checkout page built for human eyes.

x402, AP2 and a2a-x402 are separate specifications

x402 belongs to a small family of agent payment standards, and its relationship to AP2 is worth stating precisely. They are separate specifications. AP2 defines the mandates and receipts that authorize a payment, and x402 defines an HTTP 402 payment flow that a separate extension, a2a-x402, carries into agent-to-agent work. As of September 2026 the AP2 project ships x402 scenarios among its own samples, and the a2a-x402 extension carries its own specification, so a site treats them as protocols it may support side by side rather than as one finished stack.

Declaration, acceptance and settlement are different states

A 402 response with a manifest is a declaration that a resource can be bought this way, and nothing more. An agent that signs a payload and retries has made an accepted payment attempt, which is a second, later state. Settlement, where the server or its facilitator confirms the funds moved, is a third state that can trail the first two by an interval the site should be able to name. Treating these three as one event hides the point where a purchase can still fail after the agent believes it has paid, so a site's own record keeps them apart rather than collapsing a declaration into a completed sale.

Why a declared payment surface matters

Checkout is one of the places agent commerce stalls today. An agent can find a product and compare options, then stall at a checkout flow designed for a person with a browser. A declared payment surface such as x402, paired with structured pricing in the page data, lets the agent complete the purchase the same way it completed the search, though checkout is one obstacle among several and not the whole of what agent commerce still needs. A site that publishes these signals tells agents it is open for automated business, and in the case of an open peer pricelist model, it can be shown alongside other options at the moment an agent decides where to spend.

turva.dev's own x402 surface is a declaration only. Its manifest states that no facilitator is configured, that the payment header is not verified and that the resource answers 402 regardless of payment, so sending funds achieves nothing, and settlement happens out of band against a written scope after a quote. That is the boundary this guide recommends stating on any site whose x402 surface is not wired to a facilitator: say which of the three states the site actually implements.

Sources

• x402 protocol site
• x402 repository
• a2a-x402 extension
• Agent Payments Protocol (AP2) repository

Related

• Agent commerce discovery: A2A, AP2, ACP and UCP
• The /.well-known directory for agent discovery
• How to choose an agent-readiness audit