x402 isn’t good (yet) — Jan Curn, Apify
x402 servers can perform work before payment settlement, leaving a double-spend window. Builders should settle first or accept explicit counterparty risk until stronger schemes mature.
In the described x402 flow, a server verifies a signed payment before blockchain settlement. A client can reuse the same funds to create **1,000 signatures**, leaving providers unpaid after doing work; x402 also expects **HTTP 402** where MCP authentication expects **HTTP 401**.
For work with meaningful marginal cost, settle before execution or reserve funds first. If pricing is variable, account for the extra latency, fees, and trust introduced by charging a maximum and refunding the remainder.
In the described x402 flow, a server verifies a signed payment before blockchain settlement. A client can reuse the same funds to create **1,000 signatures**, leaving providers unpaid after doing work; x402 also expects **HTTP 402** where MCP authentication expects **HTTP 401**. For work with meaningful marginal cost, settle before execution or reserve funds first. If pricing is variable, account for the extra latency, fees, and trust introduced by charging a maximum and refunding the remainder. Coinbase's **batch settlement** escrows funds and signs micropayments off-chain, but Apify had not implemented it at the time of the talk. The ecosystem was described as early, with roughly **$1 million per month** in transaction volume.
This narrows payment-gateway optimism by identifying a settlement-order flaw beneath model policy and wallet budgets: valid signatures can authorize costly work without guaranteeing providers receive funds. It also exposes an x402–MCP status-code mismatch. Reservation, prior settlement, or explicit counterparty risk is therefore a protocol prerequisite, not an agent prompt improvement.