Different challenge UI from web version

[stianjensen]

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.

[ramont-stripe]

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 #1892 (comment) for a more accurate explanation.

[olagjo]

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]

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]

@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:

stripe-ios/Stripe3DS2/Stripe3DS2/STDSChallengeResponse.h

Lines 16 to 38 in 39abf35

	/**
	The `STDSACSUIType` enum defines the type of UI to be presented.
	*/
	typedef NS_ENUM(NSInteger, STDSACSUIType) {
	/// No UI associated with the response.
	STDSACSUITypeNone = 0,
	/// Text challenge response UI.
	STDSACSUITypeText = 1,
	/// Single-select challenge response UI.
	STDSACSUITypeSingleSelect = 2,
	/// Multi-select challenge response UI.
	STDSACSUITypeMultiSelect = 3,
	/// Out Of Band challenge response UI.
	STDSACSUITypeOOB = 4,
	/// HTML challenge response UI.
	STDSACSUITypeHTML = 5,
	};

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]

@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]

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:

stripe-ios/Stripe3DS2/Stripe3DS2Tests/JSON/CRes.json

Lines 1 to 31 in 39abf35

	{
	"threeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
	"acsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340",
	"acsUiType": "01",
	"challengeAddInfo": "Additional information to be shown.",
	"challengeCompletionInd": "N",
	"challengeInfoHeader": "Header information",
	"challengeInfoLabel": "One-time-password",
	"challengeInfoText": "Please enter the received one-time-password",
	"challengeInfoTextIndicator": "N",
	"expandInfoLabel": "Additional instructions",
	"expandInfoText": "The issuer will send you via SMS a one-time password. Please enter the value in the designated input field above and press continue to complete the 3-D Secure authentication process.",
	"issuerImage": {
	"medium": "https://acs.com/medium_image.svg",
	"high": "https://acs.com/high_image.svg",
	"extraHigh": "https://acs.com/extraHigh_image.svg"
	},
	"messageType": "CRes",
	"messageVersion": "2.1.0",
	"psImage": {
	"medium": "https://ds.com/medium_image.svg",
	"high": "https://ds.com/high_image.svg",
	"extraHigh": "https://ds.com/extraHigh_image.svg"
	},
	"resendInformationLabel": "Send new One-time-password",
	"sdkTransID": "b2385523-a66c-4907-ac3c-91848e8c0067",
	"submitAuthenticationLabel": "Continue",
	"whyInfoLabel": "Why using 3-D Secure?",
	"whyInfoText": "Some explanation about why using 3-D Secure is an excellent idea as part of an online payment transaction",
	"acsCounterAtoS": "001"
	}

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]

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.

• No javascript, this excludes the national "bankid" service (which, confusingly is different from "bankid på mobil" which does not require javascript. Not all banks offer "bankid på mobil", although I guess this gives an incentive to start doing so - but that is not a short-term solution)
• No built-in input masking, this excludes (in the minds of the banks we spoke to) using an SMS+personal password flow. (Some banks have an SMS-only flow, but this is of course slightly less secure)

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]

I created a follow-up issue which is a feature request from the start (#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]

Thanks for sharing the learnings! I will pass this info to my team.

I will close this issue and follow up in #1895.