Acoipat

[sonic abyss]

hey there! if the payment method requires a redirect, there is no way for this to happen automatically.
You can set up your confirmPayment options to use redirect=if_required to reduce this to only when required
https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect

With server confirmation flows, you can pass a return_url which indicates you want to handle the 3ds/auth redirect yourself, which you could open in a new tab. This is much more complex, and you'd still have an issue with getting back to the initial app tab, so I don't recommend going this route.

[graceful ruin]

Gotcha, yep we're already using that parameter and thinking about disabling some payment flows like linking a bank account

Could you dive in a bit more to what you mean by server confirmation flows? Or link to us to a start point in the docs 😄

I suppose this implies that if not doing the server confirmation flow, that Stripe Elements automatically does the redirect without us having control over it?

Opening an iframe sounds fairly straightforward, as described in the docs with message passing.

[sonic abyss]

Server confirmation: https://stripe.com/docs/payments/finalize-payments-on-the-server
Manual 3ds handling: https://stripe.com/docs/payments/3d-secure#manual-redirect

[graceful ruin]

Cool, thanks! So it sounds like the main change in this flow is:

• No longer create PaymentIntent at teh beginning of the payment flow
• The web client calls an intermediate endpoint to create a "payment method" via Stripe SDK stripe.createPaymentMethod when the user submits the form with all payment info filled out
• After the PaymentMethod, call an endpoint on our server that both creates the PaymentIntent and attempts to confirm it in one step. Confirming might fail if 3DS is required, which the client can handle by displaying the 3DS auth flow in an iframe modal (or new tab)

Is the tradeoff here that there is more error handling pushed to the client, vs it being handled in Stripe Elements? is there any chance that Stripe Elements will plan to offer a built-in option to render the redirect flows in an iframe or separate tab

[dreamy anvil]

👋 hopping in here since synthrider had to head out

Quick question for you - are you ONLY focused on cards, or do you care about additional payment method types?

[graceful ruin]

We care primarily about cards, but also would like to support Google + Apple Pay, Paypal, possibly BNPL, and possibly bank accounts and other methods. We've been told that bank accounts often have redirects that are not avoidable, and I've also seen that in my anedotal experience — but if we can avoid redirects for cards (3DS), would be relaly good!

We understand we'll probably still need to implement support to handle the redirect flow, especiially if bank accounts are enabled

[dreamy anvil]

Gotcha

Just wanted to check, because if you were only using cards you wouldn't have to worry about the redirect

So in terms of what the tradeoff is - I'd say the biggest one is that each payment method type will potentially need their next action handled a slightly different way. While a large number will just be redirecting to a url (next_action.redirect_to_url https://stripe.com/docs/api/payment_intents/object#payment_intent_object-next_action-redirect_to_url) others like cashapp or alipay have different actions that need to be fulfilled

[graceful ruin]

Just wanted to check, because if you were only using cards you wouldn't have to worry about the redirect

Not sure I understand that, we were told from support that 3DS can be triggered for cards in Europe:

3DS is required for European card payments in order to remain compliant with Strong Customer Authentication (SCA) requirements.

The only time 3DS would be prompted when SCA is not required would be as a fraud prevention measure. You would be able to disable any 3DS Radar rules: https://stripe.com/docs/payments/3d-secure

[dreamy anvil]

Yes, 3DS will be triggered, but it's not a redirect-based payment method. We'll usually display 3DS in a iframe to complete

[graceful ruin]

Ahhh ok, gotcha. It seems like if redirect_to_url is present in the response, we can always render that URL in an iframe/tab, but otherwise, call stripe.handleNextAction?

We'll usually display 3DS in a iframe to complete
ohhh ok, interesting! We haven't tried any of the 3DS test cards yet, still trying to clarify everything before implementing. But that sounds promsing for us since we'll probably start with just cards + G/Apple Pay!

[dreamy anvil]

Kind of - 3DS specifically can be displayed in an iframe, but other bank-redirect payment methods cannot

So no, if redirect_to_url is present in the response that's not a guarantee you can render it in an iframe because we use that action for other payment method types as well

[graceful ruin]

Ok, thanks! So to summarize:

• if we just enable cards, G pay, Apple pay, and Stripe Link, we should be safe to implement with the standard Stripe Elements flow, since 3DS is handled in an iframe by default
• if we add bank accounts and other payment methods, we should try and handle the redirect ourselves with the Create + Confirm flow (server-side payment confirmation). But this isn't guaranteed to be possible in the first place, from what I can tell, it sounds like some redirect flows cannot be rendered in an iframe? Possibly it could be done with a new tab, but there would be some (unreliable) polling that needs to be implemented on the main tab, I guess

[dreamy anvil]

Yes to both!

*But this isn't guaranteed to be possible in the first place, from what I can tell, it sounds like some redirect flows cannot be rendered in an iframe? *
Yeah I don't have an exhaustive list, but part of the reason why we require redirects for some of these is that the actual banks themselves have banned the use of an iframe for their site