#rast_refund-events
foggy oarBOT
👋 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. Thank you for your patience!
⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.
🔗 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/1213095017086713856
📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.
hearty adderBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- rast_refund-events, 17 hours ago, 26 messages
- rast_webhooks, 19 hours ago, 20 messages
- rast_api, 2 days ago, 15 messages
carmine cedar
Not AFAIK. Do you have an example evt_xxx? A minute to arrive from which point?
zenith siren
carmine cedar
Paste it please
carmine cedar
OK so the concern is the delay between charge.refunded and charge.refund.updated?
zenith siren
yes and no... mostly the fact that charge.refund.updated is delayed for 2mins
is this only in case of test card?
carmine cedar
I mean it isn't 'delayed' so to speak. It reflects how refunds actually work – they're async and can fail/succeed after their creation (hence the subsequent .updated event)
carmine cedar
it is not real-time either 🙂
What isn't?
carmine cedar
what do you advise?
There's no way to make that 'faster' unfortunately
zenith siren
cool.. would you advise to use charge.refunded in this case?
carmine cedar
I mean it isn't 'delayed' so to speak. It reflects how refunds *actually* work –...
No, because at that point the refund will be 'pending' as per my previous message
zenith siren
okay I see. thanks for sharing.
oh sorry, one more... do you know if there is an upper limit when the event should arrive?
carmine cedar
To be clear the delay here isn't the delivery/arrival of the event(s). It's related to how/when they're being generated in the system – we send them ~immediately after that
I'd imagine with those test cards it's intentional that the refund is 'pending' for a short time and then transitions to success/failure
zenith siren
It is not same behavior for both cards. In case of 4000000000005126, the status is set to failed immediately.
carmine cedar
That's no what the docs describe:
The charge succeeds. If you initiate a refund, its status begins as succeeded. Some time later, its status transitions to failed and sends a charge.refund.updated webhook event.
Do you have an example?
zenith siren
ok, I found a workaround. When using 4242424242424242, the status is set to succeeded immediately.
so I can use those 2 cards.
carmine cedar
Yep, refunding 4242 will succeed immediately. But, as I said, that doesn't emulate live mode payments/refunds
zenith siren
cool, thanks.. makes sens
carmine cedar
The doc mentions this:
In live mode, refunds are asynchronous: a refund can appear to succeed and later fail, or can appear as pending at first and later succeed. To simulate refunds with those behaviors, use the test cards in this section. (With all other test cards, refunds succeed immediately and don’t change status after that.)
So your integration needs to handle that