#axiosz
frosty zealot
hello! https://stripe.com/docs/api/idempotent_requests
Stripe's idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result, including 500 errors.
idempotency keys are really meant for network failures
e.g. preventing double charges in cases of poor network conditions.
They allow you to safely retrying requests without accidentally performing the same operation twice
you'll want to create a new request (with a different idempotency key) if you a get insufficient funds error
jagged radishBOT
ripe wraith
Thank you for the quick response!
Is there maybe another way to support both prevention for duplicate payments and also retry in case of previous failures, outside of using idempotency keys?
or do we have to implement this prevention net in the client that is issuing the requests to stripe
nimble flame
If the issue is specific to Transfers and insufficient balances then the recommendation is to use the source_transaction parameter: https://stripe.com/docs/connect/charges-transfers#transfer-availability
Idempotency is for use with server/API errors (5xx responses)
ripe wraith
Specific to transfers but not only insufficient balances errors
maybe the target connected account is not fully onboarded, or it became restricted etc
nimble flame
The same applies – idempotency is not relevant here
ripe wraith
Ok. So the recommendation would be for the clients to implement these safety features which support retry since there is no Stripe feature yet that support this usecase
nimble flame
Correct, yes. You should handle 4xx errors like you describe in your integration. There's no retry mechanism for them
ripe wraith
understood. thank you for the support @nimble flame 👍