What a Payment Endpoint Inspection Can—and Cannot—Prove

"We scanned the endpoint and it looks fine" is a statement about an endpoint. It is not a statement about a purchase. Teams that let AI agents spend money need to know where one ends and the other begins.

This post lays out an evidence ladder. Each rung proves something; none proves everything below or above it.

The ladder

Rung	Question answered	Observable by endpoint inspection?	Typical evidence
1. Endpoint response and protocol signals	Does the endpoint speak the protocol it claims?	Yes	HTTP status, headers, body shape
2. Observable identity information	What does the endpoint publicly say about who runs it?	Partly	Well-known documents, on-chain registry reads
3. Policy findings	Do those observations meet our rules?	Yes, as a function of rungs 1 and 2	Rule results, warnings
4. Transaction-specific approval	Did an accountable party approve this purchase?	No	Approval record in the integrating application
5. Settlement evidence	Did money move, to whom, how much?	No (needs the chain or the PSP)	Transaction receipt, PSP capture ID
6. Fulfillment evidence	Did the buyer get the thing?	No	Order status, delivery confirmation

Rungs 1 to 3: what inspection can see

For an x402 endpoint, rung 1 is the HTTP 402 response. A probe can confirm that the body has the fields the protocol requires (for example payTo, asset, network, and an amount field), that an amount is encoded plausibly for the asset, and that an address is well-formed for its chain. ContextIQ's x402 Inspector does this and also detects whether the body follows the v1 or v2 shape; see x402 v1 vs v2.

Rung 2 is whatever the endpoint publicly claims. For an ERC-8004 agent that is registry data; the ERC-8004 Inspector reads owner, agent wallet and metadata, and frames them as "trust signals found," not a trust verdict. For an OAuth-protected MCP server it can be protected-resource metadata, which the Agent Protocol Inspector detects.

Rung 3 turns observations into findings: "payment challenge is well-formed," "no registered identity supplied." That is the endpoint-analysis boundary: ContextIQ analyzes the payment endpoint, not the payment request an agent would send.

Illustrative inspection report

Illustrative and fictional. The host, values and wording below are invented to show the shape of a report. This is not a real scan.

Target:        https://api.example-vendor.test/reports/summary
Probe:         GET → 405, then POST → 402
Protocol:      x402 (v2 shape)
Fields:        scheme, network, amount, payTo, asset: present
Network:       eip155:8453 (recognized)
Address check: payTo well-formed for network
Warnings:      none
Not checked:   facilitator reachability, live settlement,
               the contents of any payment request

The last line matters as much as the others. A report should list what it did not look at.

Why a probe can mislead

Point in time. A 402 challenge today says nothing about tomorrow's.
Request-dependent responses. An endpoint may price or route differently by path, method, headers or caller. One probe samples one request.
Method fallback. x402 commonly gates POST-only resources, so a GET returning 405 is not a verdict.
Identity is a claim. A registry entry or metadata document tells you what was published, not that the operator is who a buyer assumes.
Dishonest or buggy endpoints can return a perfect challenge and settle elsewhere. Only rung 5 catches that.

Rungs 4 to 6: what has to come from elsewhere

Approval (rung 4) lives in your application. The OpenAI controlled-commerce cookbook shows an application checking merchant, purpose, amount and approval before a payment can occur. That is a documented example of the pattern, not something an endpoint scan produces.

Settlement (rung 5) needs downstream evidence. For x402 USDC payments on Base, ContextIQ's Pro-tier Agent Commerce Gate has a receipt endpoint that checks a settlement transaction against the chain and compares it with the declared payTo and amount. That covers x402 settlements it can read from the chain; it is not a general payment-verification service, and it does not cover card or PSP flows.

Fulfillment (rung 6) belongs to the merchant. In OpenAI's checkout spec that surfaces as order status events and refund history sent by the merchant. An inspection of the payment endpoint cannot see it.

Reading a report responsibly

Treat an inspection as a filter before payment, not as a receipt after it. A clean report lowers the odds of a malformed or misconfigured payee. It does not show that a specific purchase was approved, paid or delivered.