There are two ways to get an x402 integration wrong, and only one of them shows up in a contract audit.
A contract audit checks the Solidity — reentrancy, access control, overflow. It will not catch the flaws that live in the gap between an HTTP request, a payment proof, and a delivery. x402 couples synchronous HTTP with asynchronous on-chain settlement, and that coupling is its own attack surface. A server can be contract-perfect and still stream output it never gets paid for, or charge a buyer who never receives anything.
We run a production x402 gateway, and we've been writing about this surface for a while — auditing our own facilitator, securing the payment proof, and most recently mapping the four flaw classes from the first systematic security analysis of x402. This post is the consolidation: a **six-category reference checklist** we've published as a public standard, so anyone running an x402 endpoint can audit their own integration the way we audit ours.
The full checklist and methodology are public: github.com/minia2auk/x402-payment-security-checklist.
Before any security question, one liveness question: does the endpoint return a well-formed 402 with a parseable payTo? About 38% of tracked x402 endpoints don't — a dead endpoint has no exploitable payment flow, so it fails here and never reaches a security review. (The widely-circulated "76% dead" figure was a prober bug; the corrected number is 38%, and it's an availability problem, not a security one.)
| # | Category | Who loses | Measured |
|---|---|---|---|
| 1 | Payment verification authenticity — trusting a header without verifying the chain | seller | 100/100 forged (cross-resource substitution) |
| 2 | Replay protection — same txHash consumed N times | seller | ~6% of concurrent rounds |
| 3 | Delivery timing & web↔chain races — delivery before settlement confirms | seller | duplicate delivery; 302-served-without-settle |
| 4 | Allowance / permit2 — max-approval or non-binding allowance check | buyer + seller | 97.76% leakage (allowance overdraft) |
| 5 | Funds & payTo security — honeypot receivers, hijack, self-send | buyer (mostly) | 3 of 5 live-endpoint problem classes |
| 6 | Denial of settlement — rate-limit asymmetry, settle egress throttled | seller | 86.95% → 100% leakage |
Each category in the checklist carries detection questions, a live fix, and the empirical number behind it. Two categories deserve emphasis because they're the ones the ecosystem actually demonstrates:
When someone black-box scans live x402 endpoints, what they find is dominated by receiver-side problems — honeypot payTo addresses (zero/malformed), receiver hijack, and unverified receivers with no on-chain USDC history. Three of the five problem categories in a recent ecosystem audit were receiver security. A buyer-facing audit should start at Category 5, not at reentrancy.
The seller-side failures are quieter and nastier. Under upto dynamic pricing, a non-binding allowance check lets a burst of concurrent requests all pass verification and stream output while only the first few settle — a measured 97.76% leakage ratio. And a settlement egress rate-limited far below request ingress means every request above the limit is served but never paid: 86.95% to 100% leakage. Neither leaves a loud crash; both just drain revenue.
The most useful thing in the checklist is a single label on every finding: payer→resource or resource→payer. Categories 2, 3, 4, 6 are buyers attacking sellers (free-riding, replay, overdraft, settlement flooding). Categories 1 and 5 are sellers cheating buyers (bait-and-switch pricing, honeypot receivers). One is silent seller loss, the other is direct buyer theft — and they are two different audit products with two different audiences. Conflating them is how a "security audit" ends up telling the wrong party the wrong thing.
The checklist is a reference: names the failure class, gives the detection questions, gives the fix, and calibrates severity to a measurement rather than a feeling. It is deliberately not an audit engine — no scanner, no verifier, no PoC harness. The question set and the tooling are kept separate on purpose: a checklist pass is first-pass triage, and deep verification (reproducing the exploit) is a heavier, separate step.
If you run an x402 endpoint, walk your integration through L0 and the six categories. If you're an agent deciding whether to pay someone, the same checklist tells you what to check before your wallet signs. The standard is MIT-licensed and free to use — go take it, run it against your own rails, and tell us what it missed.