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.

What is the difference between x402 verify and settle?

In x402 v2, facilitator /verify is read-only: it checks whether a payment authorization is valid but must not commit payment state or write onchain. /settle durably commits payment state for the request according to the payment scheme and flow. A successful verify is therefore not evidence that funds moved.

Can an x402 payment settle successfully if the API response fails?

Yes, depending on the payment flow and application behavior. Settlement and application delivery are separate verdicts. A payment can be committed while the resource later returns an application-level error, so buyers should record settlement evidence and validate the HTTP status, response schema and useful output separately.

Does PAYMENT-RESPONSE prove useful delivery?

No. A successful x402 settlement response is payment evidence, not proof that the purchased result was correct, complete or useful. For important purchases, join the settlement response or transaction evidence to the exact request and separately validate the application response and delivery 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 · updated 12 September 2026

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 — and, after it pays, whether settlement and useful delivery actually happened. Verify the live contract, keep /verify, /settle and application delivery as separate verdicts, then validate the purchased output before reuse.

Published 11 September 2026 · updated 12 September 2026 · sources checked 12 September 2026

402 ≠ trust

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

verify ≠ paid

x402 /verify is explicitly read-only

settled ≠ delivered

Payment finality and application success are separate evidence

The four verdicts

Verify, settle and delivery answer different questions

This is the most useful debugging boundary in x402. The v2 specification says facilitator /verify validates payment state without committing it, while /settle durably commits payment state for the request. The protected application still has its own response and output contract. A buyer should preserve those layers rather than collapsing all of them into one “paid” flag.

Evidence	What it establishes	Record	Do not infer
402 challenge	The resource is quoting payment requirements.	Resource, method, amount, asset, network, payTo, scheme and paymentFlow.	Trust, settlement, independent demand or useful delivery.
/verify	The supplied payment authorization passed a read-only validity check.	isValid, invalidReason and payer where available.	That funds moved. x402 v2 says /verify must not commit payment state or write onchain.
/settle / PAYMENT-RESPONSE	Payment state was durably committed according to the selected scheme and flow.	success, transaction, network, payer and amount where supplied; use ledger evidence when stronger financial finality is required.	That the application result was correct, complete or economically useful.
Application response	The paid resource returned an HTTP/application result.	HTTP status, schema, content, freshness and task-specific acceptance checks.	Payment finality unless settlement evidence is joined to the same request.

Operational wallet tooling now exposes this split directly. Naven, for example, returns x402 payment status separately from the upstream HTTP status and documents that a paid resource can settle successfully while still returning an application-level 4xx or 5xx response. That is one implementation, not a protocol-wide guarantee about every resource server, but it demonstrates why a buyer should track both verdicts.

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.

Separate verify from settle

A valid /verify result is authorization evidence, not payment. Record the eventual settlement response or stronger ledger evidence separately.

Validate the result

Define what a successful response looks like before spending. HTTP status, schema, freshness and deterministic output checks are separate from settlement success.

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.

The same distinction matters for retries. A timeout, missing response header or application error should not automatically trigger a second payment. Reconcile the request identifier, settlement response and ledger state first, then retry only under an idempotent policy that cannot double-pay for the same intended purchase.

Read the x402 v2 specification →

Why the distinction is operational, not academic

Recent implementation reports show how evidence can be misread

An August 2026 x402 Java SDK bug report documented a middleware path that could send protected content before settlement completed. The report was closed after a linked fix, so it should be read as an implementation defect rather than the intended protocol order. For buyers and sellers, the lesson is durable: resource delivery and settlement need explicit sequencing and evidence rather than one optimistic success flag.

A separate open Bazaar provenance proposal reports a verify-only experiment where discovery processing was triggered without tokens moving. The proposal asks catalog data to distinguish verify-derived observations from settled activity. That issue is not a normative specification and its broader catalog implications remain under discussion, but it is another reason not to interpret discovery counters or a successful verify as proof of payment.

Troubleshoot Bazaar indexing →List an x402 API safely →

Verification market · 12 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

after payment:
  record verify_result separately from settlement_result
  reconcile settlement before retrying an uncertain request
  accept delivery only if http_status and output_schema pass

Reputation can improve this policy, but should not replace it. The useful pattern is discover → verify → select → pay → reconcile settlement → 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 →Bazaar indexing troubleshooting →x402 Market Pulse →Know Your Agent →Machine-service catalogue →zFinia x402 metadata →zFinia OpenAPI →

Sources

The x402 specification is normative for protocol semantics. GitHub issues are implementation reports or proposals and are labelled as such above, not treated as protocol requirements. Verification services are independent third parties whose features and pricing can change. zFinia describes public documentation observed on 12 September 2026 and does not represent third-party scoring as a guarantee, certification or substitute for the buyer's own wallet policy.