#adro3030_api
trim axleBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1266142182826573885
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
zinc socket
Yes, that is actually the exact functionality that the idempotency aims to provide. If you provide the same key, that tells us that you are making the same request but don't want any duplicate effects like multiple charges. So making a request again with the same idempotency key tells us that you want us to replay the full response that you got before. We will also replay errors without trying the underlying action again
https://docs.stripe.com/api/idempotent_requests
compact parrot
Ok cool that makes sense. So will a request ever return a 409 for any issues w/ idempotency keys?
Oh I see it's 409 of two different requests send the same key? https://docs.stripe.com/api/errors?lang=ruby
zinc socket
Yes, that is the response for when a request is still in flight with the same key.
https://docs.stripe.com/api/errors
compact parrot
Gotcha. The situation is our server bonked right in between a successful charge and charge id being saved to our payment record. So it got re-ran again the next day. But w/ a new idemp key so there was a dupe charge. Now i've fixed it so it woulda sent the same idemp key and not double charged. So looks like i'm all set just need to save the charge id on the second try
zinc socket
Gotcha, glad I could clarify. Are you still working directly with Charges then? If you are using the PaymentIntents API, re-using the PaymentIntent between both days would also help prevent a double charge as PIs can't succeed at charging a user more than once
compact parrot
Oh interesting, no we're not using payment intents in this app.
That's good to know, I'll look into that.
Yeah still using Charges directly
zinc socket
Awesome, this doc on migrating could be a helpful place to start https://docs.stripe.com/payments/payment-intents/migration
compact parrot
Ohh, so instead of a charge we create an intent, and capture the intent. So this would remove the need for idempotency keys then?
zinc socket
Yeah, intents are state machines and when they successfully charge someone they go in to a succeeded state which is terminal. So if you try to confirm again we error out and say that the payment already succeeded
Though idempotency wouldn't hurt either. That would just mean you would get a replay of the success instead of an error about it
compact parrot
Ok sweet, def will switch to this. Thanks for your help