How should API idempotency be designed to avoid duplicate submissions and duplicate charges?

I learned the hard way when I was working on payment and order APIs. I had implemented debouncing on the frontend buttons and rate limiting on the gateway, but when the user's network flickered, retry requests still pushed the same transaction through. I later realized that debouncing only reduces duplicate clicks; the real safety net is backend idempotency. When I build these types of APIs now…