Bugs from building payment infrastructure for AI agents from scratch

This is a firsthand account of building payment that lets AI agents buy things. Today's checkout systems assume a human is behind every request, so CAPTCHAs, , and fraud models either block legitimate agents or wave through real bots. To understand the problem properly, the author built the whole stack from scratch: cryptographic identity for agents, set by the agent's owner, , settlement, and refunds.

The fake settlement layer was then removed and replaced with a connection to the real x402 network on the testnet, putting the identity layer in front of actual on-chain payments. Two bugs stood out. First, the replay-protection logic rejected the author's own legitimate payment: the x402 flow involves two requests (an initial one that returns a payment-required response, then a retry with payment attached), and because the verifier burns a one-time nonce per request, the retry looked like a duplicate of the original purchase.

Neither component was wrong on its own — the bug lived in the seam where the two were combined. Second, using floating-point math for money caused a spending check to print a value like '147.20000000000002 + 7.8 > 150', a number that came from floating-point rounding error rather than any input a human typed.

Key points

  • Covers the structural mismatch where checkout systems built for humans either block legitimate AI agents or let malicious bots through
  • Built agent payment from scratch: cryptographic identity, owner-set , , settlement, and refunds
  • Connected the system to real on-chain payments via the x402 protocol on the testnet
  • Found that mistook a legitimate payment retry for a duplicate attack — a bug caused by combining two correct , not either one alone
  • Demonstrated that using floating-point arithmetic for money can break spending-limit checks due to rounding error
Read original