Skip to main content

3DS and Strong Customer Authentication (SCA)

The authorization of a card transaction—if properly configured in the Card Processor module—goes through 3D Secure (3DS) before being approved or denied. 3DS is the de facto standard for handling online debit and credit card payments.

3DS is an additional layer of security—also known as 'Three-Domain Secure'—that acts as a bridge between the merchant, the card network (Visa, Mastercard, etc.), and the Issuer, which is responsible for managing the funds. The main goal of 3DS is to ensure that the actor initiating the transaction is the legitimate cardholder, thereby preventing fraud."

Overview​

To provide an overview of the entire process, let's focus on the key steps:

  • The process begins when a cardholder makes an online purchase.
  • First, the cardholder enters their card number (PAN), CVV, and expiration date.
  • Based on the transaction data, a Risk Level evaluation is requested from the Issuer.
  • When 'Challenge Mode' is triggered (typically for medium or high-risk levels), the Issuer initiates a workflow to engage the cardholder via Strong Customer Authentication (SCA), such as an SMS code or, more commonly, a push notification on their device.
  • The customer approves or rejects the authorization, which is then sent back to the Issuer.
  • The confirmation or denial is provided to the ACS (Access Control Server) and finally reaches the merchant store to finalize or decline the original payment transaction.

Evaluation of Risk Level​

During the 3DS process, the most important step is the Evaluation of the Risk Level related with the transaction. The most part of transaction data is provided to the Issuer (and forwarded to the Affiliate) as detailed here.

When the Issuer and the Affiliate are involved in this process the output response should be one of the following:

  • Level low: the transaction will be automatically authorized in "frictionless" mode.
  • Level high: the transaction will be automatically denied and rejected.
  • Level medium: the 3DS process continues with "challenge" mode.
  • Level undecided: the decision of authorization/denial of transaction is up to the ACS.

It is up to the Issuer - or the Affiliate - to use transaction data to calculate the risk level, using a methodology that can be simple or complex, depending on the use cases. For example the following information can be used:

  • Transaction amount: if the amount is low, the calculated risk level can be considered as "low risk"; if the amount is high, so the transaction can be set as risky
  • Merchant fraud rate: using the rate provided by the circuit (1 = low fraud rate => 26 = high fraud rate) the calculated risk level can be defined according this rate

Engagement of final customer​

The 3DS process requires the user's authenticity to be verified using SCA (Strong Customer Authentication). This system decouples the customer's communication channels by employing an 'out-of-band' (OOB) methodology. For example, the user may be required to complete the authorization using a code sent via SMS or, more commonly, by approving a push notification on a physical device in their possession.

The responsibility for maintaining the registry of the end customer's physical devices always rests with the Issuer (or the Affiliate). They must provide this list whenever the ACS flow requires it specifically, when the designated endpoint is invoked.

Following this request, the ACS (Access Control Server) selects one or more devices—using their unique identifier and triggers a push notification. The purpose is to prompt the user to either authorize or decline the transaction directly from their device.

The user experience, on final customer device, should be something like this: