3D-Secure allows the issuing bank to authenticate their cardholders during thetransaction. In this case, liability for fraudulent transactions shifts away from the merchant towards the card issuer, which reduces chargebacks to the merchant.
3D-Secure v1 (3DS1) was a protocol established by Visa and MasterCard that promotes two-way authentication for transactions. It was created primarily as a means to authenticate transactions on desktop browsers.
3D-Secure v2 (3DS2) has expanded to all major card networks and is accessible through more devices and platforms including integration with a mobile number that uses a secure passcode for transaction verification. Many features are consistent for both 3DS1 and 3DS2 authentication, for example, liability for fraudulent transactions shifts to the card issuer in both versions.
3DS1 and 3DS2 have co-existed for several years before a full transition was rolled out to 3DS2; however there are differences, for example:
- 3DS1 is progressively less compatible with many modern technologies. 3DS2 integrates seamlessly with modern technologies and allows for improved authentication methods.
- Designed to enable a better user experience and minimize the impact on conversions, 3DS2 is the primary method to comply with PSD2 SCA requirements.
- Unlike with 3DS1, businesses can use an iframe to implement the request for authentication on the same page without redirection. That means customers are not redirected and enjoy a better checkout experience.
Some enhancements of 3DS2 compared to 3DS1 include:
- An improved user experience with mobile purchases.
- Secure authentication in checkout through browsers and mobile applications.
- Collection of intricate data to identify any risks or fraudulent activity in transactions.
- Reducing unauthenticated payment risks.
3DS2 uses is a risk-based authentication process to determine whether a transaction should be challenged. The risk level is calculated by intelligent use of data collected during the transaction, such as device information, time zone, and various other parameters. “Frictionless” customer authentication is achieved when the authentication can be done only using the data collected in the background, allowing the transaction to be processed without requesting any additional information from the customer.
However, if there are risks associated with the transaction, authentication moves on to the extra steps or the “challenge flow”. Users are able to use advanced authentication methods such as biometric information.
The PSD2 applies to transactions where both the issuer and the acquirer are located within EEA. The location of the cardholder and the merchant is not relevant.
The RTS (Regulatory Technical Standards) define SCA as authentication through at least two out of the following three factors:
- Something only the user knows (e.g. passcode or PIN).
- Something only the user possesses (e.g. mobile phone or token).
- Something the user is (e.g. fingerprint, facial, iris or eye vein).
* The RTS require that the selected factors must be mutually independent in that the breach of one does not compromise the reliability of the other.
* Authentication factors must belong to different categories.
For remote transactions, each SCA must be linked to a specific amount and payee (dynamic linking). This requirement, effectively binding authentication to the merchant and the amount, aims at ensuring that a valid authentication code is only used once and for the specific transaction for which the authentication is requested.
The dynamic linking requirements can be summarized as follows:
- The cardholder must be made aware of the merchant details and amount when asked by the Issuer to authenticate herself / himself.
- The authentication code generated by the Issuer can only be used once and must be linked to the specific merchant and amount displayed to the cardholder.
- The authentication code must successfully authenticate only the transaction linked to those specific merchant and amount.
- The resulting cryptographic token must be passed by the Acquirer in the authorization request and must be unique for that specific transaction (mandatory).
- The Issuer must validate the cryptographic token passed in authorization and ensure that there is a match in merchant and amount between the token and authorization.
- If there is no match, the Issuer should decline the transaction.
- SCA is not required for Mail & Telephone order (MoTo), anonymous prepaid, and direct debit transactions.
- RTS do not clarify whether card transactions initiated by the payee only (Merchant initiated transactions “MIT”) are subject to SCA.
- UB payments
- Pay-Tv and mobile phone subscriptions
- Car/bike sharing transactions
- Digital services subscriptions
- Insurance premium payments
- Hotel charges
- Funding transactions for staged wallets
Nuvei Solutions take the “hard work” out of implementing 3DS2:
- Our streamlined implementations accelerate 3DS2 implementation.
- Helps you comply with PSD2 mandates in EEA countries whilst utilizing maximum exemptions flow and balancing conversion with security.
- Dynamic decision-algorithms optimize real-time transaction processing by:
- Classifying “out of scope” transactions to smoothly route them through a Non-3D-Secure flow and avoid redundant churn.
- Leveraging strong customer authentication exemptions to maximize conversion rates.
- Using authentication challenges, in the face of moderate risk to push for higher conversion rates.
- Allowing automated “Fall back to 3DS1” protocol, where 3DS2 is not supported, or the Issuer has an outage.
- Allowing automated re-submission for Soft declines to 3DS1 / 3DS2 with a challenge request to keep you compliant and save loss.
- Rejecting risky transactions or Challenge them to ensure payment account ownership.
In order to ensure that your processes are fully transparency and that you leverage the SCA as an “opportunity”, choose a “resilient” solution for your business.
Make sure that it contains:
- The Best-of-Breed APIs.
- An entire suite of added value services.