#Jasperste

1 messages · Page 1 of 1 (latest)

fading hearthBOT
hushed mortar
#

If I refund is successful the expected behavior is to get that first charge.refunded event and then not get any further events. It is a similar situation with us to the bank. When a refund is successful, the bank tells Stripe that it was successful up front and then nothing else.

light grove
#

So to be sure about a succesful refund we need to listen to both events. If the charge.refunded is not successful we might get a charge.refunded.updated which is successful.

hushed mortar
#

No, only charge.refunded would happen in that case

#

charge.refunded.updated is for refunds failing and other updates on the refund

light grove
#

charge.refunded sometimes has a status 'pending'

hushed mortar
#

Can you send me an event ID of a refund that started out pending like that? I will look in to it. Sounds like I may be mistaken, my guess is that charge.refunded.updated should get triggered in that case

light grove
#

evt_3LWz3hR5Z77IxGN41sTVtwAo

#

The amount_refunded is updated, and refunded is set to true. But the refunds itself have a pending status. Followed by a charge.refund.updated event which did confirm.

#

It seems like since the recent updates it's less visible in events

Charge no longer auto-expands refunds by default. You can expand the list but for performance reasons we recommended against doing so unless needed.
#

For evt_3LWz3hR5Z77IxGN41sTVtwAo these were expanded.

hushed mortar
#

Thank you for the examples. Apologies that I was confidently wrong there. Looking in to if there is anything else I missed here

light grove
#

Thanks! I'm fine with refactoring a bit. Our goal is to know the amount succesfully refunded. If that means we have to check the charge.amount_refunded on both charge.refunded and charge.refund.updated I'm ok with that. It felt a bit cumbersome, but looking at everything it seems to be most reliable. We currently only looked at the updated one (no big problems occured btw).

hushed mortar
#

Have you seen instances where that amount changed between events? I was also under the impression that that amount should always be the amount that you set to be refunded but am still looking for docs on that

light grove
#

No. I haven't. But maybe in case a refund fails the amount refunded gets lowered again?

hushed mortar
#

My understanding is that the failure here would be for all of the funds (usually for reasons like the original bank account doesn't exist anymore) and you would get all of the funds back. Let me see if I can find more info on what happens with the failures.

#

Also is it possible that that event ID was truncated? I am not finding an event for evt_3LWz3hR5Z77IxGN41sTVtwAo at the moment

light grove
#

I also couldn't find it in the dashboard anymore, but do have the json. It was a test payment

#

When looking into threads in this discord I found most people just look at charge.refunded. Since updated is only in rare cases relevant for amount_refunded (if there even is a case)

hushed mortar
#

As far as I can tell, the refunded amount shouldn't change. That should definitely be the amount sent back to the customer any which way.

Also I found clarity on the pending refunds. That will happen if your account's Stripe balance is too low to cover the refunds. Once your account has enough funds, they will be sent to the customer and you should get an event about that becoming successful.
https://support.stripe.com/questions/pending-refunds-due-to-insufficient-funds-or-stripe-balance