How AI agents pay for services over x402 today

Research date: 23 October 2026 Scope: x402 protocol version 2 and current x402 Foundation specification and documentation. “Today” means what those sources specify, not a measurement of every live endpoint.

Executive answer

Fact. x402 has three core roles: a client/buyer (which may be an AI agent), a resource server, and a facilitator. The resource server can verify and settle a payment itself or delegate those operations to a facilitator; x402 does not mandate a central processor or a single facilitator. The payment recipient is the selected requirement’s payTo value. A facilitator may submit or relay the payment, but may or may not sponsor network fees. x402 v2: components and facilitator interface exact scheme: facilitator-submitted payments

Fact. An agent discovers a known paid endpoint by making the normal request and receiving 402 Payment Required. In HTTP, the canonical PaymentRequired object is base64-encoded in the PAYMENT-REQUIRED response header. It can also query a facilitator’s optional Bazaar catalog, which can list endpoint, accepted payments, and calling metadata. v2 payment-required schema v2 discovery API

Inference. A catalog should be treated as a lead, not the final quote: inspect the fresh 402 from the intended endpoint before signing. Catalog implementation, indexing, and exposure are facilitator-operator choices. Bazaar catalog limits

Who verifies and settles

Stage	Who does it	Confirmed behavior
Offer	Resource server	It returns a payment-required signal containing resource information and one or more accepts[] payment requirements. Each requirement includes scheme, CAIP-2 network, atomic-unit amount, asset, payTo, and a completion timeout. v2 fields
Sign / pay proof	Buyer agent	It selects a supported requirement and sends a PaymentPayload. The data is mechanism-specific; the EVM exact example uses a signed EIP-3009 authorization. v2 payment payload
Check before service	Resource server, locally or via facilitator	The protocol requires at least one verify or settle before protected work. /verify is read-only: it validates payment state and must not commit payment or write on-chain state. v2 payment flows and verify
Service work	Resource server	Default authorization flow is verify → resource → settle. upfront is settle → resource; escrow includes a deposit settle before work and another settle for the charge. v2 flow table
Settlement	Resource server itself or facilitator	/settle durably commits payment state, typically by ledger transaction broadcast. The specification also permits a non-chain commitment for a client-prepaid method. v2 settle semantics
Receipt	Resource server to buyer	The settlement response carries network and transaction identifier. settlement_pending is non-terminal and includes a transaction identifier to reconcile on-chain before retrying. v2 response and pending outcome

Fact. A facilitator exposes standardized HTTP interfaces for verification and settlement. Its GET /supported response declares supported version/scheme/network combinations, extensions, and signer addresses. This lets a server outsource blockchain interaction, but the server can self-facilitate. v2 facilitator interface v2 /supported

Fact. In facilitator-submitted exact, the buyer signs but the facilitator submits or relays the value-moving operation during settlement. Submission does not mean fee sponsorship; the method must state whether the fee is facilitator-sponsored or payer-funded. Correct settlement must produce the stated amount and asset to payTo. exact scheme

Fact. In a client-submitted-proof method, the buyer submits the payment and settlement validates and binds proof to the request. These methods use upfront and must define single-use handling and finality. client-submitted payment proof

Inference. “Verified by x402” is a narrow payment-validity statement. It does not, by itself, establish the seller’s legal identity, the quality of the response, or a refund right.

How agents discover paid endpoints

1. Direct HTTP discovery

Fact. The usual sequence is request → 402 and PAYMENT-REQUIRED → select an accepted option → retry with PAYMENT-SIGNATURE. The first request and 402 are unnecessary only when the client already knows accepted details. reference flow

Fact. Challenge metadata can contain URL, description, MIME type, service name, tags, and icon URL. These are fields supplied by the service; the schema does not turn them into a general merchant-identity credential. v2 resource information fields

2. Bazaar catalog discovery

Fact. A server can put a bazaar extension in its 402 response. It supplies endpoint/MCP calling information and a JSON Schema. A buyer that understands the extension echoes it into the payment payload; a facilitator validates it and may catalog it. Bazaar declaration facilitator behavior

Fact. Implementing facilitators may provide GET /discovery/resources, filterable by type, payee, scheme, network, and extension, plus GET /discovery/search. A record carries resource, type, version, accepted payments, lastUpdated, and optional extensions. v2 discovery API

Fact. The reference repository also names community-maintained directories; they are ecosystem tools, not protocol settlement or trust authorities. repository ecosystem section

Uncertainty. This report did not test live catalogs or claim their coverage, ranking, freshness, or availability. The Bazaar specification says storage, indexing, and exposure are implementation details, so no protocol-wide catalog guarantee exists. Bazaar behavior

Buyer checklist before payment

This is an operating checklist. “Fact” means protocol-derived; “Recommendation” is defensive policy.

1. Recommendation — bind the request to an approved destination. Require an allowlisted HTTPS origin or a deliberate approval for the URL, HTTP method/MCP tool, and inputs. Do not let a search listing or an agent’s prose silently choose the destination. Bazaar describes how to call a tool; it is not a universal identity or reputation system. Bazaar input structure

2. Fact + Recommendation — parse the fresh payment terms and apply a local cap. Check version, scheme, exact CAIP-2 network, asset identifier, atomic-unit amount and token decimals, payTo, timeout, payment flow, and scheme-specific extra. Reject unrecognized flows/methods; clients must not construct a payment for an unknown flow. Enforce per-call, per-service, and cumulative spending limits locally before signing. v2 requirement fields flow-selection rule

3. Fact + Recommendation — check the settlement route. Support is specific to a (scheme, network) pair. If a facilitator will be used, inspect /supported and use an operator allowed by local policy. Confirm who pays fees and the method’s validity/replay rules. pair support facilitator-submitted declarations

4. Fact + Recommendation — prefer post-service settlement when it is offered. For exact, the specification recommends authorization where supported: payment commits after a successful handler. upfront commits first; if the handler then fails, the exact scheme defines no refund and any remedy is the resource server’s arrangement. Treat escrow or usage-ceiling offers as scheme-specific commitments, not fixed-price equivalents. exact payment flow

5. Recommendation — make signing legible and contained. Record or show recipient, token contract/address and network, atomic and display amount, expiry, fee payer, flow, and request identity. Use a token-address allowlist; a ticker alone is not sufficient. Token support varies by network and facilitator. v2 asset-support note

6. Fact + Recommendation — keep receipts and do not blindly repay. Preserve the challenge, chosen requirements, signed payload reference, response, network, and transaction hash. If the response is settlement_pending, reconcile the reported transaction on the declared network before forming a new payment. pending settlement rule

7. Recommendation — assess non-payment risk separately. Before providing secrets or paying significant value, evaluate provider reputation, terms, data handling, content safety, support, and refund path. Payment correctness is not service-quality assurance.

Unanswered questions and limits

Fact. Budget management and correlation tracking are explicitly implementation-specific in x402; the core protocol does not set a universal agent spending policy. v2 AI-agent integration

Unanswered / not standardized in the sources reviewed:

• Seller legal identity, reputation, and service-quality verification.
• A universal refund, chargeback, dispute process, or service-level guarantee.
• A global authoritative directory, catalog inclusion rule, freshness SLA, or ranking rule.
• A cross-agent policy language for budgets, approvals, custody, and key isolation.
• One universal fee payer or finality depth; these depend on the selected network, scheme, transfer method, and implementation.

Method and source boundary

This report uses the x402 Foundation’s open specification and official repository documentation as primary sources, consulted on the research date. It makes no claim that a particular live facilitator, directory, seller, or endpoint is safe or operational when a buyer reads it. Such claims require current, provider-specific verification.