3D Secure
EMV Three Domain Secure (3DS) is a messaging protocol developed by EMVCo to enable customer authentication during card-not-present (CNP) e-commerce purchases .
It is a fraud prevention tool that adds an additional security layer when the customer makes card-not-present (CNP) e-commerce purchases by enabling additional customer authentication via alternate channels and additional information. This information typically includes a one-time password (OTP), a biometric scan, or other authentication methods.
The Payment Service Directive 2 (PSD2) Strong Customer Authentication (SCA) is a regulatory requirement in effect as of 14th September 2019, that impacts many European on-line payments. It requires customers to use two-factor-authentication like 3DS to verify their purchase.
3DS is optional in other regions but can still be used to reduce fraud.
3DS has evolved from the initial version, known as 3DS 1 ( or 3DS version 1, 3DS protocol 1) to the latest 3DS 2 (or 3DS version 2, 3DS protocol 2).
It helps reduce the risk of fraud and provides both merchants and consumers with increased confidence in the validity of online initiated transactions.
It should be noted that in the case of potentially fraudulent transactions resulting in chargebacks, if the cardholder was successfully authenticated using 3DS, the liability for the chargeback shifts from the merchant to the card issuer.
Here's an overview of how it works:
- Initiation: When a cardholder makes a purchase from a participating online merchant, and the card they're using has been enrolled in 3DS, the transaction process automatically triggers the additional authentication process.
- Authentication: After initiating the transaction, the cardholder is redirected to their card issuer's website or app, where they are prompted to provide additional information to confirm their identity. This information typically includes a one-time password (OTP), a biometric scan, or other authentication methods.
- Authorisation: Once the cardholder's identity is successfully verified, the transaction is authorised, and the payment is processed as usual. If authentication fails, the transaction may be declined, or the cardholder may be prompted to try again or use an alternative payment method.
The communication protocol between components is based on requests and responses, i.e Authentication Request (AReq) and Authentication Response (ARes), Result Request (RReq) and Result Response (RRes) and Challenge Request (CReq) and Challenge Response (CRes).
What is important to understand is that the outcome of a 3DS flow is an Authentication Approval Value for Mastercard (AAV) or Cardholder Authentication Verification Value for Visa (CAVV). This AAV or CAVV is used in the authorisation by issuer to prove the transaction has been successfully verified by using 3DS.
Implementation
During the Implementation project, your Progam(s) and Product(s) will be configured in line with your 3D Secure requirements.
CLOWD9 will provide support testing the solution in our Non-Production environment prior to Production testing and launch.
Before a card is used for performing 3DS authentication, the BIN or the sub-BIN needs to be configured at scheme and the ACS provider.
Configuration at the ACS provider involves configuring the work flow of 3DS authentication and the URL that will be published by ACS provider for this sub-BIN. This is the URL that will be rendered by the merchants at the point of 3DS authentication.
Configuration at the scheme involves publishing the above URL from ACS provider in its directory server. Merchant queries this directory server to fetch this URL for cards that fall within the sub-BIN.
Some ACS implementations require each card to be enrolled individually others support BIN or BIN Range level enrolment only.
Cardholder Authentication Methods
CLOWD9, via our integrated Access Control Server (ACS) provider support the following authentication methods:
- Most commonly referred to as an OTP
- A numeric and or alpha code that the Cardholder enters during the Authentication stage
- The OTP can be sent direct to the mobile number held for the Cardholder by SMS or CLOWD9 can transmit this to you via Web hook to communicate to the Cardholder via your choice i.e. SMS, email or in-app
In most regions, where the authentication method used is OTP, a secondary authentication method is required. The Password Authentication is the secondary method.
A static password is set to the card_id and entered by the Cardholder upon request. If the password is entered incorrectly or not provided, the authorization process cannot continue.
With the widespread usage of smart phones, Customers have greater access to your mobile applications to service the day to day needs. The Out of Band (OOB) authentication functionality allows you to provide a more secure authentication method such as biometric or passcode verification which only the Customer should have access to.
CLOWD9 will receive the request for OOB authentication which is sent to you. You will then be required to provide the outcome (succesful / not verified) to CLOWD9 via the OOB Authentication Result API.
Following the final result of a 3D Secure transaction, whether the authentication is frictionless, SMS, SMS & Knowledge Based Authentication (KBA) or Out of Band (OOB), CLOWD9 will communicate the outcome to you.
Updated 1 day ago