#bodger - webhooks
nova egret
Webhooks are often a good backup in case you don't hear back from the client
Otherwise it is possible to hold your user's funds and not know it.
crude inlet
Hmmm, that's confused me a bit - given that my process doesn't create a booking until it hears back from the payment confirmation, you're saying that the payment could still have been taken but they then won't have a booking?
nova egret
Right. So how does your server currently find out that there are held funds that it can capture?
crude inlet
The way I've got it at the moment, as soon as the confirmPayment comes back without an error, it submits the payment form and the server then creates the booking and captures the payment intent.
crude inlet
So Stripe Support suggests that I just try this method and let them know if I see any errors. That sounds a bit risky to me, based on what you're saying here.
nova egret
Sorry, missed that last message.
So the issue is that it is possible for the client to make the call to Stripe and have the funds held successfully but then have their connection cut out before the client can reach out to your server about it
So in that case, the funds would be held but your server would not know. With a webhook, you have a backup so that even if the connection cuts out, your server will hear about the hold
crude inlet
OK, so that would mean that the booking would have to be created before the hold on the payment was done - so that the information regarding the booking ID could go into the payment intent in order that I can identify what it belongs to when the webhook is received on my side, right?
So I need to create a booking regardless of whether the booking is going to be paid for or not.
crude inlet
Would that be the correct way to do it? Create a booking before the payment step is reached, then pass the booking ID into the payment intent so that the webhook can update the booking if and when it's paid for?
nova egret
Sorry, saw your message and had to bounce to another thread while thinking on it. When is the booking ID created now? After the hold right?
crude inlet
No probs - yeah, the booking isn't created until everything's been paid for. Otherwise I've got to go round tidying up unpaid bookings all the time, which is a pain.
So it's 1) type in booking details, 2) pay (hold) booking payment, 3) create booking, 4) capture funds
nova egret
So a typical way to do this that I've seen in other flows would be to have your server create the booking the first time it hears about the hold from either your client or a webhook event. When it hears from the other one, you can just retrieve the info on the booking that has already been created
crude inlet
So create the booking when I create the payment intent (before rendering the payment page) you mean?
nova egret
I think you can still do it after the hold.
crude inlet
Oh so my original order of things would still work? But if the hold never comes back, create the booking when the webhook calls me?
nova egret
Yes, though you might get the webhook event before you hear from your client. So you need to be able to receive them in either order.
crude inlet
Hmmm, that could be really difficult. There is tons of data required to make the booking - all sorts of information about trainees and answers to questions and subsidies and blah blah blah. All that info is only available to booking process (in the session) - when the webhook is fired, it wouldn't have it all there to be able to make the booking.
I suppose all that info would have to somehow get put into the metadata of the payment intent when it was created, so that it could be used to create the booking when the webhook is triggered?
mighty geyser
Hello. Taking over for Pompey as they had to step away. Give me a minute to read and catch up
Another option I see here is you could store some temp data for the booking while the customer is on-session right before the payment intent is confirmed
And then in your webhook handler code, you could "confirm" that booking
Basically having 2 states for the booking in your system: pending and booked
Could something like that work?
crude inlet
Yeah, that was the only solution I could think of too - creating a booking that wasn't confirmed until the webhook said it was good to go. Then I'll have to update the rest of the site to not count bookings as booked unless they have that particular state.
mighty geyser
Cool yeah that seems like a viable solution to me
crude inlet
For the time being, I am using synchronous payments which means I can wait until the hold completes before creating the booking. It does mean I can't use Payment Elements though, which is a real shame.
mighty geyser
Yeah, and as Pompey was pointing out, there is some risk involved to doing things synchronously
Up to you if you are ok to accept the risk
crude inlet
Oh sorry - I meant that I currently confirm the payment on the server - this (I think!) means that I don't have to worry about that risk, right?
mighty geyser
Ah ok I think I understand now
So you are doing these operations on the back-end, and even if the user's browser crashes or the tab is closed, the customer will still have all the states they need saved to continue where they left off if they return to the site?
I guess I'd need to know a bit more about your application structure, but you might be fine
crude inlet
No, I think if their browser crashes, they'll have to restart the booking process. But I think I'm right in saying that, if I use the "finalize the payment on the server" process (where the frontend POSTs to the backend to create the hold on the card), it should all work fine - the user enters all their booking details, then they enter their card details - that POSTs to the server which, when it confirms the hold, it creates the booking, captures the payment and all is well.
I think !!
mighty geyser
That flow is performed all on one POST call?
crude inlet
No, the payment hold part is done when the user enters their card details. That POSTs to the server to create the hold on the card for the payment. Then, when the final form in the booking process is submitted, that does another POST to create the actual booking and capture the payment.