Allow falling back to webview in 3d secure 2 flow

[olagjo]

Summary

• We would like the ability to fall back to a webview approach for 3ds2 payment authorization, even if the native approach is available
• The reason for this is that many Norwegian customers are currently excluded from authorizing payments due to unfortunate oddities in the Norwegian banking space (see details below)

Code to reproduce

Not exactly code, but:

• Be a customer of SpareBank1 or Danske Bank (big challengers, 20-30% market share in total) and get "BankId"
• Switch to DNB (incumbent, 50%+ market share) which primarily uses "BankId på mobil"
• Initiate a payment through the Stripe SDK
• You will now be presented with a screen where your only option is to use "Bankid på mobil", which you don't have (see Different challenge UI from web version #1892)

iOS version

14.x, 15.x

Installation method

Installed with cocoapods

SDK version

21.8.1

Other information

• There are several oddities in the Norwegian banking space, limiting which authorization methods are available to a regular customer
  • Different banks have different authorization mechanisms (e.g. "Bankid" vs "Bankid på mobil")
  • If you change banks, you keep your old authorization mechanism, so many people have an "atypical" authorization mechanism within their own bank
  • Due to limitations in the protocol, several of the more common fallback authorization mechanisms are excluded from being shown in the native flow ("Bankid" needs javascript, SMS + personal password requires maskable inputs)
• Due to these oddities, the options that are presented in a native could leave you as a customer without any possible path through the native authorization flows of your own bank
• The webview version has fewer limitations, and as such the banks show more options, meaning every customer has access to a fallback mechanism
• Because of this, as a Norway-based merchant we would like to have the ability in the Stripe SDK to fall back to the webview-based flow for customers that can't use the native flow (or in the worst case: always)

[ramont-stripe]

@olagjo thank you for the very detailed information! I will open an internal ticket that mirrors this, and we will keep this issue updated. I cannot promise that this will get implemented because there may be regulations and constraints that I'm not yet aware of. But we will definitely look into this.

[davidme-stripe]

We're working on a solution for this. If you're experiencing this issue and would like to opt into our testing program, please email 3ds2-mobile-fallback@stripe.com with your account ID. Thanks!

[olagjo]

Thank you @davidme-stripe!
We are very interested in this and are following up through our account manager :)

A FYI for others that might stumble upon this issue with similar difficulties:
We have been in touch with a few Norwegian banks and they confirm that they purposely leave several of their authorization options out of the native 3DS2 flow due to the limitations in the protocol (lack of masked inputs, no support for javascript).

The ones we talked to had no plans of changing this until they have been able to get through to the 3DS2 working group to update the protocol. This is obviously a slow-moving and unreliable process, so if you are experiencing this issue as a merchant, you will likely want to work around it :) I imagine similar situations also arise in other countries, but at least this is the current status for Norway