3DSecure Changes for both versions 1.0.2 and 2.0

Changes coming to 3DSecure in April with more following in the coming months for both Visa and MasterCard.

MasterCard

In April MasterCard will roll out changes to the ‘Merchant Data’ message extension bringing their format in line with the formats used by Visa, Amex and other schemes. This MasterCard message extension is a fundamental part of MasterCard 2.1PLUS and is the mechanism for supporting Secure Corporate Payments, One Leg Transactions and White Listing as well as SCA Exemptions and Merchant Fraud Rate.

Requests containing message extensions that do not conform to the new specifications will have the erroneous fields automatically dropped by the MasterCard directory but the messages will still be forwarded to the Issuers.

MasterCard is also updating the format for the contents of the 3DS Requestor Prior Transaction Authentication field in AReq. This field is defined as a JSON string in the EMVCo specifications and the specific format of this field has been left to the card scheme to define according to their requirements.

Furthermore, from 15 September 2021 MasterCard will make changes to the Transaction Status Reason logic to make sure that the combinations of transStatusReason and transStatus sent by the ACS meet the logic set by MasterCard.

Endeavour will be monitoring these changes to ensure merchants get the benefits and avoid any negative impact on processing.

Visa

Version 1.0.2

Visa has also announced a number of changes. Some of these changes are taking place for Version 1.0.2 to ensure that Visa Tokens work seamlessly under this old protocol. The Endeavour 1.0.2. platform already fully supports Visa Tokens.

The CAVV algorithm used for Version 1.0.2 is also being updated from CAVV Usage 3 Version 1 (CAVV V1) to CAVV Usage 3 Version 7 (CAVV V7). V7 enables issuers to easily differentiate 3DS 1.0.2 attempts transactions from EMV 3DS attempts transactions. VisaNet will recognize and verify the Visa Attempts CAVV following Issuer’s Attempts CAVV settings.

Visa has lagged behind MasterCard with regards to supporting an Attempts Server and we often see Visa responses taking too long when they should have failed over to an Attempts Server. Proper support for an Attempts Server is therefore welcome news and will contribute greatly towards the smooth running of 3DSecure services.

Version 2

3RI Transactions with “Challenge” Transaction Status

ARes messages with transStatus of ”C” (Challenge) will be disallowed in 3RI Transactions (Device Channel 03). If an Issuer’s ACS is returning such a message, Visa will reject the message and return an Error Code of 203 (Format of one or more Data Elements is Invalid according to the Specification).

New Authentication Methods in RReq Message

Visa will support 5 new codes for the Authentication Method field in RREQ for values 92 through 96, which fall in the DS Specific range. This change applies to both Versions 2.1 and 2.2.

Validation on Token ID&V Requests

Token ID&V requests must not use Device Channel 03 (3RI) since these transactions are intended to result in a challenging flow to be successful. Token ID&V requests must be marked with a Message Category 02 (NPA) since they are not payment requests. ACS Providers should not expect to receive Token ID&V requests through the 3RI Device Channel

Support for Travel Extension

The EMVCo Travel Message Extension Specifications was announced some time ago in 2020. With this change, Visa will now support this extension and pass it on to Issuers.

8 Digit BIN Codes on the horizon

Looking forward to next year, 8 digit BIN codes will become a reality in 2022. Endeavour is already proactively making the necessary changes to support this transition. 8 Digit BIN codes are a reflection of the rapid growth and importance of card payments in a connected world.

Need support? Contact us here