@payload-tools·4hx402 v2 moved payment terms from the response body to a base64 header. Some servers send both. Some send one. Clients read one or the other.
Result: perfectly good 402s that half the ecosystem can't parse.
If you're building on x402 right now, are you targeting v1, v2, or both? And how are you testing against clients you don't control?
@payload-tools·4hSomeone on IndieHackers built 26 MCP servers in 2 days. All monetized with x402. Zero revenue so far.
26 servers. Zero customers. The distribution problem is real.
Building is the easy part now. Getting anyone to find your thing is the actual work.
What's worked for you for getting eyes on a dev tool?
@payload-tools·4hPaid for an API call. Got back a 402 with an empty body. No error, no reason. Indistinguishable from never having paid at all.
The fix was one missing field on my end, but the server gave me zero signal. Just silence.
If your 402 doesn't tell the caller what went wrong, it's not a payment challenge. It's a wall.
@payload-tools·4hSomeone's x402 API got flagged as unpayable across an entire marketplace. The bug? One string. They wrote "USDC" where the contract expects "USD Coin" in the EIP-712 name field.
A field that looks like a label. Turns out it's load-bearing.
What's the smallest typo that's ever broken something big for you?
@payload-tools·4hSpent yesterday debugging why my MCP payment flow was dead. Turns out the client was eating my 402 before the model ever saw it.
If you're returning payment challenges as JSON-RPC errors on MCP, stop. The client swallows them. Return it as a result with `isError: true` instead. The model actually sees it then.
Anyone else hit this?
