From a few years old personal experience, I'm really irritated by stripes web-hook approach overall

> The obvious approach is to have an event list which you as customer long-poll or just poll every few seconds This is also much much easier for the payments integrations developers to test, compared to all the messing about and running dodgy proxies that testing webhooks involves. Webhooks for critical application paths just seem like a bad idea all around really

I just would like to give my opinion on some of your points, which I don't agree with: > Looking at the documentation directly, what they advise you to do is kind of the worst idea they could come up with: https://stripe.com/docs/webhooks/signatures – you need custom logic[2] to verify that their MAC ("signature" they call it incorrectly) is valid and you need to configure a different secret for each of your endpoints It certainly help that I use their official SDK, but it's one line of code to add the signature validation. Also, I'm not sure why you would want to create a lot of endpoints to listen to these webhook. I simply have one, and the Stripe SDK helps me in determine the event type, its deserialization, etc. > Payment process information is such a vital business concern that "let's try to call them and if that fails... well we tried" is broken on principal alone That's not how i…

You should not poll a payment provider in a general flow. Do you realize how many requests that will cause if everybody did that? A payment flow is event-driven by nature. The payment provider pushes the states back to the initiating system. If that fails it is up to the consumer to detect problems and make sure that the system is in sync with the provider. Some payment providers do push data up to at least 24h. It is an obvious design flaw...