x402 HTTP Payments for AI Agents

For a paid API, the difficult timeout is the one that happens after money moves and before the response reaches the buyer. x402 provides an HTTP payment exchange; the service still needs a durable answer to whether that buyer already paid and what they received.

In x402, a resource server returns 402 Payment Required with payment terms. The client submits scheme-specific payment data, and the server verifies and settles according to its integration before fulfilling the request. I would design the operation record and recovery path before choosing middleware.

The x402 Foundation specification currently documents protocol version 2. It is an open project specification, not an IETF RFC. The HTTP binding is the subject here; support for other transports doesn't establish that a website has a paid HTTP resource.

The three HTTP headers carry the payment exchange

An unpaid request receives 402 Payment Required. In x402 v2, the canonical payment description is a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED response header. The object identifies the resource and provides an accepts array.

Each accepted option states the payment scheme, network, asset, amount, destination, and maximum completion time. Network identifiers use CAIP-2 form, such as an EVM chain namespace and reference. Amounts use atomic units, so a UI or agent must know an asset's decimals before presenting a human-readable price.

The client selects an accepted option, constructs the scheme-specific authorization, and retries the original request with PAYMENT-SIGNATURE. That header carries a base64-encoded PaymentPayload, including the selected terms and signed data. The server must compare the submitted choice with the terms it issued. A valid signature over a different recipient or amount cannot satisfy the quoted requirement.

After successful settlement, PAYMENT-RESPONSE carries a base64-encoded settlement result. Depending on the scheme, that can include the payer, network, amount, and transaction reference. The application response body remains the resource server's concern. See the Foundation's HTTP transport specification for the current wire format.

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 PaymentRequired>

GET /paid-resource HTTP/1.1
PAYMENT-SIGNATURE: <base64 PaymentPayload>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64 SettlementResponse>

A plain 402 without x402 payment terms does not implement the protocol. Nor does a successful Bazaar discovery request prove that a particular origin protects a route. Test the resource itself and decode the headers.

A facilitator handles payment operations, not product delivery

A resource server can implement scheme verification and network settlement itself. Most teams will evaluate a facilitator instead. The current facilitator interface exposes /verify to check a payload without broadcasting it, /settle to execute settlement, and /supported to describe supported combinations.

The x402 facilitator documentation calls the service optional and recommends choosing a production provider that supports the intended mainnet, or operating the function directly. The public x402.org facilitator is described as a development and testnet path. Treating that public service as an assumed production dependency would skip vendor review and availability planning.

Verification should confirm the signature, amount, recipient, asset, time window, network, and scheme rules. Settlement then submits the authorized transaction. The facilitator returns a result, but the resource server decides whether to release the resource and records what it released.

That last part can't be delegated away. If settlement succeeds and rendering the paid report fails, support staff need a recovery path. If the facilitator times out after broadcasting, the server must determine whether funds moved before attempting again. Define those states before real money enters the route.

Treat recipient changes like changes to payment routing

The receiving address must belong to the business. Verify it out of band, separate test and production configuration, and make a second person confirm any change. A typo in payTo can direct funds to an unintended destination while every HTTP check still passes. Keep recipient changes reviewable separately from price changes so an ordinary catalog update can't obscure a change in where payments go.

Network selection affects finality, fees, asset availability, and facilitator support. Asset selection adds decimal handling, treasury custody, conversion, and accounting questions. A team that prices a resource in dollars but receives a token must decide when a quote expires and who absorbs price movement.

Client controls matter too. An agent-capable client should enforce a maximum amount, approved assets and networks, permitted merchants, and a per-period budget before signing. The server cannot assume that machine payment means unlimited delegated authority. A useful client-side refusal case is a valid challenge whose amount exceeds the approved budget by one atomic unit. Payment verification may succeed in a sandbox; the client should still decline to sign that purchase.

Keep wallet keys and facilitator credentials out of route code and logs. Rotate secrets, restrict outbound facilitator destinations, cap request sizes, and avoid recording complete payment payloads when a transaction reference and internal correlation ID are enough for support.

Replay protection and idempotency solve different problems

The EVM exact scheme described by x402 uses a unique nonce and validity interval. The token contract rejects nonce reuse after the authorization is consumed. Other schemes define their own replay controls.

Application retries still need a separate answer. Imagine a paid POST that generates an export and stores it. The client loses the HTTP response, retries, and presents a payment that the server has already settled. The server should return the original export or a stable status, not charge again and start a second job.

Bind an application operation ID to the quoted terms, payment reference, settlement state, and fulfillment result. Enforce uniqueness in durable storage. The x402 Payment-Identifier extension can carry an operation identifier where both parties support it, but the application still owns atomic fulfillment and retry behavior.

No priced route exists on this site

TKOResearch publishes TARE product information, engineering articles, and private client service information. The contact endpoint accepts inquiries. No public route sells a defined machine resource at a posted per-request price.

Putting x402 in front of /api/contact would charge for intake without a product decision, support policy, or refund contract. Putting it in front of an article would invent a sales model that the site doesn't operate. Public pages should keep returning ordinary successful responses, and the contact workflow should remain outside payment middleware.

A future TARE API could make a different choice for one bounded operation. The release question would be concrete: what does one successful request buy?

The first paid route decides the design

Before x402 appears in production, write a release record around that route. Four parts deserve direct answers:

1. Define the fulfillment result for success, timeout, and partial failure, along with the request schema, authentication policy, service objective, error contract, and idempotency key.
2. Publish the amount in atomic units, quote lifetime, taxes, usage limits, scheme, network, asset, receiving wallet, facilitator, confirmation rule, and reconciliation owner.
3. Connect the application operation ID, payment reference, retry result, support case, and any refund or service credit without placing credentials in logs.
4. Test key custody, recipient changes, client budgets, replay controls, rate limits, dependency failures, duplicate requests, settlement ambiguity, facilitator latency, and recovery.

That record would turn a 402 response into a supported TARE product contract. For this publishing site, no priced route meets that contract. A future implementation should first demonstrate recovery from settled-but-undelivered work and a duplicate retry, with both requests resolving to the same operation record.