3D Secure is a security standard that was designed to enable additional security in online payments. Datatrans supports 3D Secure 2 for any brand supporting the security protocol - including Mastercard, Visa, and American Express. 3D Secure may or may not be applied depending on your merchant’s configuration.

📘

Questions related to 3D Secure?

Get in touch with us today and we'll make sure to answer your questions related to 3D Secure, conversion, and more. Send us a message by using our contact form any time.

Mandatory Data for 3DS Processing

Starting from 12th August 2024, Visa will require various data fields to be mandatory for 3DS authentication processing. These fields, previously required only in certain conditional circumstances, must now be provided in all cases.

You must provide valid consumer data in your initial requests. The mandatory and optional parameters are within the 3D object nested inside card.3D.cardholder for init requests and 3D.cardholder for secureFields init requests. In addition to the required fields, other parameters are strongly recommended to be sent.

These changes aim to enhance authorization success rates and improve fraud prevention measures, making 3DS authentication more seamless and frictionless for customers. While there are currently no additional fees for not sending valid data, Visa is anticipated to introduce enhanced monitoring of these fields. This may lead to increased costs if data compliance is not met. Please refer to our init endpoint and secure fields init endpoint documentation for further details and technical specifications.

Required fields

• Cardholder Name (3D.cardholder.cardholderName)
• At least one of the following:
  • Cardholder Email Address (3D.cardholder.email)
  • Cardholder Home Phone Number (3D.cardholder.homePhone)
  • Cardholder Mobile Number (3D.cardholder.mobilePhone)
  • Cardholder Work Number (3D.cardholder.workPhone)

Strongly recommended fields

• Cardholder Billing Address (3D.cardholder.billAddrLine1)
• Cardholder Billing Address Postal Code (3D.cardholder.billAddrPostCode)
• Cardholder Billing City (3D.cardholder.billAddrCity)
• Cardholder Billing State (3D.cardholder.billAddrState)
• Cardholder Billing Country (3D.cardholder.billAddrCountry)

"3D": {
  "cardholder" : {
    "cardholderName": "John Doe",
    "email": "[email protected]",
    "homePhone": {
      "cc": "41",
      "subscriber": "791234567"
    },
    "mobilePhone": {
      "cc": "41",
      "subscriber": "791234567"
    },
    "workPhone": {
      "cc": "41",
      "subscriber": "791234567"
    },
    "billAddrLine1": "Some Street 123",
    "billAddrPostCode": "8008",
    "billAddrCity": "Zurich",
    "billAddrState": "ZH",
    "billAddrCountry": "756",
    ...
  }
}

3D Secure response

We return the directory response for any transaction where a 3D Secure verification can take place and the authentication response for any transaction where a 3D Secure challenge flow was completed. In other words: directoryResponse tells you if a card is enrolled or needs authentication and authenticationResponse returns the challenge flow response. You may also show the returned information in cardHolderInfo to your customers - This message is optionally returned by the issuer for the cardholder. transStatusReason gives you additional information on the failed 3D authentication.

Directory Response	Code	Description
Authenticated	Y	The card or account was authenticated seamlessly with 3D Secure. No challenge flow will take place.
Failed	N	The card or account failed to be authenticated seamlessly with 3D Secure. A challenge flow is required to finalize the authentication.
Error	U	The authentication or account verification could not be performed. This is usually linked to technical problems.
Authentication Performed	A	One or more 3D Secure authentication attempts were performed, but no authentication or account verification was completed successfully. This serves as proof that 3D Secure authentication was attempted. Typically this is returned if a card is not enrolled for 3D Secure. In this case, the issuer covers the liability, and there should be nothing to worry about.
Challenge Required	C	An additional authentication is required to finalize this transaction.
Declined	R	The issuer rejected the authentication or account verification. No authorization will take place.

Authentication Response	Code	Description
Successful	Y	The authentication or account verification was successful.
Failed	N	The authentication or account could not be verified. This will be returned when the authentication fails.
Error	U	The authentication or account verification could not be performed. This is usually linked to technical problems.
Authentication Performed	A	One or more 3D Secure authentication attempts were performed, but no authentication or account verification was completed successfully. This serves as proof that 3D Secure authentication was attempted. Typically this is returned if a card is not enrolled for 3D Secure. In this case, the issuer covers the liability, and there should be nothing to worry about.
Challenge Required	C	The challenge flow requires an additional authentication process. The authentication process is incomplete.
Authentication Rejected	R	The issuer rejected the authentication or account verification.

3D Secure 2

3D Secure 2 (3DS2) is an enhanced version protocol of 3D Secure that aims to reduce fraud and adds further security measures for online card transactions. 3DS2 introduced a broader set of data for creating more frictionless card payments. Acquirers and issuers in some regions had to be ready for 3D Secure 2 as of the 1st of April 2019.

The advantages of 3D Secure 2 for merchants include an enhanced conversion rate and risk measures, frictionless flows, a more harmonized look for 3D Secure, new methods of authentication, and more.

Actions required as a merchant

To integrate 3DS2 correctly, you will need to check three things accordingly.

• One is the enrollment for 3DS2 of your acquirer. Acquirers will enroll any merchant for 3D Secure 2 that is already registered for 3D Secure 1. We are actively working with acquirers to receive all information needed for the merchant enrollment on our side. Stay informed with your account manager at Datatrans and at your acquiring partner for more information on your upcoming auto-enrolment. Most merchants will not need to apply any changes.

• Two, 3D Secure 2 requires many parameters. This data is classified into three main categories: Device Information, Browser Information, and Merchant Risk Information. The latter consists of cardholder account information, specific purchase information, prior transaction authentication information, and merchant cardholder account authentication information.
  The submitted data allows issuers to run transaction-based risk analyses. The more data a merchant provides, the better are the chances for a frictionless flow to be applied during the transaction. The newly mandatory elements are covered by Datatrans. The conditional and optional fields can be specified by you. Please refer to our init endpoint for further details. You will find the conditional and optional parameters inside the object 3D nested inside the object card. Each issuer will handle the additional parameters differently. In addition, there is no guarantee for frictionless flows.

• Three, you may have to update your data privacy. The terms and conditions of the European General Data Protection Regulation GDPR are not in contradiction to the PSD2 requirements on Strong Customer Authentication. Neither are they to the 3D Secure 2 authentication protocol. They rather provide a legal framework for processing authentication data in a secure and protective manner. This means that GDPR compliance is a prerequisite to meet the PSD2 and 3D Secure 2 requirements.

Merchants can decide which optional and conditional data are sent to the issuer for risk scoring purposes. It is important that cardholders are informed in your privacy policy about the optional or conditional data being processed. Many of the new parameters are linked to personal data and subject to GDPR. The responsibility for processing biometric information (e.g. fingerprints) and any other sensitive information resides with the issuer. No further actions have to be taken in this regard.

For Strong Customer Authentication (SCA) exemptions and soft declines, please refer to our dedicated section SCA Exemptions of the documentation.

Dynamic 3D secure

Our product Dynamic 3D Secure takes care of applying 3D Secure authentication only if your client's card issuer is from an EEA country. Based on the card number, we are able to identify if this is the case or not. While this product may reduce friction during checkouts, especially for countries where 3D Secure is not as dominant as it is in EEA countries, the liability shift protection will be completely missing for such transactions. We do recommend enforcing 3D Secure whenever possible.

📘

Use dynamic 3D Secure at your own risk!

Although it is our goal to only offer smooth payment processes to our merchants, malfunctioning or inappropriate configuration can never be completely excluded. This would ultimately lead to additional authentication and authorization errors. Datatrans is not liable for errors caused by malfunctioning or a misconfiguration of Dynamic 3D Secure.

To activate Dynamic 3D Secure, please get in touch with your account manager at Datatrans or send us a message by using our contact form.