x402 and HTTP payment flows

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 PaymentRequired object, which x402 v2 carries in the PAYMENT-REQUIRED response header, stating 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 that authorize a payment and the receipts that record whether it was accepted, 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 PaymentRequired object is a declaration that a resource can be bought this way, and nothing more. An agent that signs a payload and retries has submitted a payment attempt, and the server's verification of that payload decides whether it is accepted. Acceptance is a second, later state. Settlement, where the server or its facilitator durably commits the payment, 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 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 once the site verifies and settles the payment, 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 where an agent compares sellers, a site with machine-readable prices can be one of the options it weighs when it 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