#gecko-webhooks
left fractal
hi Bismarck
I understand there are two things to handle in a payment scenario. (I'm using checkout). first, a success page, which handles the case in which a payment is made successfully, and there is no delay in funding, and the success URL is reached. I'm currently getting these via a .get(/order/success) style listener.
the second scenario I understand is a delayed or uncaught success (perhaps they close the window too fast before a success redirect is completed)
in the 2nd case, I need to have a listener that's different than the first case...it's not covering both, and I need an explicit separate webhook style listener. correct?
velvet kindle
Overall yes. The real recommendation here is to just use Checkout Session events to handle fulfillment. The Success URL (and potentially appending the Checkout Session ID to the Success URL) is to create a Sucess UI for your customers. I'd recommend giving a read through https://stripe.com/docs/payments/checkout/fulfill-orders
left fractal
yes, understnd the success UI piece....and both cases (direct handling and webhook) for fulfillment flow the same method in general. What I understand you to mean, however, is that a sucess UI focuses on the "thanks"...and an event handler (webhook) will handle fulfillment.
if I understand correctly, then I wonder if there are cases when the event is delayed in getting to my webhook listener, and then the "thanks" which implies immediate fulfillment, may not actually occur?
if so...how to prevent this timing issue?
velvet kindle
You use the webhook for fullfilment and you use the Success URL for the UI. You don't want to rely on your Webhook for the UI due to the async timing of Webhooks like you stated.
left fractal
I'm asking about the opposite scenario
do I have to worry that a sucess UI will show suceess, but there can be a delay in my webhook getting the fulfillment event?
velvet kindle
No
Sorry... worry about what?
Like you won't hit the Success URL and then get a failed payment
But yes... the webhook can take up to a couple minutes to fire
Is there an issue with that for your use-case?
left fractal
well, this is what I'm wondering....I tell the user congratulations, and they expect immediate fulfillment (software use case, so deployment is immediate)...what you're telling me is I need to include in the success UI, that it make take up to 5 minutes to reflect? is this enough time to ensure you relay to me?
velvet kindle
Most times webhooks should only take a few seconds, however if you are going to rely on immediate provisioning of your service (like redirecting them to a page with access), then you should rely on the Success URL for that, BUT you would want to configure Webhooks as well and ingest them if the customer never hits the Success URL (but makes a successful payment) because they drop off as you noted previously.
So yeah, you are in the unique situation where the best route is to use a combo as that will actually be the best customer experience.
Most folks don't need to provision immediately so Webhooks are totally fine on their own
left fractal
a sucess UI will get the session info...and so will a webhook. I'll have to filter in the webhook case, for any that I have handled in the sucess UI route, if I choose to handle fulfillment in 2 places
yeah I'm trying to decide if I need that or not, and how many angry calls I will get if I don't.
velvet kindle
Yes you would indeed check on whether you already have data for that payment when ingesting the Webhook.
Totally fair to weigh your options here.
I'd recommend doing some testing... generally Webhooks are quite quick and should be fine.
But mostly it depends exactly on how you want your flow to look
left fractal
the fulfillment doc you pointed me to, talks about fulfillment...I understand it. I don't see a reply mechanism, that ensures the event is "handled", and not repeated. so how do I determine a event.type === 'checkout.session.completed' event vs. one that is from before? the moment I fetch it, you change internal state, so it can't be fetched twice?
velvet kindle
I'm not sure I understand what you mean? You just reply that you received the Webhook, then you decide on how you want to handle the data that has been provided in the Webhook.
Can you explain more what is confusing you?
left fractal
I mean...is there a scenario where I could receive a webhook twice (or miss one if server crashed, etc)...i.e. do I need to "poll" for any missed events in some other non-interrupt way?
velvet kindle
We will resend webhooks if we don't get a response from you (see: https://stripe.com/docs/webhooks/best-practices#retry-logic), but it is also possible we send duplicates so you do need to handle those as well.
left fractal
And to make sure I understand, if I fetch the session info based on the session ID in the webhook handler, then this is my response. Right?
velvet kindle
Nope, you send a 200 response when the Webhook hits your endpoint to respond to it.
Then you can do anything thereafter (or nothing)
Here are our docs on acknowledgin the Webhook: https://stripe.com/docs/webhooks#acknowledge-events-immediately
left fractal
perfect thanks