#jonathanhayuniverse_best-practices
ruby viperBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1275143474693275679
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hearty voidBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- jonathanhayuniverse_paypal-deferred-intent, 2 days ago, 7 messages
restive basin
Unfortunately no. The Payment Element confirm method (https://docs.stripe.com/js/payment_intents/confirm_payment) requires a URL to direct to after opening the 3rd party page
dusky grail
Is there a way to at least open the 3rd party page in a new window even if the redirect is required?
Via the payment element
We're concerned about losing the state of our cart which is at the moment ephemeral
restive basin
The 3rd party page should still open in a new window. Have you tested this yet? You should be seeing an i-frame open up for things like 3DS and 3rd party auth pages
dusky grail
I'm attempting to use paypal and the authorization page seems to be redirected to rather than open in a new window.
I'm redirected to https://stripe.com/payment_methods/test_payment?payment_attempt=x when confirming the payment
restive basin
Ahhhh, that's right. PayPal might be a little different. In any case, can't you pass your cart to the back-end when you call stripe.confirmPayment() so it doesn't get lost for that session? You could also use cookies that persist for the session, so you can grab them after the redirect, though I would not recommend this if you intend to use those cookies for provisioning services, since the customer could exit the page or have a networking error that would cause the cart to be lost before you can cache it more permanently.
dusky grail
Yes we could do that but were just hoping to avoid it with the current phase of our integration. Thank you for the info, this is very helpful!
restive basin
One alternative before you go: you might consider just passing the cart items as metadata to the Payment/Setup Intent, so that you can easily retrieve them later on. This will remove the need to cache the items as cookies that might not last through the payment flow.
https://docs.stripe.com/api/payment_intents/create#create_payment_intent-metadata
dusky grail
Interesting! Thank you, that sounds like a good solution.
restive basin
Sure thing!
dusky grail
What is the best practice for handling these sorts of redirects if the Payment Element is embedded in an iframe?
Here's an example, if you click on get tickets that would open the iFrame
restive basin
Hmmmm, I think we generally discourage trying to get that setup because of how many edge-cases can result in either PayPal erroring out, or auth failures causing redirects that can't access the i-frame again post-PayPal redirect.
As far as I can tell, with PayPal specifically this just basically isn't supported. The livemode redirect link can be placed inside an iframe, but PayPal will attempt to redirect the parent page (that contains the iframe) to paypal.com after the buyer has logged in. If the parent page does not allow the iframe to redirect itself to PayPal, then the iframe will show an error message that something went wrong. I believe PayPal behaves this way because they believe that showing by "paypal.com" in the address bar people know that they can trust they are dealing with PayPal.
ruby viperBOT
dusky grail
We're also using an older integration with individual card and payment method elements where we see paypal as a new window rather than a full redirect. Is this going to be deprecated at any point to your knowledge?
Just to clarify regarding the redirect question above, we're not necessarily looking to embed the paypal page in an iframe, we just want to know if we can redirect back to a page in our app that is itself embedded in an iframe and if there are best practices to follow there.
ornate veldt
We don't have any plans to deprecate those individual payment methods currently. So you should be fine to integrate them individually. And for what it is worth when we do deprecate things, we typically make sure to be proactive in identifying effected users, reaching out, and giving a comfortable time to transition though. So that may give some piece of mind too.
I am not quite following your proposed here. Are you saying after a full page redirect and you link back to your original page, that you are trying to do something with the state of portion of the page that is in an iframe? Or something else?
dusky grail
Our application is sometimes embedded into other 3rd party sites as an iframe, so yes we'd want to update the state of our app which is embeded within the iframe. We just want to make sure with this integration, payment methods which require navigating to an outside source then redirecting back to our app are still compatible with this setup. This is why generally speaking we would prefer being able to open a payment method page such as paypal auth in a new window to begin with rather than navigating away from our app.
I think you had said that is not possible though if I understood you correctly. It seems to be possible with individual pm elements but not with the fully integrated Payment Element to open in a new tab.
ornate veldt
I think I may have misread your previous message. So your page with the individual PayPal integration is not already opening this in a new window to avoid a redirect, and you are trying to figure out if even that part is possible? I am still trying to find what if anything we have documented about trying to create a new tab or window from an iframe.
dusky grail
It is opening in a new window for the individual paypal integration. I am having trouble replicating this using the Payment Element
Ideally we'd like to transition everything to the Payment Element
ornate veldt
Unfortunately I am not finding guidance here. I will reach out to my colleagues and see if there is anything they know of
full breach
👋
Yeah Paypal won't work with Payment Element in an iframe. Instead you might consider using Express Checkout Element (https://docs.stripe.com/elements/express-checkout-element) for Paypal.
For other payment method types that require a redirect you would need to use the inidivual Elements for those as well if you are going to rely on an iframe
dusky grail
Can an express checkout element co-exist with the payment element? We still want to accept card payments.
full breach
Yep
dusky grail
Do you have a full list of accepted payment methods compatible with the express element?
dusky grail
It's not very clear here which of these are one-click payment methods. Is it only these five? We're looking to support more and would need to use them embedded within an iframe. These are what we're trying to support:
Apple Pay / Google Pay
PayPal
Bancontact
iDEAL
Sofort
EPS
full breach
Yeah only Apple Pay / Google Pay / Paypal are supported in Express Checkout Element
The rest are not and you would need to integrate them directly without Payment Element if you are going to rely on an iframe
dusky grail
Alright thank you for your help! I'll take this away and let you know if I have any other questions.
full breach
👍