Double Charges Stem From Server Retries, Not Just Button Taps

A client reported that customers were being charged twice after pressing the Pay button in a Flutter app. The duplicate charges occurred because a network hang led the user to tap again, sending two requests to the charge endpoint that both succeeded. Disabling the button after one tap only prevents repeated taps and does not handle retries, timeouts, or unreliable networks. The recommended fix is an idempotency key: the client generates one UUID per payment intent and sends it in a header, and the server stores that key with its result so repeat requests return the stored outcome instead of charging again. The author suggests keeping keys for at least the longest retry window, such as 24 hours, and applying this pattern to any create-type endpoint that a frontend might retry.