#hoyong_webhooks
fallow skiffBOT
👋 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/1236039596295458886
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
vocal fulcrumBOT
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.
- hoyong_webhooks, 21 hours ago, 52 messages
- hoyong_webhooks, 1 day ago, 10 messages
- hoyong_webhooks, 3 days ago, 6 messages
narrow locust
We don't guarantee any time range
It should be very quick
But it's possible there would be delays due to networking issues, etc
So I wouldn't rely on it being within a certain time frame for anything critical
dreamy parrot
Yeah. I would like to have a more secure way to handle this. But, without making another API call in a webhook I can't really think of a way to compare Stripe::Refund and Charge. From my conversation yesterday, charge object no longer includes refunds 🥲
Any recommandation?
narrow locust
Ok what's the goal, specifically?
dreamy parrot
So, I have a refund service that will call Stripe::Refund.create which I will store that in my database. Then I also have a webhook that listens to charge.refunded in case someone makes refunds through the Stripe dashbaord. The event will update our db when that happens. However, the Stripe::Refund will trigger the webhook event, so I would like to prevent my system to update the db again.
narrow locust
Why not only make the update in the webhook event handler code?
dreamy parrot
It's because the frontend expect the transaction data when the service is called. If the service doesn't return anything, the frontend will show error.
narrow locust
Ah I see
Ok I have a recommendation then. When you create the refund, you can set metadata on the refund object indicating it was made via the api: https://docs.stripe.com/api/refunds/create#create_refund-metadata
And then ignore those in your webhook processing if you so choose
I recommend you just let the webhook update your db anyway though
In case there was some error from before when attempting to update the db
dreamy parrot
I already know it's from the api because it's a refund object. The question is "is refund object the same as the charge event?"
narrow locust
That doesn't make sense though. Dashboard refunds also create refund objects
is refund object the same as the charge event?"
no
Charges can have refund(s)
They're not the same
dreamy parrot
Sorry. yeah, I know that. But, that's what I am trying to make sure this Refund object and the charge object are coming from the same refund action from a user.
narrow locust
However, the Stripe::Refund will trigger the webhook event, so I would like to prevent my system to update the db again.
This is the problem I was trying to address with my above suggestion: #1236039596295458886 message
You should be able to avoid updating your database twice if you check for the metadata you set in your webhook code
But to get the refund object in your charge.refunded event, you'll have to make an additional api call to list refunds by charge: https://docs.stripe.com/api/refunds/list
dreamy parrot
But to get the refund object in your charge.refunded event, you'll have to make ...
Right, and this is what I am trying to avoid since I don't think it's good to make an additional api call in a webhook.
narrow locust
What data from the refund object do you need to store, just curious (besides the metadata I suggested)?
dreamy parrot
I am saving the entire object as a json to keep a record.
narrow locust
Ok but why do you need the whole object?
dreamy parrot
That's just how it's been done. Would you suggest to save only the ids?
narrow locust
If you MUST store the whole object, you're going to have to make an additional api call
There's not really a way around it
I would suggest only storing what you need to store
Like if you don't need any info from the refund object itself for later on, I don't recommend storing it at all
dreamy parrot
but, how's storing what I need going to help my situation?
narrow locust
My point is for most integrations, simply receiving charge.refunded is enough and they mark the charge as refunded
If you don't need to grab additional data from the refund object, then don't
If you do, then there's no away around the fact that you need to make an additional api call
Making an api call when receiving a webhook event isn't inherently wrong
It's recommended even in many cases (depending on what you're doing)
If you're worried about response time due to additional api calls being made in the webhook handler, then I recommend responding quickly with a 200 and just processing events async. That's how many handle this