#Oren
1 messages · Page 1 of 1 (latest)
Hey there
Hello again
Don't think this changed with the API version change. Can you provide the charge ID?
And can you provide your retrieval request ID?
py_1LnddEAN9UGzw70gNExIbErJ
How would i find my retrieval request id, im using node sdk
more specifically i think the differences comes from omitting the latestApi config from the client initiation apiVersion: '2020-08-27', with that set no refunds returned, if i remove that they are returned
resolution: "stripe@npm:8.201.0"
Thanks
Looking!
Ah okay
This isn't a difference with the new 2022-08-01
This is 2018-02-28 compared to 2020-08-27
ah
refunds being returned with 2018 and not with 2020?
i see our default is currently set to 2018 in the dashboard
i tried using latest and also got no refunds
our webhook is likely using 2018 which is where we see the refunds initially in the charge.failed event
Hmm so what is interesting here is that there tehcnically wasn't a refund.
The payment just failed
So wonder if that is being handled differently
there does appear to be a refund generated tho
fetching the refund by id works on the 2020 api and has a link to the charge
RIght right
pyr_1LpLQoAN9UGzw70gHcLSa3Hz
When a debit payment fails a refund is generated
I just mean you didn't initiate a refund on a successful charge
i see
Just wondering if that is affecting how we are handling
We still should be returning the refund in the 2020 version imo
So need to find out why we aren't doing that
the larger problem we are having is that these types of failures do not generate an explicit refund event to process so we have to process the charge failure event and find the refund from there
looking through the event log there does not seem to be any type of refund related event outside of charge failed
Yeah that makes sense
Let me see if I can reproduce this behavior
In terms of the larger problem... you could use the charge.failed event no?
Oh
lol
That is exactly what you said
I see
ya the bug manifested for us because we receive the charge failure event and then re-fetch the charge data from the api and the charge in the event is different then the charge from the api, one reversed one not reversed
Gotcha.
short term we can work around that by just using the event charge, but there should be some programatic way of grabbing the reversal reference
these are likely destination charges so not sure if its some connect issue
Okay I was able to reproduce
So yeah this seems to be a legacy ACH thing
We actually don't even expose a refund for ACHv2 when the payment fails.
But this does seem to be a bug
Or at least it should be stated as a breaking change in our API reference
the problem we are having is these failures are netted in stripe payouts
so i need a way to create a reversal type model to reconcile
Right right
when you say achv2 is that a payment intent vs charge thing ?
I think overall this is a bug
Yeah ACHv2 is using PaymentMethods and PaymentIntents for ACH
i see
if we update our default api will that change the types of events our webhook receivies or only the content of events
Ahhh okay
So
This is actually considered a "system refund" since you didn't initiate it.
Bank pull payments no longer expose internal system refunds on failure.System refunds can still be accessed via the list refunds endpoint.
is there a way to grab a refund for a specific charge?
it seems to be a catch 22 in that you can only grab the refund if you know it exists
Yes you can list refunds by charge: https://stripe.com/docs/api/refunds/list#list_refunds-charge
So when you get a charge.failed on 2020-08-27 that is payment_method_details.ach_debit you can list the refund by charge using the above
And reconcile that way
Sure thing!
have a good rest of your day