3-D Secure Access-Control Server

Card-not-present (CNP) transactions are especially vulnerable to fraud, because the fraudster does not need to manufacture or steal a physical card to present it in person at a point of sale. To help verify that the legitimate cardholder is making a CNP transaction, many online merchants require an additional layer of authentication.

The 3-D Secure (3DS) protocol provides the framework for authenticating CNP transactions. Many countries and jurisdictions require 3DS for online transactions. Galileo's support for 3DS helps you comply with such requirements. Even where 3DS is not required, you can provide an extra layer of security that can help reduce CNP fraud and help strengthen your chargeback rights. 3DS must be explicitly supported by an online merchant to initiate a 3DS verification.

On 3DS-enabled ecommerce sites, the merchant verifies the cardholder's identity before sending the authorization request for the transaction. The verification request is sent to an access-control server (ACS) that is on the issuer side. Using the risk-based authentication feature in 3-D Secure v2, the ACS evaluates the request based on the risk profile previously configured by the issuer, which contains attributes such as:

• 3DS challenge request
• Threat matrix risk score
• Transaction amount
• Merchant ID, country, or currency
• MCC
• Recent cardholder activity
• Recurring or installment transaction
• Mobile wallet data
• Network risk score
• 24-hour velocity
• Recurring payments
• Payment category
• Currency
• Device channel

Depending on the rules configured by the issuer, the transaction could be considered low or high risk. If the risk is considered low, the transaction could take the "frictionless" path, which means that the cardholder does not need to interact further with the system. The ACS returns a "success" cryptogram to the merchant.

On the other hand, if the risk score is high, then a "step-up" might be required, which means that the ACS sends a one-time password (OTP) to the cardholder over SMS (text message), and the cardholder inputs the OTP in the merchant's interface. If the OTP is correct, the cardholder is authenticated, and the ACS returns the "success" cryptogram to the merchant.

After the cardholder is thus authenticated, the merchant sends the issuer a conventional authorization request that includes the success cryptogram. Galileo validates the cryptogram — and if the cryptogram is valid, it increases the likelihood that the transaction will be approved.

When a merchant successfully authenticates a cardholder prior to sending an authorization request, there is a liability shift from the merchant to the issuer. A transaction that is authenticated using 3DS cannot be disputed by the issuer as fraudulent. (The issuer can still dispute a transaction for other reasons.)

In the case that the cardholder's identity cannot be verified, the merchant usually cancels the transaction, and the merchant never sends the authorization request.

3DS portal

When Galileo performs the initial setup for your program, you get access to a web portal where you can see data related to your 3DS transactions, such as transaction volume, transaction amounts, challenge rate, and transaction statuses. From this interface you can perform analysis and download reports as well as create dashboards. You can provide varying levels of access to selected employees, who can view, create reports, and perform analysis. You can also create, modify and update risk profiles, and you can emulate 3DS transactions by using the merchant simulator.

Rule set

Drawing on its extensive experience in fraud detection, Galileo will recommend some rules that can be applied during 3DS verification. Galileo will train you to use the risk engine and will provide specific documentation that contains the types of rules that can be created and their attributes. You can create and adjust the baseline risk profile using the portal.

Challenge interface

This HTML form is hosted by Galileo and displayed on the merchant site in the case of a step-up. The cardholder inputs the OTP in the interface, which sends the OTP directly to Galileo for verification.

3DS authorization workflow

1. On an ecommerce site, the cardholder attempts to make a purchase.
2. The ecommerce site sends a 3DS request to Galileo's access-control server (ACS).
3. Galileo retrieves the cardholder information and applies risk rules. Based on the results, Galileo determines whether a step-up is needed:
   • No step-up — The ACS returns a "success" cryptogram to the merchant, and the merchant sends the cryptogram in the authorization request.
   • Step-up needed — The ACS sends an OTP to the cardholder's mobile number via SMS.
   • If a fraudster is performing the transaction, the OTP goes to a mobile phone that the fraudster does not own, and so authentication fails.
   • A legitimate cardholder inputs the OTP in the merchant's interface.
   • The merchant sends the OTP to the ACS for validation.
   • If the OTP is valid, the ACS sends a "success" cryptogram to the merchant, and the merchant includes that cryptogram in the authorization request.
   • If the OTP is not valid the merchant has the option to:
     • Cancel the transaction.
     • Accept the risk and send the authorization request anyway, with no cryptogram.

When the authorization request arrives, Galileo evaluates the 3DS authentication information along with the rest of the authorization request's information. Galileo approves or denies the request based on all of the information in the authentication request. Successful 3DS authentication is more likely to result in an approval.

Viewing 3DS information

You can view 3DS information for a transaction in the following places:

• 3DS Customer Portal — This web interface provides real-time reports on 3DS activity.
• Auth API – The Auth API message contains details about 3DS authentication attempts.
• RDFs — The RDFs have this information:
  • SLI INDICATOR — Security-level indicator, in both the Authorized Transactions and Posted Transactions RDFs, which contains DE048SE42 for Mastercard transactions.
  • PDS0185 — In the Posted Transactions RDF, this contains the account-holder authentication value (AAV) for Mastercard or the cardholder authentication verification value (CAAV) for Visa.

Auth API

If you are using the Auth API, you can use the 3DS values that Galileo passes to you to help in your decisioning. Galileo passes the this information to you in two places:

• validation_results object
• ecommerce object

The validation_results object

The aav field in the validation_results object contains one of these values to indicate whether the AAV or CAVV was valid:

• Y — Validated
• F — Failed
• N — Not present

The ecommerce object

This object contains information related to 3DS authentication, if the website supports 3DS. Included in this information is the result of validating the AAV for Mastercard or the CAVV for Visa.

E-commerce information is provided for Visa, Mastercard, and Discover only. None of the other networks provide 3DS information in their authorization requests, so for those network requests, is_ecommerce: null (unknown) and the ecommerce object will not be present.

is_ecommerce

Specifies whether the transaction took place on a web site that supports 3DS. Possible values:

• true — This transaction took place on a website that supports 3DS. The remaining fields in the ecommerce object will be present and non-null if known.
• false — This transaction did not take place on a website that supports 3DS. None of the remaining fields in the ecommerce object will be present.
• null — Unknown whether this transaction took place on a website that supports 3DS, because there was inconsistent or missing information in the transaction. In some cases the raw_eci will still be provided.

raw_eci

The electronic commerce indicator (ECI) that is sent in the authorization request. The meaning of this value varies by network. The ECI is called Security Level Indicator (SLI) by Mastercard and Ecommerce Transaction Indicator (ETI) by Discover.

Click a link below to see the possible values for each network. The remaining fields in the ecommerce object further break out the meaning of the raw_eci.

• Mastercard SLIs
• Visa ECIs
• Discover ETIs

aav_indicator

Mastercard only. The Universal Cardholder Authentication Field, which is populated by Mastercard Identity Check to indicate authentication type and authentication provider.

merchant_asserts_data_protection

Specifies whether the merchant reports that the HTTP transmission was encrypted. Possible values:

• true — The merchant or acquirer asserts that the communication channel between the cardholder and the merchant is encrypted, such as with TLS/HTTPS.
• false — The merchant or acquirer makes no guarantee about the security of the communication channel with the cardholder, meaning that HTTP may have been used instead of HTTPS. You should proceed with caution when this field is false. A malicious third party could have compromised the transaction.
• null — Unknown, because there is insufficient information in the transaction message, or the network doesn't provide this information.

merchant_asserts_authentication_attempted

Specifies whether the merchant reports that 3DS authentication was attempted. Possible values:

• true — The merchant or acquirer asserts that it attempted to authenticate the cardholder using 3DS, and that one of these conditions is true:
  • Authentication was done, meaning that a full 3DS authentication flow happened and the cardholder was authenticated. The cardholder was challenged and passed the challenges.
  • Authentication was not done because Galileo or the network decided that full 3DS authentication was not necessary.
  • The frictionless flow or 3DS authentication has not been set up for this product.
• false — One of the following occurred:
  • The merchant or acquirer did not try to authenticate the cardholder.
  • The merchant did attempt to authenticate the cardholder but encountered an error and decided to proceed anyway.
  • The cardholder authentication failed.
  • The merchant asserted that it attempted to authenticate, but it sent invalid data in the transaction and the network downgraded the merchant's assertion. For Visa, if a merchant doesn't send a CAVV, Visa will automatically downgrade the ECI from 05 or 06 to 07.
• null — Unknown. There is insufficient information in the transaction message, or the network didn't provide this information.

merchant_asserts_authenticated

Specifies whether the merchant reports that the cardholder was successfully authenticated. Possible values:

• true — The merchant or acquirer asserts that it received a fully authenticated CAVV/AAV using 3DS, meaning that either the cardholder was fully authenticated with a challenge or the frictionless flow was used.
• false — The merchant or acquirer makes no assertion whether the cardholder is fully authenticated using 3DS, meaning that the merchant or network was unable to carry out the entire 3DS flow, and the merchant was given an "attempt" CAVV/AAV.
• null — Unknown. There is insufficient information in the transaction message, or the network didn't provide this information.

merchant_authentication_assertions_validated

Contains validation results of the merchant's assertions. This field does not validate the merchant_asserts_data_protection field, which is the merchant's assertion about HTTPS/TLS. Possible values:

• true — The merchant's assertions have been validated, meaning that there is a CAVV or AAV in the transaction message and it is valid. Visa allows sending a CAVV even when there is no data protection (merchant_asserts_data_protection: false). You should proceed with caution with such transactions, even when the CAVV is valid.
  • If merchant_asserts_authentication_attempted: true and this field is true, then the merchant did attempt to authenticate the cardholder.
  • If merchant_asserts_authenticated: true and this field is true, then the merchant did send a fully authenticated CAVV/AAV.
• false — The merchant's assertions could not be validated, meaning that there is a CAVV/AAV in the authorization request but it is not valid. In almost all cases you should decline the transaction.
• null — No attempt was made to validate the merchant's assertions. One of the following is true:
  • The CAVV/AAV was not present. For example, if merchant_asserts_authentication_attempted: false, the merchant probably didn't send a CAVV/AAV.
  • The CAVV/AAV was not validated, because the product has not been configured to do CAVV/AAV validation. You should proceed with caution when CAVV/AAV validation is not configured, because now you are trusting the merchant's assertion.

Galileo setup

Galileo sets this parameter value for 3DS support.

raw_eci values

These are the valid values for the raw_eci field from each network.

Mastercard SLIs

These definitions are lifted from Mastercard's Customer Interface Specification, 11 July 2023 for DE048 subelement 42. Consult the documentation from Mastercard to see the breakout of the individual digits. Mastercard's 3-D Secure implementation is called Identity Check.

Visa ECIs

These definitions are based on VisaNet Authorization-Only Online Messages — Technical Specifications, 15 October 2023, for Field 60.8 (positions 9–10). Consult the documentation from Visa to see additional details. Visa's 3-D Secure implementation is called Visa Secure.

Discover ETIs

These definitions are lifted from Discover's Authorization Interface R22.2 Field Definitions, 14 Oct 2022 for Field 61 position 9. Discover's 3-D Secure implementation is called ProtectBuy.