#lukas.giniotis-stop-retries

1 messages · Page 1 of 1 (latest)

rain thunder
#

Hello 👋
Yes we expect 200 response codes for webhook events. If we don't receive that then we'll keep retrying until we do receive a 200 or we exhaust the retry cap

atomic echo
#

Thanks for the response. Maybe then it would be possible to indicate the response as 'failed' in some other way? E.g. return 200 so it does not retry, but a separate parameter says that the event has failed and would be marked as failed in the dashboard?

rain thunder
#

Just to clarify, why do you want to mark the event failed?
What's your actual usecase?

atomic echo
#

We have a Refund implementation where through an Admin Portal we'd create a refund, then someone has to approve it and we'd create a Refund in Stripe. We get charge.refunded event that we listen to for success. However, there is still the possibility to refund payments through Dashboard. In that case we want to mark the event as failed as we don't want to process refunds created this way.

rain thunder
#

When you say

However, there is still the possibility to refund payments through Dashboard.
you mean Stripe Dashboard right?
So basically you want to prevent refunds getting generated from Stripe dashboard?

atomic echo
#

Stripe Dashboard yes. Ideally yes, we'd like to prevent that, but the current use case was about logging such events. There is a separate issue about limiting to who can access Stripe Dashboard so that we don't get many Refunds done this way, but if there is a way to disable that completely, I could bring that back to business

#

By 'logging' I mean logging in our system as well as marking them as failed so they would be visible in Stripe Dashboard

rain thunder
#

Gotcha so just to clarify responding to events with failed doesn't mean the refund will be cancelled or failed.

You'd likely want to refactor your code to log these events in your system before you respond with a 200 really rather than depending on the events status on the dashboard.

I don't know much about the roles but there might be a way to prevent refunds from the Stripe Dashboard. Let me double check

atomic echo
#

Thanks for your help. Roles are going to be investigated by a separate business representative, but there will be non view-only roles anyway so we still want to log events from Dashboard. So to summarize - for this we either respond with 200 and only log them as failed in our system or respond with a failed code and have to retry the events?

eager glade
#

Correct, the 200 here is intended to be an acknowledgement that you got the event. It doesn't affect the actual status of the object that the event is about, you would affect the refund by making API calls on the refund object itself

atomic echo
#

Thanks a lot. I will return 200 in this case.