Dashboard ↗
Start typing to search…

SCA Explainer

The application of SCA (Stronger Customer Authentication) is mandatory under PSD2 for card-not-present CITs (Customer Initiated Transactions), where both the acquirer and the issuer are located within the regulated jurisdiction (EEA & UK). This requirement came into effect in September 2019.

An intro to 3DS

3DS is the protocol defined by EMVCo for implementing SCA. 3DS allows merchants and payment providers to send over 100 data elements to help the issuer assess the risk level of a transaction and authenticate the cardholder. Merchants can benefit from 3DS by lowering their exposure to fraud and in specific cases, shifting liability for losses to the issuer. However, there may also be drawbacks in the form of increased customer friction which can lead to higher churn rates.

There are multiple components to 3DS which can all have a significant impact on merchants' Conversion Rate. Choosing the correct set-up for your business is critical to achieving the right balance of reduced risk and increased friction. This guide aims to break down the core components of 3DS2, currently the most broadly adopted version of 3DS.

How the 3DS flow works

The 3DS Authentication flow encompasses interactions between 3 core components (3-Domain Secure);

3DS Components

  1. 3DS Requestor Enviroment;
    • 1.1 3DS Client: 3DS component of the merchants checkout interface that integrates to the 3DS SDK/Browser
    • 1.2 3DS SDK/Browser: Functional interface that initiates the 3DS authentication by collecting device data, presenting the challenge (if a challenge flow), and interpreting messages from the 3DS Server
    • 1.3 3DS Server: Server-side software that takes in transaction data and communicates with the Directory Server (DS).
  2. Directory Server (DS): Primary role is to connect acquirers and issuers by routing messages between the 3DS Server and the ACS. Also ensures authenticity of connected servers.
  3. Access Control Server (ACS): Operated by the issuer for the purpose of authenticating the cardholder through the interpretation of the 3DS data.

3DS Core Messages

  1. AReq (Authentication Request): Formed by the 3DS Server to initiate the 3DS flow. Contains cardholder, payment and device information
  2. ARes (Authentication Response): The Issuer’s ACS response to the AReq. Indicates if cardholder is authenticated, or if further interaction is required from the cardholder to complete authentication
  3. CReq (Challenge Request): Formed by the 3DS Client to initiate the cardholder’s interaction in a challenge flow and used to carry authentication data from the cardholder.
  4. CRes (Challenge Response): The Issuer’s ACS response to the CReq. Includes the Authentication result to complete the cardholder challenge. (Two or more CReq messages may be used in an app-based flow, including data necessary to display the 3DS challenge UI).

Where 3DS fits in the payment flow

The 3DS flow (Authentication) is distinct from the transaction Authorization flow. The result of a successful 3DS flow will be an Authentication cryptogram which is submitted within the Authorization flow and used by the Issuer to verify that the transaction has been authenticated.

3DS Versions

3DS 1.0

Support for 3DS 1.0 was discontinued on October 15, 2022.

A very limited number of 3DS 1.0 transactions may still occur, particularly originating from specific markets including India and Bangladesh.

3DS 2.1

The 3DS 2.1 specification was introduced in 2016, this was designed to be compatible across all device options. Additional key enhancements include:

  • 10x more data points collected, leading to more precise decision outcomes
  • Support for biometric authentication, reducing checkout times
  • Does not require redirections, reducing card abandonment
  • More authentication flows supported (Out of Band), such as redirection to banking app
  • More flexible implementation options; allowing for the separation of authentication and authorization. ProcessOut’s Seperated Authentication functionality enables merchants to consolidate their 3DS flows, removing the dependency on each PSP for authentication. This is discussed further in a separate blog.

3DS 2.2

This is currently the most dominant specification of the 3DS protocol at time of writing (2023). From October 2022, the major schemes required issuers and acquirers to support this enhanced standard. ProcessOut observes that around 90% banks within the EEA & UK support 3DS 2.2 as of 2022. Note that 3DS 2.2 is not mandated for 3DS Server operators (often the PSP), so it is important to confirm what version of 3DS your 3DS provider supports.

The 3DS 2.2 specifications include some key enhancements designed to further optimize the customer experience:

  • Enhanced Out of Band (OOB) authentication
  • Delegated Authentication;
  • 3RI (3DS Requestor Initiated)
  • Decoupled Authentication (a type of 3RI)
  • Support for extended Merchant Exemptions

3DS 2.3 was released in September 2021, but has yet to gain broad adoption and so is not covered in detail here.

Enhanced Out of Band (OOB) authentication

OOB authentication describes a flow where a 3DS Challenge (customer input) takes place in another channel, commonly the Issuers banking app. With 3DS 2.2, enhanced OOB authentication was introduced which allows the challenge to present a link for redirecting a customer to the banking app. Best practice guidelines recommend the use of an in-app push notification to prompt the redirection, delivering a more seemless customer experience.

Delegated authentication

Delegated authentication allows authentication to be delegated to the merchant (who are required to provide a FIDO attestation of authentication). This allows merchants to host an authentication process (i.e. biometric fingerprint scan) directly within their own customer journey. Thereby removing the need for customers to be redirected away from merchants checkout page, as well as supporting other use cases.
This flow requires collaboration between the Issuer, Merchant and the 3DS Server provider. It is yet to receive broader adoption. However, this has the potential to further reduce customer friction.

3DS Requestor Initiated (3RI)

This type of 3DS transaction, initiated by a merchant when the Cardholder is not present, is mainly used to maintain (or refresh) authentication data in the absence of a cardholder, for transactions that have been previously authenticated. This allows merchants to manage some complex payment use cases such as delayed split shipping.

Decoupled Authentication (a type of 3RI)

Decoupled Authentication occurs when the 3DS authentication (customer input) takes place in a different channel outside of the merchants checkout flow. The challenge can take place upto 7 days after the request. Once completed, the ACS send the authentication result to the 3DS Server, skipping the Creq/Cres message. This flow may be used as a fallback if the normal challenge flow fails, allowing the customer to still place an order and provide authentication asynchronously before shipping, or in the context of a MOTO transaction.

How to influence the 3DS flow

Merchants are able to influence whether 3DS is performed through a Challenge flow or a Frictionless flow. This is done through the use of a Challenge Indicator flag. Note that merchants may only influence a desired flow, the final decision is always determined by the Issuer. Many factors can contribute to the likelihood of the issuer respecting the merchants 3DS flow preference.

Implications of different 3DS flows

3DS2 supports both a Challenge flow and a Frictionless flow.

  • Challenge Flow: Requires two out of three possible authentication methods, one of which will includes a form of customer input authentication. The three possible authentication methods are often referred to as; something they know, something they have, something they are.
  • Frictionless Flow: Only the customer's device data (device fingerprint) is used to complete authentication. In this case the 3DS flow is still initiated, but a customer input is not required. This provides a more seamless experience.

Challenge indicator and SCA challenge exemption

  • Challenge Indicator: These values are used to indicate a preference for a Challenge or Frictionless 3DS flow. See the below chart to understand the liability shift implication of different Challenge Indicators. (When processing through the co-scheme Carte Bancaire, Liability Shift is only granted on a Challenge flow).
  • SCA Exemption Reason: These values, submitted within the Authorization Request, and are used to indicate a risk-based exemption from the EMVco SCA flow. While this is compliant, it also implies that the merchant (acquirer) accepts liability in the event of a fraud-based chargeback. The benefit of this flow is that it implies no friction in submitting the transaction request. This flow attracts an additional fee from schemes. Issuers may also still soft decline the transactions and request Authentication if it is deemed to high risk.

The below table indicates when Liability Shift will be granted, based on the merchant submitting a Challenge Indicator and this being accepted by the Issuer. The values indicated are those supported by ProcessOut’s API.


Indicator Field and 3DS version Value Description Liability Shift*
challenge_indicator

3DS 2.1 and later		 challenge-requested Indicates a preference for the challenge to be performed ✅
challenge-requested-mandate Indicates that there are mandates which require that a challenge be performed ✅
no-preference Interpreted the same as not providing a value. ✅
no-challenge-requested Indicates a preference for a Frictionless flow ✅
cb-scoring Only support on Carte Bancaire to indicate risk score value between 0-99 ❌
challenge_indicator

3DS 2.2 and later		 no-challenge-requested-tra-performed Allows merchants with their own risk screening to request a Frictionless flow. ❌
no-challenge-requested-data-share-only Ensures a frictionless flow by leveraging additional risk screening from the schemes. ❌
no-challenge-requested-sca-performed Indicates that a challenge has already been performed for this transaction (Liability shift is granted where the associated cryptogram is submitted). ❌
no-challenge-requested-whitelist-exemption Indicates that a customer has opted into a challenge exemption whitelist with the merchant. ✅
challenge-requested-whitelist-prompt Request a whitelist prompt be displayed to the customer during the challenge. N/A
sca_exemption_reason

3DS 2.1 and later		 low-value The value of the transaction must not exceed €30. (Velocity limits are also applied by the Issuer) ❌
sca_exemption_reason

3DS 2.2 and later		 trusted-beneficiary Allows cardholders to add a trusted merchant to a list of trusted beneficiaries held by their Issuer, completing a 3DS Challenge in the process. ✅
transaction-risk-analysis Allows merchants with their own risk screening to submit a transaction request direct to authorization. (Up-to €500, depending on PSP fraud rates). ❌
delegated-authentication Field used to indicate when delegated authentication has been performed. ❌
*Table based on Visa/Mastercard within the EEA&UK. For Carte Bancaire, Liability Shift is only granted on a Challenge flow. Source: Mastercard Authentication Guide for Europe v1.3

3DS cross-compatibility: If the parties support different versions of 3DS, the supported functionality defaults to the lower version.

The outcome obtained through the application of challenge indicators can vary based on multiple factors, including issuer preferences. ProcessOut can help merchants optimize between different values to maximize the probability of achieving the desired flows.

When to request a Challenge flow

The Challenge Flow guarantees that the Merchant will benefit from Liability Shift in the event of a fraud-based chargeback. This can be a strong benefit to merchants, particularly for those that do not perform their own customer risk analysis or that operate in higher risk sectors.

  • To request this preference, ProcessOut recommends passing the Challenge Indicator challenge-requested

If the transaction is intended to be the first transaction in a chain of subsequent MIT transactions (such as a subscription) then it is mandatory under PSD2 that the CIT goes through a Challenge flow.

  • In this case, ProcessOut recommends passing the Challenge Indicator challenge-requested-mandate

When to request a Challenge flow

The Challenge Flow guarantees that the Merchant will benefit from Liability Shift in the event of a fraud-based chargeback. This can be a strong benefit to merchants, particularly for those that do not perform their own customer risk analysis or that operate in higher risk sectors.

  • To request this preference, ProcessOut recommends passing the Challenge Indicator challenge-requested

If the transaction is intended to be the first transaction in a chain of subsequent MIT transactions (such as a subscription) then it is mandatory under PSD2 that the CIT goes through a Challenge flow.

  • In this case, ProcessOut recommends passing the Challenge Indicator challenge-requested-mandate

How to request a Frictionless Flow

As a general rule, if the merchant wants to retain liability shift, it is likely that an issuer will require a challenge flow, particularly for higher value transactions. However, challenge indicators do exist to signal a preference for no challenge, while still retaining liability shift. In practice, these often have a low impact. The challenge indicator in this case would be no-challenge-requested.

For merchants that are happy to assume the liability risk of a transaction in exchange for reduced customer friction, while still retaining some of the security benefits from frictionless 3DS, it is possible to apply an exemption based Challenge Indicator such as no-challenge-requested-tra-performed.

Core indicator and exemption decision flows

An overview of the key considerations and possible exemption / indicators that can be applied on a transaction are indicated below.