# 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#3-protocol-components) [exact scheme: facilitator-submitted payments](https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact.md#facilitator-submitted)

**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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#511-json-payload) [v2 discovery API](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#8-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](https://github.com/x402-foundation/x402/blob/main/docs/extensions/bazaar.mdx#troubleshooting-catalog-visibility)

## 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#512-field-descriptions) |
| 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#52-paymentpayload-schema) |
| 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#61-asset-transfer-methods-and-payment-flow-models) |
| 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#61-asset-transfer-methods-and-payment-flow-models) |
| 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#72-post-settle) |
| 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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#53-settlementresponse-schema) |

**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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#7-facilitator-interface) [v2 `/supported`](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#73-get-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](https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact.md#facilitator-submitted)

**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](https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact.md#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](https://github.com/x402-foundation/x402#typical-x402-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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#512-field-descriptions)

### 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](https://github.com/x402-foundation/x402/blob/main/specs/extensions/bazaar.md#paymentrequired) [facilitator behavior](https://github.com/x402-foundation/x402/blob/main/specs/extensions/bazaar.md#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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#8-discovery-api)

**Fact.** The reference repository also names community-maintained directories; they are ecosystem tools, not protocol settlement or trust authorities. [repository ecosystem section](https://github.com/x402-foundation/x402#ecosystem)

**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](https://github.com/x402-foundation/x402/blob/main/specs/extensions/bazaar.md#facilitator-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](https://github.com/x402-foundation/x402/blob/main/specs/extensions/bazaar.md#discovery-info-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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#512-field-descriptions) [flow-selection rule](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#61-asset-transfer-methods-and-payment-flow-models)

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](https://github.com/x402-foundation/x402#schemes-vs-networks) [facilitator-submitted declarations](https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact.md#facilitator-submitted)

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](https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact.md#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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#112-supported-assets)

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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#9-error-handling)

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](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md#121-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.