1. Introduction

With the introduction of the PSD2 guideline, it is more important than ever to keep track of your 3-D Secure transactions.

Whether you use e-Commerce or DirectLink, we make this really easy for you. Use this guide to learn where to look and how to read the available information.

Become a 3-D Secure expert in no time!

2. Understand 3-D Secure statuses

Apart from clearly defined exclusions and exemptions, any of your customers will have to pass a 3-D Secure authentication check. The transaction reaches both a 3-D Secure status (which is the outcome of the authentication check) and a global transaction status (which indicates the outcome of the authorisation request).

Hence, both are the result of two different steps:

  • 3-D Secure status: First, your customer has to prove that s/he is the rightful owner of the credit card used for the transaction. This authentication check takes place on your customer’s issuer online portal. An overview about possible outcomes is visible in our parameter cookbook (check parameter ECI_3DS)
  • Global transaction status: Second, your acquirer checks by consulting your customer’s issuer whether enough funds are available for the transaction, resulting in an (un)successful authorisation. An overview about possible outcomes is visible in our transaction status guide

You can look up the results both manually in the Back Office and with our electronic  Reporting-tool:

  • Back Office: Look up the transaction in Operations > View transactions. In the overview, check “Status” (which is the global transaction status) and the image combined with a description (which is the 3-D Secure status)
    3DSstatusguide_1.png

    The image shows where to look up the 3-D Secure status and the global transaction status in the Back Office

  • Reporting: Make sure to configure your Electronic reporting profile as described in our dedicated video. Parameters ECI / STATUS indicate the 3-D Secure status/Global transaction status respectively

Not all financial institutions are already fully compliant with PSD2 (which is also called 3-D Secure Version 2). In a case like this, our platform rolls out version 1 instead. We mark transactions as such by adding "V1"/"V2" in the Back Office/parameter VERSION_3DS in the Reporting respectively.

If you process transactions via e-Commerce, our platform rolls out version 1 automatically for you.

The table below gives you a full overview of possible scenarios and how our platform displays them to you in either way:

3-D Secure status (Back Office) 3-D Secure status (parameter ECI in Reporting Transaction status Description
Full thumb up/
"Cardholder has been successfully identified! V1"
5 Depending on the authorisation result by your acquirer either
2
5
9
Your customer has passed the authentication check. In case of fraudulent chargebacks, the issuer is liable
Half thumb up/
"Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)"
6
12
Depending on the authorisation result by your acquirer either
2
5
9
Your customer did not have the opportunity to perform the authentication check.
In case of fraudulent chargebacks, the issuer is liable
Exclamation mark sign/
"Cardholder authentication failed!"
91 2 Your customer did not pass the authentication check because of i.e. incorrect password/PIN. Our platform does not execute the authorisation step at all, abandoning the transaction
No image/
"Cardholder authentication not technically possible!!!"
92 Depending on the authorisation result by your acquirer and your preference either
2
5
9
Authentication was not possible due to a technical error.
By default, Our platform does not execute the authorisation step at all, abandoning the transaction (status 2).
However, our platform allows you to choose to go for the authorisation nevertheless, as described in the dedicated chapter.
Full thumb up/
"Cardholder has been successfully identified! V2 challenge"
5 Depending on the authorisation result by your acquirer either
2
5
9

Your customer has passed the authentication check, actively identifying her/himself according to the SCA protocol (“Challenge flow”).

In case of fraudulent chargebacks, the issuer is liable

Full thumb up/
“Cardholder has been successfully identified! V2 frictionless”
5 Depending on the authorisation result by your acquirer either
2
5
9
Your customer has passed the authentication. As you have provided sufficient information along with the transaction according to the SCA protocol, your customer did not have to actively identify her/himself (“Frictionless flow”)
Also check the field "3DS Liability", giving you an indication about the liability shift for fraudulent transactions.
Be aware that this is only an indication, as the definite accountability depends on various factors.

3. Understand Authentication log

On top of knowing the 3-D Secure status for your transactions, our platform stores the log files for every authentication check. These files contain detailed information about the exact flow that leads to the result of the authentication check.
Look up this information for any transaction in the Back Office via Operations > View transactions. By clicking on "AUTHENTICATION LOG" in the overview, you access a table overview. Each line represents one individual step of a complete authentication check.

Column Description
MsgType

Step executed of the current authentication check.
Possible values:

  • V2_1 – AuthenticationRequest: An authentication request sent by our platform (via e-Commerce integration mode) or your server (via DirectLink integration mode) according to the PSD2 guidline
  • V2_1 – ChallengeRequest: The issuer request that your customer has to actively identify her/himself according to the SCA protocol
  • V2_1 – ChallengeResponse: Your customer’s authentication check result
  • V2_1 – AuthenticationResponse: Your customer’s issuer response to the authentication request (resulting either in a challenge or frictionless flow)

If our platform had to roll out 3-D Secure Version 1, the following values are possible:

  • V1 – VerifyEnrollment: Our platform rolled out 3-D Secure Version 1
  • V1 – ValidatePares: Your customer’s authentication check result
  • V1 – FallbackDetail: Information about the reason our platform had to fallback to 3-D Secure Version 1
Status

Status/result of the executed step.
Possible values:

  • "–": No status/result (yet)
  • C – Challence required: You/the issuer requests a challenge flow
  • Y – Authentication Verification Successful: Your customer has passed the authentication check
  • N – Authentication Verification Failed: Your customer did not pass the authentication check

If our platform had to roll out 3-D Secure Version 1, the following values are possible:

  • Succeeded: Your customer has passed the authentication check
  • Failed: Your customer did not pass the authentication check
Date

Time stamp of the executed step

Details

Information/parameters of the executed step.
Possible values:

  • Enrollmentstatus: indicates whether the cardholder is enrolled for 3DS
  • browserJavascriptEnabled: Indicates whether your customer’s browser could run JavaScript
  • threeDSServerURL: Card scheme server routing the authentication check
  • mcc: your MCC according to ISO 28245
  • merchantName: Your company name as defined in the Back Office
  • purchaseCurrency: The currency used for this transaction according to ISO 4217
  • messageVersion: The 3-D Secure version rolled out for this authentication check
  • messageType: The definition of the executed step
  • AReq: authentication request
  • CReq: challenge flow request
  • ARes: authentication response
  • CRes: challenge flow response
Card N°

The card used during the respective step

3DSstatusguide_1.png

The image shows where to look up the authentication logs in the Back Office

3DSstatusguide_3.1.png

The image shows a typical table containing authentication logs in the Back Office

Understand and handle fallback to 3-D Secure v1

It is possible that our platform processes transactions in 3-D Secure v1 mode (check column "MsgType" in the Authentication log accordingly). Pay attention to these, as v1 will be decomissioned altogether in October 2022. To help you deal with such transactions, have a look at the table with possible causes and solutions:

Error message (column "MsgType") Description Solution
V2ParamMissing Missing mandatory v2 parameters Make sure to update your DirectLink integration accordingly. If you process transactions via our e-Commerce solution, we take care of this for you
acquirerBIN/acquirerMerchantID not recognized You need to be enrolled for v2 at MasterCard Contact either your acquirer or us to request this
"Detail":"billAddrCountry; V2Error caused fallback to v1
"Detail":"billAddrLine1,billAddrLine2
"Detail":"cardholderName;
"Detail":"email;
"Detail":"acctNumber;
"Detail":"browserLanguage"
"Detail":"acctInfo.nbPurchaseAccount,acctInfo.txnActivityDay,acctInfo.txnActivityYear"
"Detail":"Name(s) of erroneous fields separated by (,) : acctInfo.suspiciousAccActivity,threeDSRequestorAuthenticationInfo.threeDSReqAuthMethod,
acctInfo.shipAddressUsageInd,acctInfo.chAccAgeInd,acctInfo.shipNameIndicator,acctInfo.paymentAccAge,acctInfo.paymentAccInd,acctInfo.shipAddressUsage"
Error received from the directory server (DS). ISO code not valid per ISO tables (for either country or currency)

Invalid parameters sent for (mandatory) v2 parameters.

Make sure to update your DirectLink integration accordingly.

Error received from the DS. Format of one or more elements is invalid according to the specification","Detail":"threeDSRequestorURL" You website’s details in the Back Office are not correct (Configuration > Account > Your administrative details > Website address)

Correct your URL in the Back Office

Specific reason fallbacks to V1 because transaction status will be blocked by issuer
MC Fallback to V1 since Transaction status reason is 82
Cb Fallback to V1 since Transaction status reason is 13
Unspecified errors

These errors happen at a third party, the solution is out of your hands

4. Continue/Interrupt transaction flow

Following PSD2 guidelines, transactions for which a authentication check could not be rolled out due to technical problems, reach status 2 by default. Our platform interrupts the transaction by not executing the authorisation at all.

However, you can overrule this default scenario by instructing our platform to continue with the authorisation step nevertheless. To use this option, follow these steps:

  • Log in to the Back Office. Go to Advanced > Fraud Detection > 3D-Secure
  • Select the payment method for which you want to overrule the default scenario by clicking on “EDIT”
  • Select radio button option “Continue” for both “Continue/interrupt the transaction if a technical problem prevents connection to the VISA directory during the 3D-Secure registration check.” and “Continue/interrupt the transaction if the cardholder identification service is temporarily unavailable”. Confirm by clicking “SUBMIT”


3DSstatusguide_4.png
The image shows where to configure the continue/interrupt feature in the Back Office

  • If you use this option, you can be held liable for fraudulent chargebacks

  • There is high probability that your transaction still reaches status 2, as per PSD2 every online shopper must pass an authentication check

    5. Partial end of liability shift

    All the major schemes listed below are aligned and determined to ensure that the official 3DS v1 switch off happens in October 2022:

    • VISA
    • Mastercard
    • American Express
    • JCB
    • Diners Discover

    VISA and Mastercard already announced a transition period towards EMV 3DS. 

    Essentially, only fully authenticated transactions will be supported by both VISA and Mastercard, resulting in a decrease of fraud liability protection for merchants using 3DS v1.

    You will be able to see this in the Back Office as "Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)" and ECI=12 in the post-sale feedback.

    For the same message "Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)" and ECI=6, the liability shift still applies.

    Visa

    Visa Secure 3DS V1 Before 16th October 2021 After 16th October 2021
    Fully Authenticated (issuer participates) Fraud liability shifts to the issuer (ECI=5) No change
    Attempted authentication (issuer not participating) Fraud liability shifts to the issuer (ECI=12) Fraud liability with the merchant (ECI=12)
    Enrollment result=N

    Mastercard

    Mastercard Identity Check 3DS V1 Before 5th October 2021 After 5th October 2021
    Fully Authenticated (issuer participates) Fraud liability shifts to the issuer (ECI=5) No change
    Attempted authentication (issuer not participating) Fraud liability shifts to the issuer (ECI=12) Fraud liability with the merchant (ECI=12)
    Enrollment result=N