#alessio_not_shish
marble blaze
Well each of the events you describe include different API objects in the payload, which explains why specific fields are only available on specific events
charge.refunded is a Charge object
charge.refund.updated is a Refund object
The recommendation is that you use both: charge.refunded to know a refund was created, and .updated to track it's status
scenic umbra
I see, thanks. Would you happen to know if reversal can happen in case of a partial refund? I would assume they cannot, but the documentation doesn't explicitly state it
marble blaze
I assume reversal is a enum value on a field?
scenic umbra
refund.destination_details.card.type
It's an enum, it can be either card or reversal
marble blaze
Well generally a reversal is a refund that is processed before the funds from the original transaction are actually processed/cleared
But not sure if that's true in case of a partial, so I'd recommend testing!
scenic umbra
Alright, just one last piece of advise if you don't mind.
The documentation indicates that reversal are created automatically whenever possible, if a payment intent is refunded shortly after being captured. In test mode this is not the case, refund seem to always be processed as refund.
Should I use this test helper to simulate a reversal? https://stripe.com/docs/api/issuing/authorizations/test_mode_increment
If so, where can I find the authorization id?
marble blaze
Not unless you're using Issuing no. Do you have an example pi_xxx you refunded that was not processed as a reversal?
scenic umbra
Sure pi_3ObPCjIDB6WEEZZk1YQpBLjK
marble blaze
Taking a look
scenic umbra
This one has been done from the dashboard, I can quickly create one from our integration as well if needed
marble blaze
All good, checking with a colleague
scenic umbra
Thanks!
stone sparrowBOT
marble blaze
Ok, unfortunately it seems like forcing a reversal refund is not possible today
You'd need to mock that response if this is for testing purposes
scenic umbra
I see. In that case I need to bore you with one last question. In case of a reversal can we still see the transaction details in the IC+ Transaction Level Report or since the charge gets dropped we will only see the authorization fee?
marble blaze
Unfortunately we know nothing about reports, that's a better question for support: https://support.stripe.com/contact
scenic umbra
I see, no problem, I'll get in touch with them then!
I do apologize for all these questions, we tried to avoid refunds for a long time, leveraging partial capturing whenever possible, but we recently hit a hiccup with the authorization lifetime being limited to 48h so there is actually no way to avoid them anymore. And since we charge our connected accounts with the exact amount of fees we pay, the difference between refund and reversal requires to be handled correctly.
Thank you for all the answers, have a great day!
marble blaze
you too!
marble blaze
@scenic umbra circling back here, seems the way to force a reversal is to do capture_method: 'manual' to only auth and then refund/cancel the PI
I'm not sure if that behaviour extends to captured payments in production payments, trying to confirm
scenic umbra
@marble blaze this is what we do now, we cancel the payment intent in case of a full refund or we do a partial capture in case of a partial refund. Both scenarios do not create a refund object though, and they do not send any of the above webhoks because there is no charge object created until the payment intent is captured
marble blaze
Hmm, there should definitely be Charge and Refund objects for authorisations (I just tested this)
scenic umbra
This works fine and we have a confirmation from our AE that Stripe does not charge for the refunded amount in this case, because no refund charge is actually created, so we can't legerage this approach to test the reversal scenario
scenic umbra
Hmm, there should definitely be Charge and Refund objects for authorisations (I ...
Maybe I am missing something, but I am not receiving any webhook
Just tried with: pi_3ObPIqIDB6WEEZZk09iBs9dh
marble blaze
Well it's because you've captured it. You don't refund uncaptured intents, you cancel them. See: https://dashboard.stripe.com/test/logs/req_jYMYY2DNCZQeCT
marble blaze
If the scenario you want to emulate is: captured charge refund before the charge clears
Then that cannot be tested specifically
scenic umbra
In this one, the refund object sent to the webhook actually appears as a reversal
In my previous PI I tried to partially capture it, to see if a partial refund was also created
scenic umbra
If the scenario you want to emulate is: *captured charge refund before the charg...
yes, this is the last scenario I need to test. According to the documetation, if a refund is issued shortly after the capturing, Stripe attempts to create a reversal if possible. The doc does not indicate what "shortly after" means in terms of minutes, but I would assume it actually depends on the card issuer
marble blaze
Yeah AFAIK you can't test that specifically today and I'm not sure what the exact definition of a 'reversal' is