#intelagent_webhooks
fierce hemlockBOT
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.
- intelagent_api-account-support, 4 days ago, 14 messages
- intelagent_api, 5 days ago, 33 messages
naive birchBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1254911881143910524
đ Have more to share? Add details, code, screenshots, videos, etc. below.
ashen parrot
Hi there
tacit wind
Hello there
ashen parrot
Recommended practice is to retrieve the charge and expand the refunds hash: https://docs.stripe.com/api/charges/object#charge_object-refunds
tacit wind
Right... but then there is no way to know which refund fired the event? I understand it's an event on the charge so that may make sense
I have the following scenario:
- create refund object internally
- create refund in stripe
- update refund status to db
In the case that 3 fails I'm subscribed to webhook events for resiliency but unsure which webhook event to listen to in order to update the refund status, as it seems like this might not be the right one
ashen parrot
Right, we recommend listening for events related to the charge since refund events are only sent in very specific cases (refunds from a cash balance): https://docs.stripe.com/refunds#refund-webhook-events
tacit wind
Right, that would definitely be the wrong event to listen to in this case.
I'm a bit confused on how to understand which refund I'd need to update in my application as the result of a charge.refunded event. I could grab the latest refund but that doesn't seem like a robust solution.
ashen parrot
charge.refunded is the right event to listen for. What's confusing about this event is that refunded will only be true only if it is fully refunded
I see the charge in question has two refunds associated with it but they were both partial refunds and don't yet add up to the full Charge amount, which is why both charge.refunded events show refunded: false
tacit wind
The charge in question was really just an example. If I listen to charge.refunded how can I understand which refund object in my application to update?
Because by the time I fetch the charge object and expand it more refunds could have been attached to the charge
ashen parrot
The associated refund object is not included in the event payload so you'll need to make a follow up call to retrieve the Charge, expand the refunds hash and look at the timestamp for when the refund(s) were created to compare these to the charge.refunded time stamp and any other Refunds you already track in your database
tacit wind
Right okay, thought maybe there would be a nicer way. Seems odd that the refund that caused the event is no where to be found easily
But alright sounds good appreciate the help
ashen parrot
Sure thing!