[jtsiskin]

Sounds very much Uber’s fault, although there is not quiet enough information. It’s perfectly reasonable for a payments API to return “error: not enough funds” on the first call and “error: rate limit exceeded” on the second. This just reads as a desperate attempt to pass on the blame

[thundergolfer]

The ex-Uber author is using a loose or colloquial definition of idempotency, which is concerned with getting an identical response across calls (implying something about system state changes that produce the responses). But the API providers may consider their system still idempotent because the HTTP response is not considered part of their ‘system state’ and so the response changing across calls is not relevant. What’s relevant is the payment provider’s internal system state being invariant across 1-N calls. They may claim “this is idempotent because it’s safe to retry repeatedly” without making the claim that the error code is identical each call.

[mytailorisrich]

Repeated failures with the same error code is not idempotency even using a loose or colloquial definition, which at some point means nothing at all beyond getting the same result when trying the same thing multiple times (of course you do, it fails!)