Knowledge Base · Payments & x402
Verifying payments without trusting the client: what an ERC-20 transfer log actually contains
The symptom
On one service, payments were never recognised on the EVM chain although the identical flow worked on Solana. On another, a single payment could be spent again and again.
What was actually wrong
Two facts about token transfers: an ERC-20 Transfer event is emitted by the token contract, so filtering the event log by the recipient's address returns nothing, ever; and a payment is only a payment when it is bound to a payer, a recipient, an amount and a token — and is usable exactly once, which requires recording the transaction hash.
The fix
One shared verification module now builds the log filter correctly (token contract as the address, the Transfer signature as the first topic, the recipient as the third — plus the payer when known), re-checks recipient, sender, token and amount locally on every returned log rather than trusting the node to have honoured the filter, and claims each transaction hash once in a durable store so a replay cannot double-credit.
What we took away
On-chain payment code fails closed and fails quietly. Write the matcher once, test it, and never hand-roll it per service: the same mistake was made twice by two different people on two different days.