Apexx Global

1. What is 3D Secure?

1.1. Definition

3D Secure (3DS) stands for Three Domain Secure, a security protocol used to add an additional layer of authentication to card-not-present (CNP) transactions. It ensures that the person initiating the transaction is the legitimate cardholder.

This is an authentication protocol (not authorisation) which takes place before the payment is authorised. There is no payment interaction with 3DS, it is a standalone authentication interaction which can happen through a banking app or through a One-Time Password (OTP).

The three domains refer to: 

• Issuer domain (cardholder's bank)

• Acquirer domain (merchant's bank)

• Interoperability domain (infrastructure provided by card schemes)

3DS is facilitated by communication between the issuing bank and an Access Control Server (ACS). 

What is the purpose of an Access Control Server (ACS)? 

An ACS is a server on the issuing bank’s side that verifies cardholder identity during online transactions and allows issuing banks to verify authentication requests. Gateways may use third-party ACS providers or develop their own.

The issuer decides whether to process the authentication as frictionless, or go through the challenge flow, based on data received via the ACS, including:

• Device fingerprint

• IP address

• Billing/shipping address

• Browser metadata

• Purchase history (i.e. a recurring transaction with the same retailer)

• Time and amount of transaction

If insufficient data is provided, the transaction is unusual, or the amount is high, a challenge flow is triggered.

1.2. Types of Authentication in 3DS2

There are two high-level types of authentication under 3DS2 - frictionless and challenge.

• Frictionless Authentication

In a frictionless authentication, the issuing bank perceives that the transaction is low-risk and they do not need to confirm that the customer is actually there, nor that they own the card and the device the transaction can be authenticated on. 

The issuing bank determines whether they allow for an authentication to be frictionless based on the information that is communicated by the ACS, including address, browser data, device data and fingerprint, for example. Similarly, for lower-value transaction, the frictionless flow may be preferred. The more data is sent to the issuing bank as part of the authentication request, the more likely the issuing bank will go for a frictionless authentication.

In this case, the consumer is not asked to interact with an interface (e.g., no OTP or banking app interaction) and the transaction will process automatically. 

• Challenge Authentication

  • The consumer must authenticate via a banking app or by entering an OTP.

  • Triggered if the transaction is considered high risk, involves a new merchant, has limited data provided, or exceeds a certain value.

An issuing bank will choose to present a challenge to their customer if they do not deem the transaction as low risk. A challenge may be enforced for example, if the amount is high, it is a new merchant the cardholder has never transacted at before, or there is less data (e.g. no device data collection, or IP address) in the enrollment request. 

In the challenge flow, the cardholder is presented either with some form of window into which to add the OTP, or they will have to log into their banking app and authenticate the transaction. The latter option tends to be more common nowadays. 

Once the cardholder has gone through the challenge flow, if the transaction is authenticated properly, the transaction will then be processed with the data that is obtained from the bank during the authentication. 

1.3.  What is included in the authentication?

There are three essential values for determining the outcome and liability shift of a 3DS transaction.

• CAVV (Cardholder Authentication Verification Value)

The CAVV is a unique string of alpha numerical values which is used to verify the cardholder’s identity. This value is generated by the card issuer’s ACS and is sent back ti the merchant to confirm that the transaction has been authenticated. 

 NOTE 

The CAVV is different from the CVV (Card Verification Value). The CVV is a physical code on the card itself (3 or 4-digit long depending on the type of card) , while CAVV is a value generated by the 3DS Access Control Server during online authentication. 

• ECI (Electronic Commerce Indicator)

The ECI - also called Universal Cardholder Authentication Field (UCAF) by Mastercard - is used across all schemes. It is a numeric value that is used to provide information on the authentication status of a cardholder and the outcome of the 3D Secure process. Some schemes’ ECI values may vary but the same categorisation applies throughout (see below). 

What is the liability shift?

In some cases there may be a liability shift - meaning that in the event of a fraudulent transaction giving way to a chargeback, the results of the ECI will indicate whether the liability remains with the merchant or will shift onto the issuer. Whoever bears the liability in the transaction will be responsible for the fees and fines in case of a chargeback. 

Fully authenticated (2 or 5) 

• The cardholder’s identity has been confirmed by the card issuer, the transaction can proceed.

• There is a full liability shift from the merchant to the issuer in the case of fraud 

Authenticated attempted (1 or 6)

• Authentication is not available through the issuer - this can happen if the card is not enrolled in 3DS for example. In this case the authentication was attempted but not completed.

• The transaction may proceed to the authorisation stage 

• This however shows that the merchant has attempted authentication under the 3DS mandate

• There may be a liability shift to the issuer 

Authentication failed or unavailable (0 or 7)

• The authentication has failed - this can be for a number of reasons such as incorrect data being entered by the cardholder during the challenge flow, or the cardholder has cancelled the authentication attempt.

• The authentication was not attempted -for example if the cardholder is not enrolled into 3DS. 

• It is unlikely that the transaction will progress to the authorisation stage and is likely to be declined due to an SCA required by issuer message, at least in the UK and Europe.

• There is no liability shift 

1.4. What are the exemptions from 3DS?

• TRA exemption

Before the implementation of PSD2 regulations in Europe and the UK, it was not mandatory to conduct 3DS checks, and in fact, merchants were taking the risk not authenticate transactions in favour of an optimised and uninterrupted checkout flow.  With the introduction of PSD2 and the SCA (Strong Customer Authentication) mandate, 3DS became mandatory for all e-commerce transactions in the UK and Europe in a bid to curb fraud. In an effort to reduce friction and decrease basket abandonment, TRA (Transaction Risk Analysis) exemptions were introduced as part of PSD2 to allow certain transactions to avoid SCA but under strict governance. 

With a TRA exemption, the merchant opts not to perform 3DS checks if the transaction meets certain criteria. A TRA exemption can be applied to a low-risk transactions but this has to be agreed by the acquirer in order to be implemented. The TRA exemption takes place before the authentication.

TRA exemptions may apply in certain situations - as agreed with the merchant’s acquirer - to transactions that have been scored by the merchant’s risk and fraud system as low, if the customer is known and trusted (i.e. a regular customer), or if the amount of the transaction is under a certain threshold.

Both the acquirer and the issuer must support and flag the TRA exemption in the authorisation request so that the transaction is recognised as such.

 NOTE 

There is no liability shift with TRA exemptions as the merchant chooses to circumvent SCA, they will be responsible for paying the chargeback fees and fines.

• Other exemptions

Alongside TRA exemptions, there are other types of exemptions such as low-value exemptions, Secure Corporate Payment (SCP) and Delegated Authority. 

The low-value exemption allows transactions below a certain limit to be processed without 3DS (typically around €25-€30). However the number of consecutive low-value exemptions is capped after which the cardholder has to go through authentication. 

Secure Corporate Payments are transactions between businesses using dedicated payment methods (such as a corporate card or business travel system) and can be 3DS-exempt under strict conditions.

Lastly, in the case of Delegated Authority, the merchant is performing their own checks as the amount of data held on the customer can be greater than, or equal to, that of issuing bank. Delegated authority only works for huge merchants like e-commerce giants, that have collected vasts amounts of customer information to be able to do their own authentication checks.

2. How is 3DS implemented at APEXX?

APEXX supports 3DS in all the payment flows (hosted, direct, CSE).

 NOTE 

3DS only applies to card, not to Alternative Payment Methods. In most cases, they rely on other authentication methods, such as via their own app for example, and as such biometrics (e.g. Face ID or fingerprint) can be used instead of 3DS. 

 NOTE 

Considerations about 3DS will be brought-up when you choose your integration methods with APEXX as it will dictate how 3DS is implemented. This will be discussed with your Implementations Manager during your onboarding.

2.1. 3DS in the Hosted Payment Flow

Who is it for?  The HPP suits small to medium merchants as there is no integration work needed, or for merchants who want to maintain a lower-level of PCI compliance.

If the merchant is using a Hosted Payment Page (HPP), APEXX will be capturing the cardholder data and managing the authentication process. 

In the request for hosted transaction, the merchant must send an object called three_ds, with 2 associated fields: three_ds_version =2.0 and three_ds_required = true. 

This ensures that the 3DS version is the correct one (version 2 as the first version has been deprecated) and that 3DS is required for that particular transaction. When the customer enters the card data, APEXX will interact with our 3DS provider. 

• For a frictionless authentication, APEXX will take the data that we were given by our 3DS provider and send it downstream for authorisation and then capture. 

• For a challenge interaction, APEXX will present the challenge over our hosted page. Once the challenge has been completed, we will get the data, verify it, and process the authorisation using that data. 

All the complexities of 3DS is managed by APEXX and other than including the object and 2 fields above-mentioned, there is nothing else to implement on the merchant’s side, turning it into a very straightforward and easy way of implementing 3DS.

 NOTE on PCI scope 

HPP requires the lowest-level of compliance, SAQ-A

2.2. 3DS in Direct integrations and Client-Side Encryption

Who is it for? Either of these methods is more suitable to an enterprise-level merchants as there is SDK set-up required on the merchant’s side, and the PCI level required is higher.

The interaction with our 3DS provider is done via SDK that the merchant has to implement. When the customer is entering their card details on the merchant’s payment page or form, the SDK will be interact with that form. The merchants have to trigger a certain number of steps in order to attempt the authentication, including BIN look-up, device data collection etc. 

Each of the SDK steps collects data about the interaction, about the customer, and about the device to ultimately form a request that is sent to our 3DS provider using the SDK. All of these steps happen behind the scenes, without the customer being aware - from their perspective, the authentication attempt is instantaneous and seamless.

If the authentication comes back in the response as a frictionless flow, the merchant will send this authentication request to APEXX to be verified. If the data comes back as a challenge, then a URL will be returned to the customer for them to complete the challenge. Once the challenge has been completed, the authentication data is sent to APEXX to be verified. 

 NOTE on PCI Scope 

• A CSE integration requires a SAQ A-EP level 

• A direct integration either requires a SAQ-D or PCI Level 1 (the highest level of compliance)

2.3. External 3DS Providers

Merchants can also choose to do the 3DS outside of APEXX - in whjch case they would interact with their own 3DS provide, get the authentication data and send it to APEXX to pass it through. This would only be possible with a direct or CSE integration. 

RELATED ARTICLES