6.2. 3-D Secure (3DS)

3-D Secure (3DS) technology implies the pre-authentication of the participants. The particular technology supposes that the liability for authenticated transaction refusal is shifted from the internet shop to the issuer bank, then, to the cardholder. In the 3-D Secure technology, the transactions require the special password known only to the customer (cardholder) and to the issuer bank. This allows to reduce the number of Internet transaction refusals.

3-D Secure is based on the Tree-Domain Model in which the process of online transaction authentication is subdivided into three domains: Issuer Domain, Acquirer Domain and Interoperability Domain.

Issuer Domain includes: bank that issued the credit card, Access Control Server (ACS), customer intending to make a purchase by credit card, software on the customer computer (Web Browser).

Acquirer Domain includes: merchant or Internet shop (whose WEB-site is used for the purchase), Internet shop server software which creates and processes the payment authentication messages and acquirer – financial institution which interacts with the authorization system (such as VisaNet/Europay Payment System Net) according to the agreement concluded with the Internet shop and informs the shop of the authorization results.

Interoperability Domain. Visa or MasterCard domain provides communication between customer, Internet-shop and Banks. At that, the domain ensures strict privacy of the information. To authenticate the customer, system sends an authentication request to the issuer bank. The issuer establishes connection to the customer, presents a secret phrase and inquires the customer password. Once the customer password is verified, the issuer bank generates response. Then, the acquirer bank authenticates the Internet shop.

6.2.1. 3-D Secure flow Diagram

@startuml participant Cardholder participant "Merchant Application" participant "Apropay" box "Interoperability Domain" #LightBlue participant "Directory Server" participant "ACS Server" end box participant Acquirer participant Issuer "Acquirer" -> "Issuer": Inter\nSettlement Cardholder -> "Merchant Application": Shopping +\nTransaction Data "Merchant Application" -> "Apropay" : 3DS Transaction\nRequest Message "Apropay" -> "Directory Server": 3DS Enrolment\nRequest(VEReq) "Directory Server" -> "ACS Server": 3DS Enrolment\nRequest(VEReq) "ACS Server" -> "Directory Server": 3DS Enrolment\nResponse(VERes) "Directory Server" -> "Apropay": 3DS Enrolment\nResponse(VERes) "Apropay" <-> Acquirer: Apropay Risk Setting = Process All Transactions "Apropay" -> "Merchant Application": Transaction\nResponse Message "Merchant Application" ->o "Apropay": Get Transaction Request "Apropay" -> "Merchant Application": Payer Authentication Request(PAReq)\n Redirect Cardholder browser to ACS server page "Merchant Application" -> "Cardholder": Payer Authentication Request(PAReq)\n Redirect Cardholder browser to ACS server page "Cardholder" -> "ACS Server": 3DS Payer Authentication Request (PAReq) activate "ACS Server" "ACS Server" -> "ACS Server": Cardholder Authentication "ACS Server" -> "ACS Server": MHS Message "ACS Server" -> "Apropay": 3DS Payer Authentication Response(PARes) deactivate "ACS Server" "Apropay" <-> Acquirer: Process Transaction "Apropay" -> "Merchant Application": Transaction Response\nMessage "Merchant Application" ->o "Apropay": Get Transaction Request @enduml

When Cardholder submits an order in Merchants Application the following process is triggered:
  • The Cardholder specifies the card number and CVV2;
  • The Merchants Application requests Apropay via MPI (Merchant Plugin Interface) billing system in order to get the address of ACS Server (Access Control Server) bank issuer;
  • Apropay system redirects the Cardholder to ACS Server bank issuer;
  • The Cardholder is authenticated at the Issuer then is redirected to the system Apropay with the results of authentication;
  • Apropay system authorizes the transaction in the Acquirer, if the result of the authentication was successful.

6.2.2. Verify Enrollment Response Error message

Error message Error code
Error message Error code
Acquirer not participating 50
Merchant not participating 51
Password Missing 52
Incorrect password 53
Incorrect Common Name value in Client Certificate 54

6.2.3. Verify Enrollment Response Values

Enrollment Response Description VERes Status
Authentication Available Cardholder is enrolled, Activation During Shopping is supported, or proof of attempted authentication available. The merchant uses the URL of issuer ACS included in VERes to create the Payer Authentication Request Y
Cardholder Not Participating Cardholder Not Participating - Cardholder is not enrolled N
Unable to Authenticate or Card Not Eligible for Attempts Unable to Authenticate or Card Not Eligible for Attempts (such as a Commercial or anonymous Prepaid card) U

6.2.4. Issuer Authentication Results Values

Authentication Result Authentication Result Determined by Issuer ACS PARes Status
Authentication Successful The issuer has authenticated the cardholder by verifying the password or other identity information Y
Attempts Processing Performed Authentication was not available, but functionality was available (through the issuer, the Visa Attempts Service, or a third party) to generate a proof the merchant attempted VbV authentication A
Authentication Failed

The cardholder’s password (or other authentication information) failed validation, thus, the issuer is not able to authenticate the cardholder. The following are reasons to fail an authentication:

  • Cardholder fails to correctly enter the authentication information within the issuer-defined number of entries (possible indication of fraudulent user)
  • Cardholder “cancels” authentication page (possible indication of a fraudulent user)

Merchants are not permitted to submit these transactions for authorization processing

 N
Authentication Could Not Be Performed

The issuer ACS is not able to complete the authentication request – possible reasons include:

  • Card type is excluded from attempts (such as a Commercial Card or an anonymous Prepaid Card)
  • ACS not able to handle authentication request message
  • ACS is not able to establish an SSL session with cardholder browser
  • System failure that prevents proper processing of the authentication request

Merchants may proceed with the above purchases as non-authenticated and retain liability if the cardholder later disputes making the purchase. These are non-Verified by Visa electronic commerce transactions

When the PARes has a U and an Invalid Request Code of 55, this indicates that the Account Identifier in the PAReq did not match the value returned by the ACS in the VERes. Merchants must view this as an invalid transaction

 U

6.2.5. Visa Electronic Commerce Indicator (ECI)

Name ECI Description
Cardholder was authenticated 5 This value means that the cardholder was authenticated by the issuer by verifying the cardholder’s password or identity information. The value is returned by the ACS in the Payer Authentication Response message when the cardholder successfully passed 3-D Secure payment authentication
Merchant attempted to authenticate the cardholder 6 This value means that the merchant attempted to authenticate the cardholder, but either the cardholder or issuer was not participating. The value should be returned by the ACS in the Authentication Response message for an Attempt Response. Additionally, merchants may use an ECI 6 in the authorization request when a Verify Enrollment of N is received from the Visa Directory Server
Payment authentication was not performed 7 This value is set by the merchant when the payment transaction was conducted over a secure channel (for example, SSL/TLS), but payment authentication was not performed, or when the issuer responded that authentication could not be performed. An ECI 7 applies when either the Verify Enrollment or the Payer Authentication Response contains a U for Unable to Authenticate

6.2.6. MasterCard E-Commerce Commerce Indicator (ECI)

Name ECI Description
Merchant attempted to authenticate the cardholder 01 Authentication could not be completed but a proof of authentication attempt was provided
Cardholder was authenticated 02 Cardholder was successfully authenticated

6.2.7. 3-D Secure authentication Result

UI Information VERes Status PARes Status CAVV/AAV ECI Visa ECI MasterCard Description MasterCard recommended Name
Merchant Not SecureCode-enabled - - - - - Merchant Not SecureCode-enabled Merchant Not SecureCode-enabled
DS Error (%d) Error - - 7 - The merchant was unable to provide the appropriate credentials to the Directory Server Error on VERes
Not Eligible U - - 7 - Unable to Authenticate Unable to Authenticate
Not Participating N - - 6 - Cardholder Not Participating Cardholder Not Participating
3-D Secure Error Y Error - - - PARes validation failed. Merchant should not submit authorization request Error on PARes
3-D Secure Failed Y N - - - Authentication Failed. Merchant should not submit authorization request Auth Failure (SecureCode failure or Signature verification incorrect)
3-D Secure ACS Error Y U - 7 - The issuer ACS is not able to complete the authentication request Unable to Authenticate
3-D Secure Attempt Y A No - 01 - Attempt (without AAV)
Full 3-D Secure Attempt Y A Yes 6 01 Merchant attempted to authenticate the cardholder, but either the cardholder or issuer was not participating Attempt
3-D Secure Successful Y Y No - 02 Authentication Successful without AAV Auth Success (without AAV)
Full 3-D Secure Successful Y Y Yes 5 02 Authentication Successful Auth Success