cab-webhook-sla

[dull jacinth]

cab-webhook-sla

@digital beacon we don't have specific SLAs for this on our end. Webhooks are almost always used for async reconciliation and not something you would build real time blocking behaviour on. But you can read more about delivery and retries in our docs https://stripe.com/docs/webhooks

[digital beacon]

thanks - although that is kind of conflicting to what I have heard from other Stripe people when you say "not something you would build real time blocking behaviour on".
My Stripe integration creates subscriptions and confirms payment for them on the client side, and I was told to use webhooks to update my backend upon completion of payment, at which point the backend would provision access to the user. Are you suggesting I shouldn't rely on webhooks for that?

[dull jacinth]

If you have something client-side, you should hit your server and there you can look at the Subscription and its latest Invoice to confirm if it was paid successfully or not and do fulfillment this way.
Webhooks are crucial and you need to listen to them for async reconciliation, but that doesn't prevent you from having an additional synchronous fulfillment in this case

[digital beacon]

Okay yup I was planning on having the client make some sort of POST /subscription/{id}/sync request that would check for success of the subscription creation as a guard against the race condition where the webhook may be slow. It seemed like most of the time the webhook would be handled in time, but if not, that API could check the status in Stripe, make updates to our DB if necessary and return the success.