When an agent pays an API it has never met before, it is really answering one question twice. First: is this specific request safe to pay right now? Second: has this seller been trustworthy in the past?
Those are two different questions, and they have two different answers. The x402 ecosystem is quietly splitting along exactly this line, and most of it is only answering the second question.
There are now two trust models in machine payments, and they operate at different moments in the flow.
| Model | When it runs | What it establishes |
|---|---|---|
| Post-payment reputation | After settlement | A signed receipt feeds a seller score — "this seller settled N times, on time, for M buyers." |
| Pre-payment verification | Before you sign | The 402 challenge is checked — payTo matches who you think you're paying, amount matches the advertised price, scheme is one you can actually settle. |
Post-payment reputation is the common one. It is cheap to build — you append a receipt to every settlement and aggregate them. It is also genuinely useful: a buyer choosing between ten sellers wants to know which ones have a settlement history at all.
But it answers yesterday, not now. A score tells you the seller was fine last week. It does not tell you that the payTo address in this particular 402 challenge is the seller's, and not an intermediary's.
In x402, the payment flow begins with an HTTP 402 response carrying a signed challenge — the amount, the payTo address, and the accepted settlement schemes. Everything downstream of that challenge is scriptable. An agent reads it, signs it, and settles it without a human in the loop.
That means the challenge is the one point where a machine can be misdirected before money moves. Three concrete failure modes live entirely inside the challenge:
Wrong payTo. The challenge advertises an address that is not the seller's — an intermediary, a reseller markup, or an outright spoof. A reputation score for "the seller" does not flag a challenge that never belonged to the seller in the first place.
Price drift. The catalog said $0.05; the challenge says $0.50. The agent that signs without re-reading the challenge pays ten times what it was told.
Unsettleable scheme. The challenge lists a network or asset the buyer cannot settle on. The payment stalls, and the buyer has to discover that after the fact.
None of these is caught by a receipt that is only generated after a successful settlement. By construction, post-payment reputation only observes the transactions that already went right. The transactions that went wrong never produce a receipt, so they never enter the score.
Pre-payment verification is a check on the challenge itself, before signing: does payTo match the seller you intended, does amount match the advertised price, is the scheme one you can settle? It is not a score — it is a gate.
It is rarer because it is harder to build. It has to run inside the agent's payment step, before the signature, on every call. A reputation score can be computed asynchronously, in a batch, after the fact. A pre-payment check has to be correct on the cold path, where a false positive costs a real failed payment and a false negative costs a real misdirected one.
That is the same asymmetry as the accounting problem in machine payments: the honest number is the harder one to produce, and the easy number is the one that inflates. I wrote earlier about settle-only accounting — counting a transaction only when a chain-confirmed transfer matches the advertised amount. Pre-payment verification is the security half of the same discipline. Settle-only accounting asks, after the fact, "did a real transfer happen, for the right amount?" Pre-payment verification asks, before the fact, "is this the transfer I'm about to authorize?"
The raw scale of the x402 ecosystem is real and growing: a single public discovery API currently indexes on the order of 14,000 listings across roughly 1,900 distinct hosts. That is a lot of endpoints an agent can pay. It is also a lot of challenges no human will ever read.
The number that matters is not the listing count. It is what fraction of those endpoints an agent can pay safely — with the challenge verified before the signature. Right now, most of the tooling in the ecosystem produces the after-the-fact receipts. Far less of it does the before-the-fact check. That gap is the difference between "a marketplace of 14,000 endpoints" and "a marketplace of 14,000 endpoints you can actually pay without reading every challenge by hand."
We run a live gateway, so we see this from both sides of the counter. We publish a pre-payment payment-security checklist and a verify endpoint that checks the 402 challenge before a buyer signs. We also report our own settlement numbers the settle-only way — chain-confirmed transfers matched to the challenge, not a total-requests figure inflated by bots and self-polling. Both halves are the same idea, applied at two different moments: verify before you pay, and count only what actually settled.
If you are building an agent that pays for APIs, adopt the pre-payment half today, independent of any platform: re-read the 402 challenge before you sign it, check payTo against the seller you intended, check amount against the price you were shown, and refuse schemes you cannot settle. It is the one check that a reputation score cannot do for you, because a reputation score only ever sees the payments that already worked.