#srkishy-disputed-refunds

1 messages · Page 1 of 1 (latest)

solemn stream
wicked siren
#

Yup, /req_MrEHAbTBOtItNY

solemn stream
#

How is the refund being created? Via the dashboard or via the API?

wicked siren
#

Via the API

solemn stream
#

Okay, let me dig on this a bit and get back to you

#

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

wicked siren
#

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

solemn stream
#

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.

wicked siren
#

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!