How do I verify an x402 API before paying?

Resolve the endpoint directly, inspect its live HTTP 402 challenge, confirm the resource and method, price, asset, network, payee and payment flow, compare those terms with the service's owned machine-readable contract, then apply bounded-wallet and output-validation rules. Third-party reputation or settlement-history services can add evidence but should not replace the live contract.

Does an HTTP 402 response prove an API is trustworthy?

No. A 402 response proves that an endpoint is asking for payment. It does not by itself prove that the seller is reputable, the price is normal, the payee is expected, the output will be useful, or the service has delivered successfully to independent buyers.

Does x402 always settle after the API returns its result?

No. The x402 v2 specification defines authorization, upfront and escrow payment flows. Authorization is the default flow and orders verify, resource execution, settlement and response. Upfront and escrow can commit value before resource execution, so buyers should inspect paymentFlow rather than assume one settlement order.

Can an AI agent automatically check an x402 service before paying?

Yes. An agent can automate endpoint, schema, challenge, price, payee and policy checks, and can query third-party verification services for additional evidence. The final spend decision should still be bounded by explicit wallet limits and a known output contract.

Editorial

Research guide · x402 buyer safety

How to verify an x402 API before paying

Machine-readable discovery makes it easy for an agent to find something that asks for money. The harder question is whether it should pay. Verify the live contract, the settlement flow, the seller evidence and the expected output before a wallet signs anything.

Published 11 September 2026 · sources checked 11 September 2026

402 ≠ trust

A payment challenge is a quote, not proof of seller quality

3 flows

x402 v2 defines authorization, upfront and escrow

Fail closed

Unexpected price, payee, network or schema drift should stop the spend

Buyer checklist

Seven checks before an autonomous x402 spend

Resolve the exact resource

Call the canonical endpoint and HTTP method directly. Redirects, dead routes and stale directory URLs are reasons to stop before payment.

Read the live 402

Treat the current PaymentRequired challenge as the payment contract: resource, amount, asset, network, payee and any declared payment-flow fields.

Check the payment flow

x402 v2 can use authorization, upfront or escrow. Do not assume value moves only after useful output; inspect the offered flow and reject one your buyer does not understand.

Compare price and payee

Compare the live amount and receiving address with the provider's owned OpenAPI, x402 manifest or other canonical metadata. Unexpected drift should fail closed.

Look for independent evidence

Liveness, recent successful delivery, distinct paying wallets, settlement history and anomaly checks can improve confidence. They are evidence, not guarantees.

Validate the result

Define what a successful response looks like before spending. Schema checks, freshness requirements and deterministic validation make a paid response easier to accept or reject.

Cap the wallet

Set per-call and session limits, allowlisted networks/assets and a maximum acceptable price. Discovery should never imply unlimited authority to spend.

The protocol detail that matters

Do not assume every x402 payment settles after delivery

The x402 v2 specification distinguishes three payment flows. In the default authorization flow, the facilitator verifies first, the resource executes, settlement follows, and the response is returned. The specification also defines upfront and escrow flows that can commit value before resource execution.

That changes buyer risk. A wallet-equipped agent should inspect paymentFlow, understand the mechanism it is being offered, and skip combinations it does not support. The specification says clients should prefer authorization when the same request offers both authorization and a pre-handler-settlement flow.

Read the x402 v2 specification →

Verification market · 11 Sep 2026

A new verification layer is appearing around machine payments

Several independent services now target the same buyer question: should an agent trust this paid endpoint enough to spend? Their methods differ. Some inspect the payment payload, some use on-chain or liveness evidence, and some buy the service to test fulfillment. zFinia has not independently benchmarked their proprietary scoring, so the table describes their current public claims rather than endorsing a winner.

Service	What it checks	Current public model
Paddock	Endpoint, expected price, liveness, observed payer activity and circular-pattern checks	Its public verify-before-pay example returns a verdict before the buyer commits. Paddock says its free-key tier includes 10 checks per day and also offers pay-per-call access.
vet402	Independent fulfillment measurement based on actually buying x402 endpoints	Its public methodology says it buys what endpoints sell, checks fulfillment against the seller declaration and publishes evidence. The service describes itself as building in public.
Faro	Pre-payment verdict from raw x402, AP2 or ACP payment context	Its documentation says the verifier is advisory only: it does not settle, authorize or move funds. That separation is useful when the buyer wants a policy gate before payment execution.
PulseFeed	Liveness, payment anomaly and receiver-profile checks	Its public trust API describes checks including payTo hijack, price bait-and-switch and on-chain receiver signals. Treat its proprietary verdict as one input rather than a universal trust score.

What a verifier can tell you

• whether the resource is reachable now;
• whether the quoted price or payee looks anomalous;
• whether there is observed settlement or delivery evidence;
• whether the payment payload matches a policy;
• whether known risk signals justify rejecting the spend.

What it cannot guarantee

• that a future call will return a useful answer;
• that historical payers were economically independent;
• that a seller will never change price or behavior;
• that one proprietary reputation score fits every buyer;
• that the agent should exceed its own explicit spend policy.

Minimal policy

A buyer should be able to reject a service deterministically

allow only if:
  endpoint == expected canonical resource
  network in approved_networks
  asset in approved_assets
  payTo in expected_or_verified_payees
  quoted_price <= max_price_per_call
  payment_flow in supported_flows
  response_schema is known
  requested_action is within session_spend_cap
otherwise: do not sign

Reputation can improve this policy, but should not replace it. The useful pattern is discover → verify → select → pay → validate delivery → record evidence → reuse only when the result justifies it.

Continue the research

Move from discovery to a bounded buying decision

zFinia tracks x402 discovery, payment infrastructure and machine-readable services. Use the discovery guide to find candidates, then inspect the owned machine contract before an agent spends.

Find x402 APIs →x402 Market Pulse →Know Your Agent →zFinia x402 metadata →zFinia OpenAPI →

Sources

Verification services above are independent third parties. Their features and pricing can change. zFinia describes public documentation observed on 11 September 2026 and does not represent third-party scoring as a guarantee, certification or substitute for the buyer's own wallet policy.