How an ACS Picks a 3DS Challenge Method and Renders It

Most issuers configured a 3DS challenge method once and have not revisited it. In a large number of cases that method is a passcode sent by text message, applied to everyone, on every device, in every channel.

Selecting a 3DS challenge method is not a static setting. The protocol gives the ACS inputs that should make it a decision, and issuers that treat it as one see better completion for the same level of assurance.

What the ACS knows before it chooses

The device information supplied to the ACS can indicate the capabilities of the device, and that information can inform the presentation of authentication methods during a challenge.

In app-based flows this is rich. The SDK collects a substantial data set through operating system APIs, covering the device, the operating system and its version, and interface preferences and settings. In browser flows it is thinner but not nothing.

Alongside capability sits enrolment. Whether the cardholder has an authentication app installed, whether they have registered a cryptographic credential, and whether the device is bound to their account are all inputs the ACS may hold.

The point is that the ACS is not choosing blind. It is choosing with information most implementations discard.

How the choice is communicated

Two elements carry the decision to the SDK in an app-based flow. One indicates the authentication method the ACS will use. The other indicates the initial interface and template the ACS requires the SDK to present. Both are required in the authentication response when a challenge is requested, and both are reported again in the results message when the challenge completes.

That second point is worth dwelling on for anyone who wants to improve this. Because the method and the rendering type are reported in the results message, you already have the data to analyse which methods and templates correlate with completion across your own portfolio. Very few issuers look at it.

The constraint nobody accounts for

A capability limit that reshapes the whole decision on some devices.

Where a Limited SDK or Limited Split-SDK is in use, only dynamic challenges are supported. Static data such as a password is not available at all.

So for constrained client environments, the choice is narrower than your configuration screen suggests, and a method relying on something the cardholder knows and types from memory simply cannot be presented. Any selection logic that can route to a static method needs a branch for this.

Multi-select, and a length trap worth knowing

Where the ACS offers the cardholder a choice of how to authenticate, it supplies the options as key and value pairs.

On versions 2.1.0 and 2.2.0 there is a constraint that has caught implementations out. The combined length of the keys matters, because the cardholder’s selection has to fit within a separate element with its own maximum length. Where the total key length is too great and the cardholder selects several options, their response does not fit, and the SDK cannot send it back to the ACS.

That produces a challenge the cardholder completes and the system cannot process, which is close to the worst possible failure mode.

Version 2.3.1.1 resolved it structurally by limiting the number of options and capping the key length, so that the selection always fits even when every option is chosen and the ACS no longer has to manage the total. If you are on an earlier version and offer multi-select challenges, check your key naming.

Autofill, and why it needs testing before it ships

Version 2.3.1.1 supports the autofill function commonly used in mobile applications. In a challenge, the ACS indicates that autofill is supported for data entry and specifies the expected data entry type, either a password or a passcode sent by text message.

On the face of it this is a straightforward win. Manual code entry is a measurable source of abandonment, and removing it should help.

EMVCo’s caution is specific and worth heeding. On iOS, autofill uses heuristics to decide when the operating system can input the best possible entry automatically. Where a challenge presents two data entries on the same screen, the heuristics may assume they are a username and password pair and fill both regardless of the declared entry type. iOS may also suggest an existing stored credential that has nothing to do with the challenge.

EMVCo strongly recommends that ACSs test autofill on iOS before offering it to cardholders, and notes that other operating systems may have similar heuristics.

That is the right framing for the feature generally. Autofill is a completion improvement with a platform dependency, and platform behaviour is not something the specification controls.

Where out-of-band fits

Out-of-band is often the best method available, and its viability depends heavily on channel.

In an app-based flow it can be close to seamless. In a browser flow on a mobile device it has documented failure modes related to how the operating system manages memory and application state, which are covered separately.

There is also a small dependency in the app flow worth knowing when configuring it. Where the ACS supplies the out-of-band app URL without the accompanying label, the SDK does not return an error and the flow does not end. It simply does not display the button, and the cardholder has to switch manually. A configuration omission silently downgrades the experience.

A better way to configure this

Four steps, in order.

Stop defaulting. Establish what proportion of your challenges currently use each method. In most portfolios one method dominates for historical rather than considered reasons.

Segment by channel first. App, mobile browser and desktop browser have materially different completion characteristics for the same method. A single global choice is guaranteed to be wrong for two of the three.

Use the enrolment you already have. A cardholder with an authentication app installed and a device bound to their account is a different proposition from one you have never seen.

Measure with the data you are already receiving. The method and rendering type come back in the results message. Compare completion across methods and channels in your own portfolio rather than relying on industry generalisations, which will not reflect your cardholder base.

Frequently Asked Questions

Can the merchant influence which challenge method the cardholder gets?

Not directly. The ACS chooses the method and the template. The merchant’s influence is indirect, through the quality of the data it supplies for risk assessment and through the client environment its integration provides.

Why can some devices not present a password challenge?

Because a Limited SDK or Limited Split-SDK supports only dynamic challenges. Static data such as a password is not available in those environments, so any selection logic that can route to a static method needs a branch for constrained clients.

Is autofill safe to enable?

It improves completion, but platform heuristics can override your intent. On iOS, autofill may fill both entries on a two-field screen regardless of the declared entry type, or suggest an unrelated stored credential. EMVCo strongly recommends testing on iOS before offering it, and notes other platforms may behave similarly.

What happens if we offer too many multi-select options?

On versions 2.1.0 and 2.2.0, where the combined key length is too great and the cardholder selects several options, the response does not fit in the element carrying it and the SDK cannot return it. Version 2.3.1.1 resolved this by limiting the option count and capping key length.

Reviewing your challenge configuration? ActiveAccess is the GPayments Access Control Server solution for issuers and processing centres. Speak with a 3DS specialist about challenge method selection.