#Cédric Morelle
thin pelican
hello! no, the customer will be redirected to the return_url you pass once the confirmation is complete. Your return_url should make a request using the publishable key to get the status of the PaymentIntent to display to the customer.
Webhook processing should be handled asynchronously
spark knoll
Your return_url should make a request using the publishable key to get the status of the PaymentIntent to display to the customer
is there an exemple somewhere here?
in our case we expect using fast checkout and once payment done, to be redirected on the page where he was previously
thin pelican
you mean you don't want them to redirect to another page?
spark knoll
No, but let's explain us the workflow:
- user get in our site, and got a token stored in his cookie for his session
- he go to StripeCheckout and make his payment
- webhook is creating user if not existing, and then set his status as premium
- user is being redirected to page where he was before opening StripeCheckout form
So basically, it means, webhook is almost useless and I should bring to my return_url all my worflow
thin pelican
the webhook is important since the customer might close the page before redirecting to the return url and your callback occurs
thin pelican
no, you wouldn't need to wait for the webhook ended
why do you feel the the need to do so?
spark knoll
why do you feel the the need to do so?
there is no need to redirect user to anything unless we now if the payment is complete or not
if payment is complete THEN he should go to a specific page while when he is not complete it should go to somewhere else
thin pelican
why is there a need to differentiate though? you should be able to handle both flows in the same page
spark knoll
ok so may be my question is not good:
When calling return_url, we have to handle data provided here:
payment_ok?payment_intent=pi_3N904NAslfugMFd90IKdaxTe&payment_intent_client_secret=pi_3N904NAslfugMFd90IKdaxTe_secret_XNEBQqDijqq21uhoryZhKub3S&source_redirect_slug=test_YWNjdF8xR2ZuTDhBc2xmdWdNRmQ5LF9OdXBreUdpbU5Wb0VnMWJoS3RSNERxNEc2aUtZd0ZF0100iUV47nOs&stlContext=Stripe for exemple and check if Webhook ended ?
thin pelican
i suggest taking a look at this section : https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements#web-submit-payment - it mentions
Use one of the query parameters to retrieve the PaymentIntent. Inspect the status of the PaymentIntent to decide what to show your customers. You can also append your own query parameters when providing the return_url, which persist through the redirect process.
webhooks should be handled asynchronously i.e. you shouldn't be checking if your webhook ended on your frontend page
spark knoll
webhooks should be handled asynchronously i.e. you shouldn't be checking if your...
got it, please last question when using return_url, is status == "succeeded" and amount_received are guarantee to be accurate?
I mean when Stripe is calling back return_url are we sure amount is captured ?
thin pelican
you should always retrieve the PaymentIntent using the publishable key to verify what's the status
spark knoll
Sure but it’s not my question : when return url is being called IF payment done we immediately have status succeed if we retrieve paymentIntent ?
thin pelican
not necessarily
so if 3DS fails for example, i believe you will also be redirected to that page
you can test it out
unique shadowBOT
spark knoll
if 3DS fail it should send processing or may be requires_payment_method but never succeeded right ?
hushed tinsel
If the 3DS auth attempt fails, it'll always be requires_payment_method
spark knoll
ok thanks I think I have all in hand to finish our workflow