Why your crypto checkout only needs one wallet address

Why your crypto checkout only needs one wallet address I run a small store that sells digital goods. For two weeks it accepted exactly one thing: BEP20 USDT on BSC. Technically the payment flow worked — the RPC was healthy, the watcher was armed, orders were quoted correctly. Zero sales. Twenty-three inquiries, four of them reached the payment page, and all four left at exactly the same step: the moment they saw the payment screen. It took me an embarrassing amount of time to understand why. The buyers had money. They just didn't have money on that chain. One had USDC on Base. Another had USDT on Ethereum. A third had something on Polygon. Every single one of them would have paid instantly if the checkout had said "USDC on Base" instead of "USDT on BSC". So I rebuilt the rail. One wallet address, six chains, two stablecoins, eleven ways to pay. This post is what I learned doing it, including the four things that cost me real debugging time. The insight that makes it simple The obvious approach is wrong. If you support six chains, you might think you need six sets of order numbers — one per chain — so you can tell which payment belongs to which order. You don't. The amount is the identity. The chain is just transport. When an invoice is created, give it a unique micro-amount. Not 19.00 — 19.13. The buyer is asked for exactly 19.13 in USDT or USDC, on whichever chain they like. Your watcher scans every enabled chain for Transfer events addressed to your wallet, and matches on the amount. Two orders can never share an amount, so there's no ambiguity. The buyer never has to tell you which chain they used. And adding a seventh chain requires zero changes to the order model — you just watch one more chain. The one thing you must get right: uniqueness has to be enforced globally across all pending invoices, and it has to be enforced before you issue the invoice, not after. What the transfer event actually looks like ERC-20 and BEP-20 share the same event signature: topics[0] = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef topics[1] = the buyer topics[2] = you (padded to 32 bytes) data = amount, in the token's base units Filtering by topics[2] is not an optimization. It is the difference between a working watcher and one that melts your RPC provider. On BSC, a 200-block window carries roughly 7,600 Transfer events across all of USDT. If you pull every transfer and filter client-side, you download all 7,600 to find the zero that are yours. Filter server-side and you get an empty array in 200ms. const TRANSFER = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'; const pad = a => '0x' + a.toLowerCase().replace(/^0x/, '').padStart(64, '0'); const logs = await rpc('eth_getLogs', [{ address: tokenContract, fromBlock: '0x' + from.toString(16), toBlock: '0x' + to.toString(16), topics: [TRANSFER, null, pad(myWallet)], //