Closed stianjensen closed 3 years ago
ramont-stripe
commented
3 years ago Hi @stianjensen, on mobile SDKs, the option is restricted to one as per the 3D Secure 2 specification. As of now, the specification only allows for one option, where the bank controls which one to use.
EDIT: Comment is not technically accurate. See https://github.com/stripe/stripe-ios/issues/1892#issuecomment-952213908 for a more accurate explanation.
olagjo
commented
3 years ago Hi @ramont-stripe, that is surprising to hear! I have a different bank, and I can see two options in the 3d secure 2 challenge flow (Sbanken app vs Bankid på mobil in the screenshot above). Additionally (with a different bank): In the webview version (via stripe elements) of 3d secure 2, I do get the choice between two different challenge flows (SMS vs Bankid in the screenshot below). This transaction is marked in the stripe dashboard as having been confirmed with 3d secure 2. (If I do the same flow on mobile, I only get one option, SMS)
So unless we misunderstand something fundamental, it seems to be possible to do a choice of flows in 3d secure 2, but the mobile app version of the flow presents fewer options than when it is presented online - can you help us understand the difference here?
olagjo
commented
3 years ago Just to clarify, the reason why we care about this is that many customers are now outright unable to pay in our app. Since there are so many methods of identification in Norway, there is no single method that supports everyone, even if they have the same card from the same bank. This means that limiting the number of choices to one (or even two) actually prohibits certain payments from being possible to authorize, if the bank does not choose the options wisely.
We are in contact with several of the banks in Norway, so any pointers on how to select which one of their options should actually be presented in the native 3d secure 2 flow would also be appreciated!
ramont-stripe
commented
3 years ago @olagjo It is possible, but the bank has to implement it. 3DS2 supports 5 different types of challenge UIs, and the bank has full control over which one we present in the mobile SDK and when. Think of it as 5 different templates, where they (banks) provide the content and we just render and report back the user input if needed. You can find them here:
In the screenshot you shared, the bank is using the "Single select" UI to let the user pick how to authenticate; depending on the selected option, the bank may instruct us to show a different UI next.
Unfortunately, this is something controlled by the bank. It may be worth to reach out to DNB on your end to see what they can do.
olagjo
commented
3 years ago @ramont-stripe Perfect, thank you!!
We have reached out to DNB and are in touch with Sbanken, so we are trying from several angles to figure out exactly who we need to talk to about this :)
Could you help me understand HOW the bank chooses which UI type should be selected? Is this a field in some JSON/XML payload you receive from them when initiating a challenge flow?
(I assume the names like STDSACSUITypeSingleSelect are internal to Stripe?)
Would it be at all possible for you to share an example payload or two so we can understand what it looks like when a bank choses SingleSelect vs MultiSelect (or even HTML)?
Is there a hierarchy of options, where the bank can provide a "first choice" and a "fallback?" - I am thinking about how it could be that the same bank on the same transaction provides different choices whether I go through the challenge flow in a web browser (react-stripe-js) vs in apps (stripe-ios, stripe-android)
ramont-stripe
commented
3 years ago Would it be at all possible for you to share an example payload or two so we can understand what it looks like when a bank choses SingleSelect vs MultiSelect (or even HTML)?
We have a sample CRes for the "Text" UI:
The acsUiType field is what determines which UI to use.
You can also obtain a copy of the 3DS2 protocol specification from EMVco, the consortium that maintains the spec.
Is there a hierarchy of options, where the bank can provide a "first choice" and a "fallback?" - I am thinking about how it could be that the same bank on the same transaction provides different choices whether I go through the challenge flow in a web browser (react-stripe-js) vs in apps (stripe-ios, stripe-android)
In a web browser you are served a page hosted by the bank. On native mobile we make API calls to their ACS. With them being two different systems, I can see how things can become inconsistent.
olagjo
commented
3 years ago Hi and thanks a lot @ramont-stripe, this is very clarifying! Armed with this we have reached out to the banks, and learned about the rationales behind their choices.
So it turns out that the protocol maintained by EMVco has certain limitations that exclude several of the Norwegian banks' authentication flows, e.g.
Based on this, the banks have been forced to not expose all their options in the native 3ds2 flow, making it a less complete (and for ~10% of Norwegian customers outright broken) authentication flow. As far as I understood, the Norwegian banks are currently working towards EMVco to enable more options due to these difficulties, but could of course not give a timeline on this.
For us as a Stripe customer, that means that we would love the ability to "force", prefer, or be able to swap to the webview-approach in our native apps. We have seen over the last few months that the view has been native or webview almost randomly swapping from transaction to transaction, but the last two weeks we have only observed the native view which is the least useful for us (although of course more convenient for the people who it works for).
Is this issue the right channel to report such a feature request?
olagjo
commented
3 years ago I created a follow-up issue which is a feature request from the start (https://github.com/stripe/stripe-ios/issues/1895), rather than starting out as a "bug report" which we originally thought this was. That could make the issue at hand a bit easier to parse without having to read a full history of discoveries.
I will leave it up to you which of these issues to keep open or close
ramont-stripe
commented
3 years ago Thanks for sharing the learnings! I will pass this info to my team.
I will close this issue and follow up in #1895.
Summary
In Norway, the major banks have started requesting 3d secure on many transactions now. We're having issues where banks allow several different ways to authenticate transactions (using a physical code generator, an app, sms-verification etc.) Our company allows payment on web, ios and android. But when performing 3d secure, the UI that is presented to the user is very different between the platforms. On web, you'll often get several options for how to authenticate your transaction. While with the ios-sdk, you often get only one of those options.
iOS version
14.x, 15.x
Installation method
Installed with cocoapods
SDK version
21.8.1
Other information
When using react-stripe-js on web:
With this SDK:
As you can see, on web I have the option to select between three different authentication options (UI provided by my bank).
On mobile, I only have the one option. This option is not always practical to use for our customers. They need the option to select between all methods.