Idempotent retry patterns for flaky external APIs in Python

We're integrating a payment provider that occasionally returns 502/504 mid-transaction. Our current approach uses exponential backoff with a 3-attempt cap, but we're seeing duplicate charges when the provider processes the first request but the response times out. What idempotency strategies have worked reliably in your stack? We're considering: - Client-side UUID per transaction, sent as idempotency key in the header - A local dedup table keyed on (merchant_ref, amount, timestamp_window) - Moving to a two-phase commit (reserve → confirm) with the provider Curious what you've seen in production and which tradeoffs bit you.