Cardholder Authentication (3D Secure)

3D Secure (Three Domain Structure) is a security protocol that helps to prevent fraud in e-commerce credit and debit card transactions. This security feature is supported by Visa and Mastercard and is branded as ‘Visa Secure’ and ‘Mastercard Identity Check’ respectively. You can use 3D Secure in your payment programmes to protect online credit and debit card transactions, reduce the risk of fraud and give cardholders a more secure buying experience.

Thredd offer a choice of 3D Secure service providers: Apata and Cardinal. Both service providers enable a real-time 3D Secure enrolment and authentication service. You can implement this service through Thredd to ensure that your cardholders are successfully enrolled and authenticated using 3D Secure.

The figure below provides an overview of the cardholder authentication process.

Figure: Three Domain Secure Cardholder Authentication - Parties Involved

Authentication Methods

Thredd supports a number of methods of authentication that can be used to further verify the cardholder during an online transaction made from a merchant’s website:

Authentication Method

Description

Risk based authentication (RBA)

Risk profiles define how a transaction is evaluated once it reaches the Access Control Server (ACS)Closed A system used to manage the 3D Secure authentication service for the issuer. During an authentication session, the ACS communicates with the Card Scheme and Thredd systems, and may also interact with the cardholder, by providing Challenge screens.. These are a combination of rules which determine the processing action (challenge, accept or reject) which should be taken based on the individual characteristics of a transaction.

OTP SMS authentication

The ACS generates a single-use One-Time Passcode (OTP). Thredd sends the OTP in a SMS text message to the cardholder’s mobile phone number and the cardholder enters the OTP in the 3D Secure screen to authenticate the e-commerce transaction.

OTP Email authentication

The ACS generates a single-use One-Time Passcode (OTP). The ACS sends the OTP in an email message to the cardholder’s email address and the cardholder enters the OTP in the 3D Secure screen to authenticate the e-commerce transaction.

OTP Email is only available for the Apata 3DS service.

Biometric authentication

The ACS sends a Biometric authentication request to Thredd and we forward this to your systems. Your cardholders will need to verify themselves with a biometric identifier (e.g., fingerprint, voiceprint, facial scan) within an authenticator app, for example your organisation's mobile banking application. Your application manages the Biometric verification and returns a response to Thredd.

Out of Band (OOB) authentication

The ACS sends an authentication request to Thredd and we forward this to your systems. You need to verify the cardholder using your cardholder In-AppClosed Purchase or activity made or available from within a particular app on a mobile device, without the need to visit a separate online site. smart phone application, for example by asking them to enter a username and password. Your cardholder application manages the verification and returns a response to Thredd.

Knowledge Based Authentication (KBA)

You enrol the cardholder in KBA using the 3D Secure service and provide the security question ID(s) and answer pair(s). Thredd provides the ACS with the security question and answer to use for KBA. During the e-commerce authentication session, the ACS asks the cardholder to answer the security question and validates. KBA is typically combined with OTP to satisfy the two-factor authentication requirement for PSD2 SCA compliance.

Transaction history

Another type of Knowledge based authentication. If the card is configured to use transaction history, the cardholder is asked to identify a recent payment they made with their card. (Transaction history details are taken from previous transactions where 3D Secure authentication was requested.)

The availability of some authentication methods depends on which service provider you are using: Apata or Cardinal. Please check with your account manager for details.

You can add multiple authentication methods to each card that you enrol in the 3D Secure service. For more information on setting up 3D Secure, see the 3D Secure Guide (Apata) or 3D Secure Guide (Cardinal).

For details of how to enrol cards into 3D Secure using the Web Services API, see Web Services Guide > 3D Secure Credentials (Cardinal and Apata).

Strong Customer Authentication (SCA)

If you are supporting 3D Secure on your cards, you must be able to offer Strong Customer Authentication (SCA) to your cardholders. SCA is required to comply with the Second Payment Services Directive (PSD2) on strong customer authentication. These regulations apply to cards issued in the European Economic Area (EEA) and the United Kingdom.

SCA requires a combination of two forms of customer identification at checkout. Examples include:

Knowledge

Possession

Inherence

Something they know (such as a password or PIN).

Something they have (such as a mobile phone, card reader or other device evidenced by a One-Time Password).

Something they are (such as a fingerprint, face recognition or voice recognition).

You can implement SCA on your cards using the Thredd 3D Secure service. For more information, refer to the 3D Secure Guide (Apata)

SCA Exemptions

Exemptions, when specific criteria are met, can reduce the need for SCA, for example:

  • Low value contactless transactions are exempt - below 30 EUR/£25 per transaction, however:

    • If the cumulative total of up to five transactions exceeds 100 EUR, SCA must be applied.

    • After the fifth transaction, or when the cumulative total goes over 100 EUR, SCA must be applied.

  • Trusted beneficiaries can be exempted. When participating, an issuer can offer their cardholders an enrolment process that allows them to add their trusted merchants to the issuer’s approve list to not present SCA when purchasing from that merchant in the future.

    • SCA is required on the initial enrolment and PAN for a merchant to be approved.

    • For subsequent transactions, if the merchant sends the trusted beneficiaries exemption flag, SCA is not required.

  • Other exemptions apply, such as for recurring payments, Mail Order Telephone Order (MOTO) and merchant-initiated payments

SCA Status and Thredd Systems

Where Thredd manages the SCA parameters on your behalf, we will soft decline any contactless transaction which fails our SCA checks; in this case the cardholder would need to enter their PIN.

In the case of an e-commerce transaction, if it fails our SCA checks then Thredd will soft decline (e.g., the merchant flags the transaction as a low-value exemption and therefore hasn't carried out 3D Secure Authentication and SCA, but the transaction-amount is higher than the issuer-configured low-value exemption). In this case, the cardholder would need to go through 3D Secure Authentication.

You can configure SCA parameters, such low value transactions, for e-commerce and contactless, as well as per billing currency.

The External Host Interface (EHI) provides information to indicate whether a transaction was exempt from SCA or the rules for SCA, as well as additional information about the SCA status. For more information see the EHI Guide > GPS_POS_Data.

PSD2 Dynamic SCA Linking

PSD2 Dynamic SCA Linking requires you to verify that the details provided in a 3D Secure authentication session matches the details that were provided during the transaction authorisation. For example, matching of the authorised amount to the authenticated amount, and matching of the merchant name.

You can perform your verification using details provided in transaction messages sent from the Thredd External Host Interface (EHI) to your systems. For more information, see the EHI Guide > Transaction Matching - Authentications and Authorisations.

For more information on how Thredd performs transaction checks to ensure PSD2 SCA compliance, see the PSD2 SCA Guide.