x402 payments: from the first request to the final receipt

A price software can understand

A useful API can be available to the whole internet and still need a way to charge for its work. A traditional checkout is designed for a person: choose a subscription, create an account and copy an API key. An autonomous client needs something more direct. x402 gives the server a way to describe a paid resource inside the HTTP conversation, so the client can evaluate the price before it authorizes a payment.

The first response is an offer, not a charge

For an unpaid request, the resource server returns HTTP 402 Payment Required. In x402 v2, payment requirements are carried in the PAYMENT-REQUIRED header. The client reads the supported scheme, network, token, amount, recipient and timing requirements. It should also check that the resource being offered is the resource it actually requested. Receiving a challenge does not move funds and does not oblige the buyer to pay.

Authorization is a separate decision

A compatible client chooses an accepted payment option and prepares the required signed payload. It retries the request with PAYMENT-SIGNATURE. The signature is permission under the selected payment scheme; it is not permission to use the wallet without limits. A buyer should enforce a maximum price, an approved recipient and a permitted network before signing. Token symbols alone are insufficient: contract addresses and decimal precision matter.

Verification and settlement do different jobs

Verification checks whether a payment payload satisfies the terms. Settlement submits the payment through the chosen chain and scheme. A facilitator can perform these operations for the resource server, but a verification result by itself is not a confirmed transfer. The server must coordinate its work, payment handling and response delivery. A successful response may include a PAYMENT-RESPONSE receipt that the client should retain with its request record.

A timeout needs reconciliation

If a connection drops, a client may not know whether payment settled or whether the result was delivered. Automatically signing a fresh payment can pay twice. The correct recovery process depends on the network and scheme. Check the receipt, transaction and authorization state where supported, and respect the authorization expiry. Sellers should publish a support or recovery path for a settled request whose response was lost.

What a good first integration looks like

Start with one clearly priced operation. Publish the method, input example, payment asset, supported network and error behavior. Test unpaid requests, valid payments, rejected signatures, timeouts and lost responses. Record the difference between a paid request and a funding transfer. The strongest payment integration makes the price clear before signing and makes the outcome traceable afterward.