#chukdawit
fallow stump
solemn mirage
Hi, are you able to share the event id with me so I can look at it on my end?
dry swan
I don't know if my dashboard will show me the id going back to the first event, as it was a couple months ago. But I can give you the one I created yesterday. Hold up. Give me a sec.
evt_3NXutiH6wPz6LzpK1heAyv14 - this event id was issued yesterday. The webhook was a charge.refunded webhook, which seems to be different than the one a few months back, which I believe was a refund.created webhook. Either way, it seems logical that I should get a refund.created webhook when creating a new refund, no?
solemn mirage
Depending in the type of refund we send different event types. Can you confirm that the requests between this and the other one is 100% identical, same payment method type etc? When refunding a charge like this, https://dashboard.stripe.com/test/logs/req_xVg51Lku3yi5wp it's expected to get this event.
dry swan
type of refund? I didn't know there were different types you could send vis API. In all my use cases I provide a payment intent id and the amount! I believe one type of payment is automatically confirmed/collected and the other is manual, first put on an authorization hold for 24 hours and then captured. Would these two different types be the reason?
safe ridge
👋 When you refund a Charge or a PaymentIntent you get charge.refunded as an Event.
We do want to support refund.created as an Event for those but we haven't historically. I won't get into the weeds of why but it boils down to the fact that Refunds used to be done as part of a Charge and not a separate API/resource.
It's something we do want to fix in the future, just haven't gotten around to it yet
dry swan
"When you refund a Charge or a PaymentIntent you get charge.refunded as an Event." - no, well I guess, I get a webhook response of charge.refunded. I guess that's an event, right? I'm trying to understand how I received a refund.created webhook a few months ago. I know I received it, because I went and coded the method up to save the data coming from the webhook. If I provide different parameters to the API RefundService call could that change the webhook event type? or am I just loosing m mind??????
I'm trying to figure out why a few months ago I coded up a method to handle a refund.created webhook. I did receive 2, as I have a 2 rows in my db with data from them coming in.
from Stripe. Maybe I miss configured something or change names of the webhooks over the last couple of months. Question - what causes a refund.created webhook???
safe ridge
I can't tell you that, Events disappear after 30 days so I can't find what happened
there are a few rare cases (bank transfers refunds in some countries) where we send refund.created but it's rare
Ultimately if you do card payments you want charge.refunded which you already get, so that's what you should focus on
dry swan
grunt...ok! thanks for the help...
oh wait, one more question.
in my initial implementation for the refund.created webhook, I had 4 properties (FailureBalanceTransactionId, FailureReason, SourceTransferReversalId, TransferReversalId) and it seems like those were appropriate to have if the refund failed to get sent back to the credit card. There would be info there in those fields I could present to the customer to show him why we couldn't refund back the card. But now in charge.refunded, there are no fields like this. There's a Refunded (bool) field that I guess is false if there's no refund and a status field, but that looks like it's for the original charge. Question - What way can I determine if and how/why the refund fails to get sent back to the customers card?
safe ridge
safe ridge
When you refund a Charge you get charge.refunded. When a Refund later fails you get charge.refund.updated
they are separate Event types. The first one describes the Charge object as it's what's refunded. The second one describes the Refund object (to reflect it failing)