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. 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 a valid cryptogram 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
- On an ecommerce site, the cardholder attempts to make a purchase.
- The ecommerce site sends a 3DS request to Galileo's access-control server (ACS).
- 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
objectecommerce
object
The validation_results
object
validation_results
objectThe aav
field in the validation_results
object contains one of these values to indicate whether the AAV or CAVV was valid:
Y
— ValidatedF
— FailedN
— Not present
The ecommerce
object
ecommerce
objectThis 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
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
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
.
aav_indicator
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
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
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
or06
to07
.
- null — Unknown. There is insufficient information in the transaction message, or the network didn't provide this information.
merchant_asserts_authenticated
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
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 istrue
, then the merchant did attempt to authenticate the cardholder. - If
merchant_asserts_authenticated: true
and this field istrue
, then the merchant did send a fully authenticated CAVV/AAV.
- If
- 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.
- The CAVV/AAV was not present. For example, if
Galileo setup
Galileo sets this parameter value for 3DS support.
Parameter | Value | Description |
---|---|---|
AAVPV | G | Galileo retrieves the cryptogram from DE048 for validation. If no data is present, then Galileo does not perform the cryptogram validation and returns aav: N . If Galileo cannot validate the cryptogram because it is malformed or incorrect, Galileo returns aav: F (failure). |
raw_eci
values
raw_eci
valuesThese 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.
Value | Definition |
---|---|
210 | Present in unauthenticated transactions, or in transactions where an Identity Check merchant has chosen not to undertake Identity Check, or where Identity Check failed authentication and the merchant desires to proceed with the transaction. Also present in transactions with a DTVC |
211 | Mastercard Identity Check transaction. UCAF data contains either an Attempts AAV or a Non-Low Risk AAV for Mastercard Identity Check from Smart Authentication |
212 | Mastercard Identity Check transaction. UCAF data contains a fully authenticated AAV for Mastercard Identity Check or a Low-Risk AAV for Mastercard Identity Check from Smart Authentication. |
214 | Mastercard Identity Check where merchant has chosen to share data to generate insights within the authorization (used in Identity Check Insights or Ekata transactions). Insights or Ekata scores are provided to the issuer in DE 48, subelement 56. |
216 | Mastercard Identity Check transaction. Merchant Risk Based Decisioning. This includes European PSD2 Acquirer Exemption transactions |
217 | Mastercard Identity Check transaction. Merchant Initiated Transactions. NOTE: Mastercard Identity Check split shipments should be managed as 1 authentication, 1 authorization, and multiple clearing records. |
242 | Authenticated tokenized transaction with DSRP cryptogram. Transaction is not eligible for fraud-related chargeback by the issuer |
246 | Tokenized transaction with DSRP cryptogram |
247 | Tokenized Merchant Initiated Transaction |
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.
Value | Definition |
---|---|
05 | Fully authenticated CAVV verification submissions |
06 | Non-authenticated security transactions at a 3-D Secure-capable merchant. The merchant attempted to authenticate the cardholder using 3-D Secure. |
07 | Non-authenticated security submissions. |
08 | Nonsecure submissions |
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.
Value | Definition |
---|---|
0 | Unknown/unspecified |
1 | Transaction is not an ecommerce transaction |
4 | In-app authentication |
5 | Card transaction is a secure ecommerce transaction (cardholder authenticated using Discover ProtectBuy) |
6 | Merchant attempted to authenticate the cardholder information using ProtectBuy, but was not able to complete authentication because the cardholder or the issuer does not participate in ProtectBuy |
7 | Ecommerce card transaction with data protection but not using ProtectBuy for cardholder authentication |
8 | Ecommerce card transaction without data protection |
9 | Reserved |
B | Buy online pickup in store (BOPIS) |
Updated 7 days ago