How to choose an x402 service before your agent pays

The verification signals

Start with an identifiable provider and source documentation. Next look for a recent automated quote check. Paid-call verification adds evidence that settlement and documented output worked once. Ongoing production trust still requires monitoring, because any endpoint can change after it is verified.

Fit and failure questions

Ask what input is required, whether the call is read-only, what the output guarantees, how timeouts are charged and whether retries can duplicate work. A provider that documents failure semantics is easier to integrate safely than a cheaper endpoint that only advertises a happy path.

The first paid call

Use a representative public input, a dedicated wallet and a cap equal to the inspected quote. Save the requirement, response status, settlement evidence and a small output sample. If any layer differs from the documentation, report the discrepancy and keep the service out of unattended workflows.

Write a one-paragraph service brief first

Before opening a directory, describe the job in operational terms: the input the agent has, the output it needs, acceptable latency, maximum effective cost, privacy constraints and whether the operation may change external state. This prevents a famous provider or low price from defining the requirement after the fact.

For example: "Given a public company URL, return the current company name, headquarters and source links as JSON within fifteen seconds; do not submit forms; spend no more than two cents per company." That brief is specific enough to reject an endpoint that returns uncited prose, even if its payment integration is excellent.

Score candidates on fit, evidence and operating risk

Use a small scoring sheet instead of an overall impression. Capability and output fit should carry the most weight because they determine whether the service can do the job. Evidence covers identifiable ownership, current documentation, exact-route quote checks and controlled paid results. Operating risk covers network support, privacy, latency, error handling and the consequences of a duplicate call.

Do not turn the score into false precision. A missing required capability is a rejection, not a few lost points. Likewise, an endpoint that requires a disallowed network or handles sensitive data in an unacceptable way should not win because it is inexpensive.

Inspect the unpaid response before making a purchase

The initial 402 is the buyer's chance to check the seller's current offer without moving funds. Confirm that the status is actually 402, the requirement uses a protocol shape your client understands and the resource refers to the requested route. Compare amount, network, asset, scheme and destination with the listing and provider documentation.

A mismatch is useful information. It can mean the directory is stale, the provider changed configuration or the buyer reached the wrong route. Record it and stop. Silently coercing a field or substituting a directory price makes the client less interoperable and can authorize something the server did not offer.

Design the first paid test to answer one question

Use a public, representative input whose expected characteristics are known. Fund a dedicated wallet with a small amount, cap the payment at the inspected requirement and call one read-only or idempotent operation. The goal is not to prove the provider is universally reliable; it is to learn whether this exact route settles and returns the kind of output the service brief requires.

Save the sanitized request, payment requirement, response status, settlement evidence, latency and a quality note. A raw 200 status is not enough. If the expected output is structured, validate its schema. If it is research, check whether source links support the answer.

• Use non-sensitive input and a predictable result.
• Authorize no more than the observed requirement.
• Avoid an automatic retry until charging semantics are known.
• Record payment success and output success separately.

Promote gradually into production

After a successful test, begin with limited volume and monitoring. Keep per-request, task and daily caps. Set timeouts and retry rules by failure type. Decide which output checks run before the agent can act on the result, and maintain a fallback for workflows that cannot wait for the endpoint to recover.

Re-evaluate when the provider changes its schema, price, network, facilitator or documentation. A dated verification record should lower uncertainty, not become a permanent badge. For high-impact actions, payment never replaces user confirmation, authorization or a security review.

Red flags that should stop the evaluation

Stop when the provider cannot identify the exact protected route, publishes example inputs that no longer validate, asks for a private key, or changes the destination without explanation. Repeated generic 500 responses and undocumented charges after failed output also make controlled automation difficult.

A young service can still be a good choice, but uncertainty should be visible. Start with narrower permissions and lower budgets rather than filling evidence gaps with optimistic copy.

Related directory entries

Sources and methodology

TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.

1. TOLL·402 verification states — Directory-specific evidence definitions.
2. x402 buyer quickstart — Authoritative buyer implementation.
3. x402 signed offers and receipts — Current extension for signed payment artifacts.
4. x402 rate card — Provider-weighted per-call price benchmarks by capability.