What’s new in EMVCo 3DSecure 2.2

EMVCo 3DSecure 2.2 brings enhanced functionality as the SCA protocol matures and consolidates its experience with over two years of deployment.

3DSecure 2.2 is now available and has been provided by Endeavour for the past few months.

Version 2.2 brings improvements and new features to the previous 2.1 Version. Because the schemes are free to deploy their own functionality via Message Extensions rather then wait for the EMVCo specification to be updated, many of the new functionality is in fact available in Version 2.1 as a Message Extension, but is now promoted as an integral part of the core specification.

Its not just Message Extensions which allow schemes to deploy new functionality. Many of the message values also have a range reserved for the schemes in the 80 to 99 range. Some of these settings can also be expected to become part of the  core specification.

Multi-Version Protocol

Version 2.2 bring a new challenge in that this is the first time that multiple versions of EMVCo 3DS will run in parallel. There will be no clean upgrade from version 2.1 to 2.2 but rather the new version will be phased in and after a long period of having both versions in production, the older version will be phased out. Its quite possible, in fact, that at some point Versions 2.1, 2.2, 2.3 and even 2.4 will be all active in production.

3DS 2 was always designed to be a multi-version protocol – this is part of its strength. But merchants must now work out a strategy on how to decide the version to use for any particular transaction. In most cases a merchant simply wants regular authentication so the merchant does not need to be distracted by the intricacies brought about by different versions.

New Capabilities

The new changes can be summarized as follows:

• Issuer Capabilities
• Merchant White Listing (Trusted Beneficiaries )
• Decoupled Authentication
• Merchant Initiated Transactions
• SCA Exemptions
• Different Types of Transactions

Issuer Capabilities

Endeavour has made this functionality available for a long time and so will familiar to our users. This information tells the merchant not only which versions the Issuer supports but also the functionality. This functionality can be summarized as follows:

• Authentication Available at ACS
• Attempts Supported by ACS or DS
• Decoupled Authentication Supported
• White Listing Supported
• Data Only Supported by Issuer
• Card Range is enrolled in Smart Authentication Direct
• Card Range supports payment transactions
• Card Range supports non-payment transactions
• Card Range supports the app channel
• Card Range supports the browser channel
• Card Range supports app-based ACS/Issuer Challenge Capabilities
• Card Range supports browser-based ACS/Issuer Challenge Capabilities
• Card Range is Enrolled in Identity Check Express
• Card range supports Authentication Express Merchant Delegation for Identity Check Express (Type I)
• Card range supports Authentication Express Low Fraud Merchant (Type II)
• Card Range participates in Authentication Express Wallet Delegation

This information is key to answering the question set above. How will be the merchant know what version to use? The Merchant must first check what versions are supported by the scheme and the Issuer – if for example a function is specific to version 2.2 only and the Issuer supports 2.2, then it is possible to send a 2.2 message to use the function; the merchant can then formulate the message to access the functionality.

Merchant White Listing / Trusted Beneficiaries

Version 2.2 has extend support for Merchant White Listing and is the recommend version for this functionality. Its now possible to check the status of a Merchant’s Whitelisting. Its is also much easier in 2.2 for the merchant to evoke 3DS exemption with Merchant Whitelisting.

Decoupled Authentication

Decoupled Authentication is a great addition to Authentication. Decoupled Authentication can be used when the card holder is not immediately available to complete an authentication. The Merchant fires off an Decoupled Authentication Request, giving the Cardholder up to 7 days to complete the authentication. The authentication is typically completed on the Issuer Banking App with the Cardholder simply acknowledging the request.

Expanded 3RI/MIT Transactions

3RI stands for 3DS Requestor (Merchant) Initiated Transaction. 3RI is not new to 2.2, but the field ThreeRIInd has been expanded to include the following new options.

• Split Delayed Shipment
• Top Up
• Mail Order
• Telephone Order
• White List Status Check

ThreeDSRequestorChallengeInd / SCA Exemptions

The field ThreeDSRequestorChallengeInd has been expanded to bring more SCA Exemptions into the core specification. The following new values have been added:

• No Challenge Requested (TRA Already Performed)
• No Challenge Requested (Data Share Only)
• No Challenge Requested (SCA Already Performed)
• No Challenge Requested (Utilize Whitelist Exemption if no challenge required)
• Challenge Requested (Whitelist Prompt Requested if challenge required)

Different Transaction Categories

Different type of transaction categories can now be distinguished within 3DS. These are summarized below.