#Earl

1 messages ยท Page 1 of 1 (latest)

quiet trenchBOT
mild shuttle
#

Hi! Let me help you with this.

slow gust
#

That would be great advocate Not looking for like a 100% definite answer because I realise that either approach would work just what people normally do or if there are any best practices/recommendations.

mild shuttle
#

We recommend using webhooks over server-side confirmation, because if the user drops off the session before you confirm the payment, it will fail.
Therefor it's more reliable in many senses to listen to payment_intent.succeeded before displaying the success page to the customer.

slow gust
#

Great thanks. Any idea on the expected delay of webhooks do they pretty much get sent immediately? And now I'm getting a bit technical and maybe theres an obvious answer here but how would the client best get notified that the webhook has been successfully received so they can move onward to the next page, like should they just ping the backend or is there some obvious way i'm not thinking of here ๐Ÿค”

vapid pendant
#

๐Ÿ‘‹ taking over for my colleague. Let me catch up.

#

before answering your question, QQ, are you using the confirmPayment's confirmParams.return_url for your redirection?

slow gust
#

uhh 1sec i'll try to see

vapid pendant
slow gust
#

it doesn't look like it currently no

#

edit: actually nvmnvm we are not using it ๐Ÿ˜ฌ

oh the return url no since it's a card payment. So we're using confirmCardPayment instead of confirmPayment

vapid pendant
#

are you using CardElements?

slow gust
#

Yes, these I believe. Basically using individual Iframes/elements for the relevant fields so we could use our own design (At least that is my understanding, my frontend knowledge is a bit limited)

vapid pendant
#

which is technically not what you're describing

slow gust
#

what do you mean? ๐Ÿ˜ฌ

#

Doesn't both of these implementations have a client response as well as a webhook after a successful payment?

vapid pendant
#

they work a bit differently

#

with PaymentElement you would use confirmPayment and it will call the right confirm method depending on the chosen PM type

#

and it will redirect once the confirmation is done

#

where as the confirmCardPayment works with CardElement and you'd have to redirect yourself after resolving the promise

slow gust
#

We do not use the full Stripe Payment Element though we use the individual components idk what the right piece of code to show that is but we have the different elements so we don't copy the entire iframe.

But it seems in both cases you do the re-direct to a page where the backend needs to have the updated status to be able to show the correct info (e.g that they have succesfully made a purchase and the contract is activated.).

The previous person recommended me to use webhooks in case something goes wrong which makes sense, but that leaves the remaining question whether whether they are redirected by us or the Stripe payment element, couldn't they be redirected to the next page before the webhook has reached our side and been processed (which is what actually confirms the payment and updates their account on the backend).

๐Ÿค”

vapid pendant
#

Ok but reading through the docs once more I was right the first time ๐Ÿคฆ

#

this param is only used with redirect payment methods

#

so let me sum things up here so you wouldn't get confused by my incompetence

#

so first things first, if you're using the confirmCardPayment in your frontend what you need to do is the following:
1- you should listen to the payment_intent.succeeded webhook events
2- you should await the Promise of confirmCardPayment (.then or await) which will resolve either in a paymentIntent or an error

#

in the case it's a successful payment Intent you can redirect the customer to the success page

#

especially the info box at the end

slow gust
#

but confirmCardPayment happens independently of the webhook right? It wouldn't wait for the webhook to be processed before it gets a successful response?

So it just seems like this is a race condition which the webhook is likely to lose and the customer might get sent to the page after purchase where they won't see their purchase in effect.

The frontend can just continually ping the backend after confirm_payment is done & true to check whether the webhook has been received and processed but wondering if there is a better way to do it ๐Ÿค”

vapid pendant
#

but confirmCardPayment happens independently of the webhook right? It wouldn't wait for the webhook to be processed before it gets a successful response?
correct

#

So it just seems like this is a race condition which the webhook is likely to lose and the customer might get sent to the page after purchase where they won't see their purchase in effect.
that's not a major issue to be honest, the success page might have a message saying "your order is being processed it will soon appear for you" or something of that kind

#

The frontend can just continually ping the backend after confirm_payment is done & true to check whether the webhook has been received and processed but wondering if there is a better way to do it ๐Ÿค”
that's one possibility, unless you have websockets setup which can be another way of your backend notifying the frontend that the order was processed

slow gust
#

okok, Was mostly just making sure there isn't any specific stripe way we are supposed to handle it (e.g a "waitForWebhookWithSuccess flag or something ๐Ÿ˜ฌ ). We'll figure it out. Thank you for the help ๐Ÿ™‡โ€โ™‚๏ธ

#

ah wait final question, any idea ฤฑf there is ever any noticable lagtime between a confirmed payment and the webhook being sent? Or does it basically always just happen immediately (obviously taking into account that the internet is not an instant affair for anything)

vapid pendant
slow gust
#

thanks ๐Ÿน

topaz coral
#

Hey going to archive this thread for now. If you have any further questions feel free to ask again in the main #dev-help channel

ivory cedarBOT
#

This thread has been archived. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact