1. Home
2. Security
3. PSD2
4. 3-D Secure status guide

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 Hosted Payment Page 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)
  
  
  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

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”)

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 Hosted Payment Page 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

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

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 Hosted Payment Page 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”

The image shows where to configure the continue/interrupt feature in the Back Office

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