SECURITY · 31 JULY 2026

x402 security: the payment failure modes every implementation should test

x402 turns an HTTP 402 into a real payment. When the implementation is wrong the request usually doesn't crash — it quietly settles the wrong way, or unlocks a resource nobody paid for. These are the failure modes worth testing before they become incidents.

1. Payment bypass — the critical one

The worst failure is also the simplest: a resource that unlocks whenever a PAYMENT-SIGNATURE header is merely present, without cryptographically verifying it. An attacker sends arbitrary bytes and gets the paid content for free. This is a fail-open bug, and it is a direct revenue leak.

Test it by submitting one intentionally invalid signature and asserting the endpoint fails closed — it must return 402 or 400, never 200. A pass here should be non-negotiable on every release.

2. Weak payment-to-resource binding

An x402 PaymentRequired object advertises a resource.url. If the server doesn't bind the payment to that exact resource, an authorization issued for a cheap endpoint can be replayed against an expensive one. Verify that resource.url matches the protected URL exactly — path and relevant query included — and that a payment for one resource cannot unlock another.

3. Price and recipient drift

The payTo and amount fields decide who gets paid and how much. If they change between identical requests — or drift away from the values you reviewed — funds can be silently redirected or customers overcharged. Pin the allowed recipients and a maximum price, and diff every response against them. A recipient that changes without a deploy is a red flag, not a feature.

4. Protocol drift

Schema and version changes (an x402 v1 object where you expect v2, a new required field, a renamed key) break integrations without an obvious error. Validate every response against the official x402 schema and your target version, and treat a silent shape change as a regression — because to your users it will look like a mysterious payment failure.

5. Freshness and replay

Authorization windows (validAfter / validBefore) that are too wide, or nonces that can be reused, widen the replay surface. Keep windows as tight as settlement allows, and confirm the payment terms don't mutate across identical unauthenticated requests. Stable terms are a prerequisite for reasoning about replay at all.

6. Verify / settle inconsistency

A facilitator's /verify endpoint should reject an invalid signature. If it returns isValid: true for an all-zero signature, verification is broken upstream of your resource — and every downstream control inherits the flaw. Test the facilitator directly, not just the resource server. The two can disagree, and that disagreement is exactly where money goes missing.

None of these checks require a wallet, a private key, or moving a single cent. They are deterministic tests you can run in CI on every release and, ideally, continuously in production. That is precisely what Settlens was built to do — and the practical testing checklist walks through how to run each one.