#warrenn1_api
jovial forgeBOT
👋 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/1298004602133811303
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
jade prawn
Hello, in our API idempotency keys are only associated with API calls themselves, not the objects that they interact with. Can you tell me more about which part of that process you are trying to make more idempotent?
https://docs.stripe.com/api/idempotent_requests
mild urchin
If I submit a payment intent. I want each active order to only ever submit one payment intent.
jade prawn
Gotcha, in that case idempotency on the payment intent creation call may help, that being said our idempotency keys only last for 24 hours, so our API's idempotency alone wouldn't be a foolproof way to prevent that issue.
So one way or another it would be a good idea to add functionality on your side to associate each order with a payment intent and check if one has already been created before making the API call to create one.
mild urchin
How would you suggest dealing with this?
Let’s say I submit something to stripe it gets stuck in your guys’ queue. I query for the payment, it does not exist, so I send in another request.
jade prawn
We don't have a queue like you describe. The only time that your integration should treat a payment intent creation as indeterminate is if you get a 500 response from the API call to create a PaymentIntent. 500 errors indicate that something went wrong on our side where we aren't sure of the outcome when we return the response from the API. Other than that, you can be sure whether the payment intent creation succeeded or failed and the rest of our API calls will be completely consistent on this.
mild urchin
Perfect. thank you very much.
mild urchin
Hello, in our API idempotency keys are only associated with API calls themselves...
I need this for payment intents. This is for customers.
jade prawn
That can be used as a general rule for our API. If you create a customer and we give you any HTTP response code other than a 500, you can be sure whether the customer was created or not.
mild urchin
I need idempotency for payment intents.
jade prawn
I don't fully understand that last part. Are you saying that you are unsure how to build idempotency on your side for this given what has already been discussed? Or something else?
mild urchin
No. I checked the API for idempotency keys for creating payment intents and I could not find it. I was wondering if there is something I am missing.
I am assuming I just add it to the headers.
But I just want to be 100% certain this applies to all.
jade prawn
Those parameters are present on all API calls, so we only show the relevant fields in the idempotency section of the API ref rather than the section for the API calls themselves
Yep yep, applies to all. This section shows the right parameter or header to use https://docs.stripe.com/api/idempotent_requests
mild urchin
Especially given the PaymentIntent API says "Avoids problems with Idempotency".
I was wondering why that is?
jade prawn
Can you link me to the doc where you are seeing that? Happy to take a look
What that might be referring to is that PaymentIntents are state machines so a PaymentIntent can only successfully charge a user once. If you try to make a payment on a payment intent after it has already succeeded, you will get an error message, making the single successful payment idempotent
mild urchin
Gotcha. Let me find the link to show you.
"No idempotency key issues"
Just want to double check before we start doing volume.
jade prawn
Thank you for the link. From what I can see internally it looks like that bullet point is referring to the same thing as the "No double charges" bullet point above it albeit in a more confusing way.
So I think what that means is that you can avoid double payments without idempotency keys. I will write in to our docs team to have that clarified in the doc, I defintely get the confusion with how it is written now