x402 quote checked vs paid-call verified
The exact difference between observing a valid 402 requirement and proving settlement plus useful output.
DIRECT ANSWER
Quote checked means an unpaid request reached the endpoint and returned a usable x402 payment requirement. Paid-call verified means a reviewer authorized the payment, confirmed settlement and checked that the endpoint returned the documented result. A quote check is cheaper and scalable; paid verification is stronger but narrower evidence. Neither is a permanent uptime guarantee.
Key takeaways
- Provider-reported live status is weaker than a current quote check.
- A 402 quote proves a payment wall, not the quality of the paid output.
- Verification dates must remain visible because stale badges create false confidence.
What an unpaid quote check proves
The checker reaches the exact advertised endpoint with its safe method and observes payment requirements. TOLL·402 requires HTTP 402, a numeric x402 version, version-correct amount and resource fields, a positive atomic amount, a numeric timeout, payment destination, asset, network and a resource URL that matches the requested route. It records the requirement and date, but does not sign a payment or assert that the provider would return useful output after settlement.
What a paid-call check adds
A paid verification chooses a non-mutating representative operation, authorizes a bounded payment and checks the successful response against documented behavior. Where available, settlement or receipt evidence is retained. The reviewer should avoid publishing sensitive wallet or response data.
| State | Payment made | Output checked | Scalable |
|---|---|---|---|
| Provider reports live | No | No | Yes |
| Quote checked | No | No | Yes |
| Paid-call verified | Yes | Yes | Limited |
Badge maintenance
A verification badge should include its date and be removed or downgraded when later checks fail. Automated quote checks can run more often than paid calls. TOLL·402 keeps these fields separate so a failed liveness check does not rewrite historical evidence, but it does change what buyers see now.
A concrete example of the difference
Suppose a weather endpoint returns HTTP 402 with a valid requirement for $0.001 in USDC on an allowed network. A quote check can confirm the route, price requirement, destination and protocol shape without signing anything. It cannot tell whether the paid response contains current weather, a stale demo object or an internal error wrapped in a 200 response.
A paid-call review continues from that same requirement. The reviewer authorizes the bounded amount, confirms the settlement outcome and compares the response with the documented weather schema. If the endpoint returns the expected city, conditions and timestamp, the test adds evidence about product delivery. It still says only what happened for that route, input and date.
How strict quote validation prevents misleading passes
A checker should not award a pass simply because the status code is 402 or the body contains the word payment. The requirement has to be machine-readable, internally consistent with its protocol version and bound to the requested resource. Amounts must be positive and interpretable in the advertised asset, and the destination, network and timeout fields must be usable by a client.
Strictness produces some failures that a permissive client might coerce. That is intentional. If a server sends mixed v1 and v2 fields or a numeric value as an unexpected type, different clients may interpret the offer differently. Marking the quote invalid gives the provider a clear interoperability problem to fix instead of hiding it behind one tolerant implementation.
- Exact requested method and URL
- HTTP 402 with a supported, decodable requirement
- Version-correct resource and amount fields
- Supported scheme, network and asset identifiers
- Usable destination and timing constraints
Why a valid service may not receive an automated quote check
Automated checking stops at safety boundaries. A POST route may create a job, send a message or mutate data even without payment. A path containing an unresolved customer ID cannot be called honestly with a guessed value. A host that resolves to a private address should not be reached by a public crawler. These routes are not safely testable, which is different from invalid.
Other results are genuine but time-sensitive failures: a timeout, DNS problem, non-402 response or malformed requirement. The status should retain the reason and date so a provider can distinguish a skipped route from a broken one and request an appropriate review.
| Outcome | Interpretation | Next step |
|---|---|---|
| Confirmed | Exact route returned valid requirements | Consider a controlled paid test |
| Invalid 402 | Payment response failed protocol checks | Fix requirement shape |
| Non-402 | Route did not present an x402 offer | Check method, path and deployment |
| Not safely testable | Automation would need unsafe or invented input | Use human-controlled verification |
| Unreachable | Transport failed | Repair DNS, TLS or availability |
What a responsible paid-call review records
The review starts with a public, non-sensitive and preferably read-only input. It records the exact requirement selected, caps the amount, uses a dedicated wallet and avoids broad retry behavior. After the call, it retains settlement or receipt evidence where available, response status, media type, latency and a concise statement of whether the documented output was observed.
It should not publish private keys, reusable signatures, wallet balances or sensitive response data. A result can be payment-successful and product-unsuccessful, and the record needs to preserve both facts. Otherwise a settlement receipt can be mistaken for proof that the service delivered useful work.
How often should verification be refreshed?
Quote checks can run more frequently because they do not move funds and can be applied to many safe routes. Paid calls should be targeted: new high-interest listings, services whose output contract changed, or routes important enough to justify the cost and review. The right cadence depends on how quickly the provider changes and how much buyers rely on the signal.
A new failure should update the current state without erasing historical evidence. Showing both the last successful verification and the latest failed check tells a more useful story than a permanent badge or a blank slate. Buyers can see that a route once worked but should not be trusted now without another test.
Which signal should a buyer use?
Use a quote check to confirm that a route currently speaks x402 and to inspect the offer before funding a test. Use paid-call evidence when output quality and settlement are important to the decision. For production, add your own monitoring and task-specific validation; directory evidence reduces uncertainty but cannot operate the service for you.
The absence of paid-call verification is not proof that a service is bad. It means the stronger test has not been recorded. Adjust the initial budget, permissions and review accordingly instead of turning missing evidence into either an endorsement or a rejection.
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.
- TOLL·402 verification methodology — Public definitions for quote checks, paid calls and dated evidence.
- x402 signed offers and receipts — Protocol extension for verifiable payment artifacts.
- x402 client/server concepts — Authoritative payment flow.