3-Domain Secure was created in its first iteration (3DS1) over 15 years ago. The goals were relatively simple, as there were few standards to build upon at the time. Even though there was a mounting challenge in credit card fraud, hopes for what would come
to be a vibrant e-commerce industry were already high.
Despite the clear demand for a secure method in eCommerce transactions,
3DS1 didn’t kick off so smoothly. The mistakes made in the first real attempt at online payment security still left many lessons to consider.
Why was 3DS1 adopted so conservatively in the US?
User experience plays a huge role in the success of any technology. People are naturally quite fickle when it comes to new ideas, but even more so when it adds frustration to their already difficult day. This was where 3DS1 lacked.
The technology was not user-friendly, and it required the cardholder, card issuer, and merchant to participate in the payment authentication. This added an extra step which customers saw as unnecessary. Moreover, the security checks also included a pop-up
window which left users confused. Unable to identify the authenticity of the pop-up window, users saw it as a security threat and would often abandon their purchase before completing the payment process.
Furthermore, the authentication required all customers to enroll with static passwords which many later forgot, creating friction during checkouts. Not to mention that static passwords are rather easy for fraudsters to steal, considering 37% of users change
passwords less than once a year.
Naturally, when the protocol was causing issues that left customers to abandon their carts, merchants turned elsewhere for ways to prevent card-not-present fraud. Address Verification Service (AVS) was a more popular system in comparison to 3DS1 in the US,
not because it was more secure but simply because of its better usability. The system works by verifying whether the address entered by the user is associated with the cardholder’s credit card account. However, AVS acts more like a fraud prevention measure
than an authentication tool.
To sum up the experience, merchants needed a secure authentication system that was user-friendly and didn’t cause frustration in customers to the point where they would abandon the transaction, causing retailers to lose sales.
How 3DS2 is going to change that
Fortunately, the technology did not stop developing at that point and EMVCo (initially named EMV) learned from the 3DS1 experience. The next step in tackling the original challenges of 3-Domain Secure was the development of
3D Secure 2.0.
The improved iteration covers all the pain points experienced in 3DS1. Firstly, 3DS2 focuses on the ease of use. Customer experience is enhanced through risk-based authentication, the new process only makes customers go through the extra stage of security
only if the degree of risk identified is higher than a determined standard, facilitating a frictionless user experience.
Not only will transactions now run smoothly, but the employment of Two Factor Authentication also makes it more secure and compliant with the new Payment Service Directives (PSD2) requirement which will be coming into effect on September 14, 2019. For multinational
firms in the US conducting business with European customers, it is expected that 3DS2 adoption will rise as they witness success in Europe.
While its previous counterpart focused on static information, the security checks for 3DS2 utilises what you have rather than what you know. This includes the implementation of biometric identification, such as facial recognition or fingerprint scanning.
These more advanced checks don’t require customers to use their memory at all, while still giving them more security.
All in all, there seems to be a brighter future ahead for both merchants and customers with 3DS2. In this day and age, there should not be any compromises between the ease of use and security. The improved technology aims to tackle the problem of cart abandonment
by bringing customers a seamless shopping experience while offering advanced authentication.
External | what does this mean?