#shenlok-3ds
tiny prism
hello @umbral timber! could you share a bit more on what user state you'd lose upon return?
umbral timber
Hey @tiny prism sure thing. As I mentioned, we don't have a discrete checkout page, we aren't a traditional ecommerce site with a cart and checkout flow. Our app is a design tool and a common payment flow is when a user would be editing their design and have added some premium content (images etc). In order to download or otherwise publish a non-watermarked version of their design, users need to pay for each premium element they have used.
To do so, a user would click 'Publish' in the main toolbar, and the publish dropdown would open. They'd select to download or publish to some platform without watermarks, click continue, then be presented with some additional options, and eventually continue to the payment step in the flow. They'd choose their payment method, enter card details etc, and submit. At this stage they've entered various form data, selected options, progressed through a flow within a dropdown, etc. None of which is tied to any URL state.
If they were redirected to a 3DS challenge page now, it would be akin to just fully refreshing the page, and they'd have lost e.g the options they selected. We'd need to convey some state via the URL when returning from the 3DS page (what publish flow was the user going through? Do we need to trigger a download? Display a link to the published design on some external platform?). Or if the payment failed, the user now needs to go back through the flow and re-enter all their information. This would be exacerbated further for more complex flows, like printing and shipping physical goods rather than publishing digital designs.
And this is one payment flow on one page (albeit, the most complex and most commonly used flow). We have e.g subscription modal flows on other pages
austere hound
Hey there! Taking over from @tiny prism – let me catch-up!
austere hound
Sorry for the delay here. You mentioned an iframe implementation, which is possible. Had you seen this doc? https://stripe.com/docs/payments/3d-secure#custom-iframe
umbral timber
Yep I had given that one a read. I'm moreso trying to get info on why there is some advice out there against using iframes for 3DS challenges due to some issuers being incompatible (inadvertently or purposely)
Has stripe heard of any such compatibility issues with any issuer's 3DS challenge page implementations when using iframes?
austere hound
I personally haven't, no. But that's not to say they don't exist! Equally there are still teething problems on 3DS/auth flows with some issuers as SCA regulations are still rolling out and only just being implemented
I think our recommendation is to use the preferred Stripe.js implementation via our confirmation functions which is designed to function with the majority of issuers. The iframe stuff is a little off the beaten track (so to speak) so your results may vary
umbral timber
Makes sense! Thank you for taking the time 🙂
austere hound
Np!
compact trellis
Has stripe heard of any such compatibility issues with any issuer's 3DS challeng...
FWIW ,yes, 100%. Some of them use X-Frame-Options to block being framed. When we identify them we have a fallback that adds them those issuers to a list and we instead put a button in the popup to redirect to the challenge in a new tab (it's transparent to your code, the Promise from the stripe.js function resolves the same way)
umbral timber
Hm ok so you fall back to a native popup/new tab. We'd likely be rolling our own solution which is why I'm asking about these quirks. We route payments through gateways other than stripe depending on the market hence not being able to use your JS.
Where do you read the X-Frame-Options header?
compact trellis
it's a HTTP header served by the issuer for their ACS page with the challenge