#cris-moshtix_webhooks
warm ospreyBOT
👋 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.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 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/1362412680106872903
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- cris-moshtix_webhooks, 1 day ago, 21 messages
shadow bobcat
Hi, can you share the webhooh endpoint where you see this issue?
From looking at this, I see you are listenting to this event on 5 different webhook wendpoints. Out of those, 3 suceeded but the rest have timed out due to timed_out. You need to ensure that you respond to the event with 200 right away before you run any logic on your end.
Of the suceessful deliveries, I can see the body of the event on my end. Can you share what you recieved on which of the webhook endpoints? What did you expect to get?
gray wave
I receive this
But I'd expect this
So confusing as one is the event request, the second is the Event Data and looks like my code is grabbing only the event request (1st file)
The timeout is because I'm debugging and stopping the response. No need to warry about it.
What I'm after is this part:
"refunds": {
"object": "list",
"data": [
{
"id": "re_3RErIbIydrkivHR82mShYU3I",
"object": "refund",
"amount": 2347,
"balance_transaction": "txn_3RErIbIydrkivHR82cZXZcOu",
"charge": "ch_3RErIbIydrkivHR82LZDCLqp",
"created": 1744892295,
"currency": "aud",
"destination_details": {
"card": {
"reference_status": "pending",
"reference_type": "acquirer_reference_number",
"type": "refund"
},
"type": "card"
},
"metadata": {
"Admin User Id": "6311",
"Attendee Ids": "[43436257]",
"Environment": "devCris",
"Is Bulk Refund": "False",
"Is Full Refund": "False",
"Is Manual Refund": "False",
"Is Store Refund": "False",
"Merchant Code": "MoshtixStripeMerchant",
"MoshPos": "170415-44671599-Rf-1",
"Order Id": "44671599",
"Refund Contact": "Cristian Carotenuto",
"Refund Flow Type": "Booking",
"Refund Reason": "Test refund",
"Refund User Credits": "False",
"User IP Address": "{"IpAsString":"10.211.55.2"}"
},
"payment_intent": "pi_3RErIbIydrkivHR82xofwAZC",
"reason": null,
"receipt_number": null,
"source_transfer_reversal": null,
"status": "succeeded",
"transfer_reversal": null
}
],
"has_more": false,
"total_count": 1,
"url": "/v1/charges/ch_3RErIbIydrkivHR82LZDCLqp/refunds"
},
shadow bobcat
~~You'd want to review the webhook event API versions. We document a bit about it here: https://docs.stripe.com/webhooks/versioning~~
You should listen to this event and then use the Charge ID to retrieve the Refund by using the ID in the Refund List API, https://docs.stripe.com/api/refunds/list
gray wave
When u say that I should listen to this event, are u referring to "charge.refunded" event?
shadow bobcat
I do not think it's a versionining issue so scratched that.
yes, it's that event
gray wave
Ok, I don't think the version is an issue either.
But you mentioned that I should send a second request with the Charge ID to retrieve the refunds. I think this kind of defeats the purpose of webhooks. Cannot be this way.
Indeed, if I look at the event data, the refund is already there
shadow bobcat
I tested this and confirmed that it works that way. To attain the event data, you'd need to use the Charge ID to use Refund List API, https://docs.stripe.com/api/refunds/list
That event is on the charge and it let's you know that a refund was created.
gray wave
I don't understand. Let's just have a clear vision of the process.
- I send Stripe a refund request
- I receive a Stripe webhook with the Charge ID
- I then need to send a second request to Stripe, using the Charge ID, to retrieve the refunds. This is not completed via webhook, but it's a direct call/response.
- I then guess which of the refunds in the list I need to process. I also read your docs saying it return only the 10 most recent refunds.
Sorry but the above must not be the case. I'm sure I got something wrong. Please explain as I'm confused.
shadow bobcat
You would want to use: https://docs.stripe.com/api/refunds/list#list_refunds-charge and pass the charge id
Yes, that is expected and you can use auto-pagination to get more: https://docs.stripe.com/api/pagination/auto
However, I think the flow would be that you get that event, and then make a call to retrieve the refund for that Charge ID
gray wave
Ok, but may I know why the webhook is not returning the refunds list in the first place? After all, I'm listening to a refund event.
shadow bobcat
No, you're listenting to a charge event charge.refunded: https://docs.stripe.com/api/events/types#event_types-charge.refunded
gray wave
Ok, let's go back one step. I initially listen to only refund.updated event. On the sandbox this was all I needed and works just fine. Then, once I deployed to production, I realised a lot of refunds wouldn't complete as the refund.updated event was triggered only for some refunds. I had a chat with your colleagues and they said to listen to charge.refunded instead. Is this correct? If so, your sandbox is not behaving like prod. Also, I'm still insisting on the fact that both events should return the list of refunds. Is this perhaps an issue Stripe has, which is going to be resolved? Sorry but it doesn't make sense refund.updated has the refund data, but charge.refunded doesn't.
shadow bobcat
That refund.updated event is a refund event. That is sent only after the refund is updated. You may want to look at https://docs.stripe.com/refunds#refund-events
On the other hand, charge.refunded is an event on the charge
gray wave
I get that. Then which is the event I need to listen to when refunding money?
shadow bobcat
It all depends on what you're looking to do. At a minimum, Stripe recommends that you listen for the refund.created event.
Can you try that?
gray wave
I can but is that telling me if the refund has been processed by the bank?
shadow bobcat
I'm unsure what you mean by that, are you able to reword this please?
gray wave
I want to know only when the refund has been completed, either successfully or a decline. I don't need to know if a refund has been created.
warm ospreyBOT
shadow bobcat
Then, you can listen to refund.failed event: https://docs.stripe.com/refunds#failed-refunds
gray wave
I already do that. Let's assume refund failed is covered. What do I need to listen to if a refund succeeds?
Which webhook event is it?
shadow bobcat
We assume that refunds will always succeed, so if you do not get refund.failed that means it's succeeful.
gray wave
So refund.created means it's succeded?
shadow bobcat
If you get that creation event, and if you do not get that refund.failed event, yes. Refund failures are rare: https://docs.stripe.com/refunds#failed-refunds
gray wave
That doesn't work for me. If I receive a refund create event, assuming it's successful, then I complete the refund on my end. Which is a bad thing to do if I also receive later on a refund failed event.
Refunds failures are not rare at all. I wark in the ticketing industry and we have many instances where refunds are declined because of credit cards no longer valid.
I surrender. I think I need to do some research elsewhere. Thanks for your help.