What's your idempotency-key TTL — and what broke when you got it wrong?

Quick one for the payments / API engineers in here.

Idempotency keys are one of those features where "we have them" hides a lot of variance. The piece nobody agrees on is the TTL.

I've seen production systems run with:

• 1 hour — fine for browser checkout, breaks the moment a mobile app retries from an offline queue 2 hours later.
• 24 hours — the default-ish answer, fits an end-of-day reconciliation cycle.
• 48–72 hours — server-to-server with human-in-the-loop retries.
• 7 days — usually because someone got burned once and didn't want to pick a new fight with finance.

The honest heuristic I keep coming back to: TTL ≥ your longest legitimate retry path, and < your reconciliation window. Anything tighter and a real retry lands after the key has expired (double charge); anything looser and you can't close the books cleanly.

So — two questions, looking for war stories more than theory:

1. What TTL do you run, and what's the use case it's tuned for?
2. Have you ever had a duplicate transaction (or a near-miss) because the TTL was wrong? What did the post-mortem land on?

(If you're using idempotency keys without a body fingerprint, that's a different conversation, and worth its own thread — same key + different body is a quiet way to get the wrong thing accepted.)

I'm collecting answers for a follow-up post on idempotency patterns in payment APIs — happy to credit anyone who shares a story. Comments below 👇

---

Author: payments engineer at PaynetEasy — we build payment orchestration and global payouts infrastructure.