Use x402 when an agent can price a discrete task

Use x402 when the resource can be priced and fulfilled deterministically: a provider search, a data lookup, or a bounded analysis. Use a user-approved account key when the workflow needs durable preferences, third-party connections, account management, or long-lived access to private data.

Give the agent spend limits and retry rules

Treat the 402 response as priced capability discovery. The client should parse requirements, select a supported network, protect wallet signing material, retry idempotently, and record settlement metadata beside the resulting work.

Design the service to fulfill before settlement where the protocol and operation allow it, and make retries safe. Write operations need an idempotency key so a network retry cannot create two imports, analyses, or charges.

When pay-per-request fits

Good candidates have clear inputs, a predictable maximum price, a bounded output, and no need for lasting account authority. Provider discovery, a one-off public-data calculation, or wallet-owned analysis can fit. Frequent workflows may be cheaper and easier to govern through a subscription and scoped API key.

The agent needs a budget policy before encountering a 402. Define allowed assets and networks, maximum per-call and daily spend, approved service domains, confirmation threshold, and receipt storage.

A payment-aware agent loop

Discover the service, validate its schema and domain, call the route, parse payment requirements, compare them with policy, sign through a protected wallet component, retry, and verify the settlement response. Store the receipt beside the task result.

Reject unexpected price changes, unknown networks, mismatched destinations, or an input schema that differs from discovery. Require user confirmation when the call exceeds policy or sends sensitive data to a new service.

  • Service allowlist
  • Per-call and daily limit
  • Allowed asset and network
  • Human-confirmation threshold
  • Receipt and result retention

Agent payment policy

  • Every spend maps to a named user task
  • Discovery and response schemas are validated
  • The wallet component exposes signing, not seed material
  • New destinations or sensitive uploads require confirmation
  • Retries use idempotency
  • Receipts and task results can be audited together

Expose paid health capabilities through discovery

WellNizz describes selected paid routes through its x402 discovery document and Bazaar metadata. It supports Base, Polygon, and Solana configurations, maps a verified payer to a private workspace, and keeps account administration, direct WGS uploads, exports, deletion, and third-party OAuth API-key-only.

Keep wallet authority narrow and observable

An autonomous payment system can amplify a bad permission model. Set spend limits, monitor activity, and keep personal health data and wallet credentials out of prompts and logs.

Editorial sources

Read the primary guidance

These sources support the technical and health boundaries in this article. Provider prices, availability, and product terms should always be checked at the provider before purchase.

Questions, answered

FAQ

Do x402 agents need an API key?

An enabled pay-per-request route can use the payment flow directly. Routes that need durable user authority still require a scoped account credential.

Why use idempotency with x402?

It lets a retry return the original successful write and prevents duplicate work or charges.