# Should Your Agent Pay via x402? Why Agentic Commerce Needs a Check First > Source: > Published: 2026-09-06 00:00:00+00:00 # Should Your Agent Pay via x402? Why Agentic Commerce Needs a Check First A real scan of 135 x402-payable services from Coinbase's Bazaar catalog shows why 'accepts x402' isn't 'safe to pay' — and how ContextIQ's Policy Check API combines ERC-8004 identity with x402 validation to decide. Agentic commerce is usually described as a stack: **x402** moves the money, discovery layers like Coinbase's Bazaar catalog make endpoints findable, and **ERC-8004** provides on-chain identity and reputation so a payment isn't just money sent to a stranger. [We've written about that stack before](https://contextiq.trango-compute.com/blog/what-is-agent-commerce-x402-erc-8004). What we hadn't done until recently was check whether the stack, as actually deployed today, gives an agent enough to make a safe payment decision on its own. It doesn't — and we have real numbers, not a guess, to show why. ## What We Actually Found We pulled 135 real, live services from Coinbase's own public x402 Bazaar catalog — not a curated "best of" list, a representative sample of what's actually listed as agent-payable right now — and ran them through ContextIQ's own free tools. The results: - **33%** have no SPF record at all. - **63%** aren't actively enforcing DMARC — missing, set to`p=none` , or monitoring-only. - **27%** have zero agent-discoverability signal whatsoever: no`llms.txt` , no MCP, no A2A, no ARD. None of that shows up in an x402 402 response. A service can be fully compliant with the payment protocol — correct challenge shape, valid network, real USDC address — while having no email-spoofing protection and no way for an agent to learn anything about it beyond "send money here." **"This endpoint speaks x402" and "this endpoint is safe to pay" are unrelated claims**, and right now, a meaningful fraction of the ecosystem only satisfies the first one. ## What a 402 Challenge Actually Tells You Read the x402 spec literally and a 402 response is remarkably narrow. It tells you: this scheme, this network, this exact amount, this address, this timeout. That's the entire contract. It does not tell you: - Whether the operator has ever done business with anyone before. - Whether the wallet receiving payment is even the same one the operator's own published identity claims to use. - Whether the challenge itself is internally consistent, or just happens to parse. - Whether the endpoint is reachable at all beyond the single request that produced the 402. An agent that pays as soon as it sees a well-formed challenge is trusting exactly as much as that challenge contains — which, per the numbers above, is often not much. This is the actual gap in "agentic commerce is live": the payment rail works, but the pre-payment judgment call has been left to each agent to improvise, usually by not making it at all. ## How Policy Check Answers It [Policy Check](https://contextiq.trango-compute.com/policy-check) exists specifically to fill that gap, by combining two things ContextIQ already builds independently — [ERC-8004 identity/reputation lookup](https://contextiq.trango-compute.com/erc8004-inspector) and [x402 challenge validation](https://contextiq.trango-compute.com/x402-inspector) — into a single call an agent framework makes right before authorizing payment: ``` curl -X POST https://contextiq.trango-compute.com/api/v1/policy-check \ -H "Content-Type: application/json" \ -d '{"endpoint": "https://api.example.com/paid-resource", "agentId": "1", "network": "ethereum"}' ``` The response is a categorical `allow` / `warn` / `block` decision backed by a transparent 0–100 score — every point traced to a named check, never a black box: - **Identity (30 pts)** — is the counterparty even registered on ERC-8004? Does it have a wallet set, resolvable metadata, and does its own declared x402 endpoint actually match the one you're about to pay? - **Reputation (20 pts)** — how many*distinct* clients have given feedback, not how positive it is. ERC-8004 doesn't standardize a value scale across registrations, so scoring the magnitude of feedback would be fabricated precision; breadth of independent feedback is the signal that's actually comparable. - **Payment (50 pts)** — is the challenge well-formed, free of spec-hygiene warnings, on a recognized network, and — separately — has a*prior* confirmed payment to this exact endpoint ever settled to somewhere other than the declared payTo/amount? That last check is independent of anything the endpoint says about itself: it's read from receipts other callers submitted after actually paying. The `agentId` is optional — omit it and only the payment half is evaluated (identity/reputation are marked "not checked" rather than scored against a fake ID). `block` is reserved for genuine impossibility — an agent ID was supplied but nothing is registered under it, or a target that's actually unreachable — never for "the score was too low." A confirmed prior misdirected payment on the same endpoint also caps the decision at `warn`, regardless of how high everything else scores. Deciding how much reputation is "enough" is the caller's judgment call, not something ContextIQ makes unilaterally on an agent's behalf. [Five real worked examples](https://contextiq.trango-compute.com/blog/policy-check-worked-examples-agent-payment-risk) show exactly what this looks like against currently-registered agents, and a [full technical walkthrough](https://contextiq.trango-compute.com/blog/pay-policy-check-api-x402-technical-walkthrough) covers calling it via x402 payment instead of an API key, if that's the integration you need. ## Where This Sits in an Agent's Decision Loop The intended call site is narrow and specific: your agent framework gets a 402 from some counterparty, and instead of immediately signing a payment, it calls Policy Check with that same `endpoint` plus the counterparty's ERC-8004 `agentId` and `network`. The response's `decision` field is enough to gate on directly — `allow` proceeds to the normal x402 pay-and-retry flow, `block` or `warn` routes to a human, a fallback provider, or just gets logged and skipped. Agents that want finer control can apply their own threshold to `score` and read `reasons` for the specific factors that mattered, rather than trusting a single opaque gate. ## What This Doesn't Solve Worth being direct about the limits, the same way we are about ContextIQ's other inspectors: a `block` on identity means "not registered," not "malicious" — plenty of legitimate services simply haven't registered with ERC-8004 yet. A high reputation score means "many independent clients left feedback," not "verified good," since ERC-8004's Validation Registry — the piece meant to carry independent attestations — has no canonical deployed address yet, so it isn't part of the score. And a clean x402 challenge only means the payment mechanics are sound; it says nothing about whether the resource you're paying for will actually be delivered as described. Policy Check turns "we found real, checkable signals" into a decision you can act on automatically — it doesn't turn those signals into a guarantee. ## Try It The 135-service numbers above and the check itself run on the same free tools — [DNS Inspector](https://contextiq.trango-compute.com/dns-inspector) and [Agent Protocol Inspector](https://contextiq.trango-compute.com/agent-readiness-detector) for the ecosystem scan, [ERC-8004 Inspector](https://contextiq.trango-compute.com/erc8004-inspector) and [x402 Inspector](https://contextiq.trango-compute.com/x402-inspector) feeding directly into [Policy Check](https://contextiq.trango-compute.com/policy-check)'s combined decision. If you're building an agent that pays autonomously, the practical move is wiring Policy Check into the moment right before that payment gets signed — not after something's already gone wrong. Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. [Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)