The money comes from a wallet

An agent researching a trip might need a paid weather reading. With x402, the API can quote a price in its HTTP response, and the agent’s software can authorize payment before receiving the data.

The developer or operator supplies a funded wallet and a signer, the component allowed to authorize payments. The language model does not acquire money by itself. Its surrounding application connects the request, wallet and payment rules. This guide explains the current documentation checked on November 3, 2026; it is not a new launch announcement.

One API purchase, step by step

First, the client requests a resource. If payment is needed, the server returns HTTP 402 Payment Required. In V2, the PAYMENT-REQUIRED header describes the accepted payment options, including the amount, asset, network and recipient.

Next, the client checks those terms against its policy and available payment support. It creates a signed payment payload and resends the request with PAYMENT-SIGNATURE. The private signing key stays with the signer; it is not the payment header.

The server checks the payload and handles settlement itself or through a facilitator. A successful request returns the resource and settlement information in PAYMENT-RESPONSE. That header can also carry failure information, so its presence alone does not prove payment succeeded.

Consider an illustrative API charging 0.01 USDC for one weather response, with 100 accepted fixed-price purchases. Their service charges total 1 USDC, before any additional costs. These are example terms, not a quote from a live provider.

A fixed price is only one payment model

The buyer documentation distinguishes exact, a fixed-price payment; upto, where the buyer authorizes a maximum and the seller charges actual usage; and batch-settlement, where deposits and signed off-chain vouchers allow later on-chain redemption in batches.

Consequently, one paid API call does not always mean a separate immediate blockchain transfer. The client must support the advertised scheme and network. A token balance on an unrelated network does not automatically satisfy the server’s offer.

Give the application a budget before it gets a signer

The current official buyer quickstart documents a default limit of $1 per payment and recognized USD-pegged assets. Those are client implementation defaults, not an immutable protocol rule or a daily budget. Configuration and software versions matter.

For deployment, a practical policy should also restrict approved services and recipients, require the expected network and asset, and track a total task or daily allowance across concurrent calls. For the example above, a 1-USDC service budget permits at most 100 purchases at 0.01 USDC each, before other charges.

The SDK exposes spend controls before signing and hooks for interactive approval. Keep signing credentials out of model prompts and retrieved documents. A webpage requesting payment should be evaluated by the application’s rules, rather than treated as authority to spend.

Who processes payment, and who pays the fees?

A facilitator verifies payment payloads and submits settlement transactions for the server. The documentation describes it as non-custodial: it processes signed instructions rather than holding the buyer’s funds. A server can instead implement its own settlement path.

The x402 standard has no built-in protocol fee. That does not make every integration free. API prices, facilitator terms and network costs remain separate. Gas treatment depends on the mechanism; some EVM transfers use facilitator-sponsored gas, while Cardano’s documented flow has the client pay its network fee.

The public x402.org facilitator is intended for development and testnets. A production service needs a suitable production facilitator or its own settlement implementation.

A timeout is not permission to pay twice

After PAYMENT-SIGNATURE has been sent, a lost HTTP response leaves the payment outcome uncertain. The server may already have settled it. Check available transaction and network details, or the provider’s reconciliation process, before authorizing another payment.

The documented settlement_pending result is non-terminal. An expired timer does not prove the earlier transaction failed. If the outcome remains unknown, stop automatic payment attempts and keep the operation unresolved for review. The protocol does not supply a universal settlement-status endpoint.

Older examples may use X-PAYMENT and X-PAYMENT-RESPONSE. V2 uses PAYMENT-SIGNATURE and PAYMENT-RESPONSE, alongside PAYMENT-REQUIRED. Check the version of the service and client rather than mixing examples.

Payment and access permission remain separate

x402 supplies a payment flow. An API can still apply its own access rules, and the documented hooks support alternatives such as valid API-key access. Paying does not by itself establish data accuracy, permission to redistribute the response or a service guarantee.

For a first integration, the useful proof is an authorized request with a checked payment result and usable data, followed by a correctly handled declined payment and timeout. This explainer did not connect a wallet or execute a real purchase.