#srkishy-disputed-refunds
1 messages · Page 1 of 1 (latest)
Do you have an example request ID?
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
Yup, /req_MrEHAbTBOtItNY
How is the refund being created? Via the dashboard or via the API?
Via the API
Okay, let me dig on this a bit and get back to you
Can you confirm that you are using idempotency keys when creating refunds?
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
I think the issue is that the API is interpreting the request as a "replay" of a previous refund creation, as opposed to a new refund altogether
Yeah, we're using idempotency keys
Hmmmm, that would make sense as to what's happening, was hoping since the initial creation failed it would allow it to succeed later
This is news to me as well, but as I'm looking at the request, that seems to be the reason the 2nd refund isn't succeeding.
Ok, I confirmed I was able to create the refund through the API, I'll try changing the idempotency key
Ok, confirmed changing the key works. Definitely not an ideal flow for us as currently we make an order on our side to track the refund, and the idempotency key we use is attached to that order.
But, assuming that's not going to be changed anytime soon, we'll try to find another way to handle it, thanks for the help!