Enhancing Online Transaction Security with 3D Secure: Part 1

In an era where digital transactions are ubiquitous, ensuring their security is paramount. One significant step towards this is the adoption of universal security protocols. Join us as we explore the evolution of protocols like 3DS and tokenization alongside the evolution of emerging payment types like contactless card payments over the next few blogs.

Brief history of 3DS

When cards were first used for e-commerce transactions, fraud was rampant. A study in 1998, found that almost 50% of disputed transactions at Visa Europe came from e-commerce¹. Early fraud prevention methods were also quite rudimentary and often failed to effectively stop fraud.  This was an important problem to solve, as the industry predicted a rise in online shopping in the future.

So, in 2001, Visa launched the 3DS protocol which initially used a password for security. The protocol soon became an industry standard and was adopted by all major card networks. Today, the protocol is managed by EMVCo, a consortium composed of EuroPay, MasterCard, and Visa.

But what is 3DS?

3DS stands for 3 Domains Secure. The three domains here are:

1. Acquirer domain: Merchant, payment gateway, and bank handling their payment
2. Interoperability domain: card network 
3. Issuer domain: financial institution issuing the card 

The protocol mandates roles and responsibilities for each domain, to ensure the security of online transactions.

Typical transaction flow of 3DS 1.0

But how does 3DS work? Let’s understand with the help of an example. Let’s consider our friend Bob who has a Visa card and is looking to buy a pen. 

In the offline world, Bob would go to a store, select a pen, and pay at the checkout counter. To do this, he presents a card to the checkout clerk who dips the card into her card terminal. The terminal reads the information on the chip on the card to “validate” the card.  The terminal prompts Bob to enter his PIN to complete the transaction at the terminal. Since the PIN is only known to Bob, the PIN entry “authenticates” that Bob is indeed the owner of the card.

This works well for a store transaction where the card is physically present. But in an online transaction, the card is not present. So then how will the merchant complete the “validation” and “authentication” of the card? That’s where 3DS comes into the picture.

Image 1 illustrates how 3DS securely handles online transactions.

Image 1

1. Bob visits the merchant’s website, browses the store, chooses a pen, adds it to his cart, and checks out. At the checkout screen, Bob enters his card number, card expiry date, and a three-digit secure code called CVV.
2. The merchant’s payment gateway provides them with software to accept cards for payments. This includes a component called the Merchant Plug-In (MPI). The MPI sends the card details to the Issuer (through the network) to validate them and check if the card is 3DS enabled.
3. If the card is 3DS enabled, the Issuer returns a URL to an Access Control Server (ACS) page. This is like the Issuer telling the merchant – Hey, this card is mine and to authenticate it please ask Bob to visit this page
4. The merchant redirects Bob to the issuer’s ACS page which prompts Bob for a password. The ACS manages card authentication for the issuer. Depending on the configuration, Bob may enter his password or enter an One Time Password (OTP).  The OTP may be sent by SMS or E-mail
5. The Issuer then checks the password or OTP entered by Bob. On successful authentication and authorization, it communicates the success back to the merchant 
6. The merchant displays a payment success message to Bob and prepares to send him the pen that he bought

This entire process is encrypted, adding to the security of the transaction. Without knowing both Bob’s card details and his password, a fraudster cannot use Bob’s card online. Thus 3DS secures online transactions.

Shortcomings of 3DS 1.0 and birth of 3DS 2.0

While 3DS 1.0 was great at reducing fraud, it had some shortcomings: 

1. User Experience: One of the most significant issues with 3DS1 was the user experience. The 3DS process required cardholders to remember passwords or answer security questions. This was inconvenient for cardholders and sometimes led to transaction abandonment. The process was also not well-integrated into the checkout flow, causing confusion and frustration for cardholders.
2. Mobile Optimization: As online shopping shifted to mobile devices, the lack of mobile optimization in 3DS 1.0 became a significant problem. The user interface and experience were not tailored for mobile transactions, leading to cumbersome and often unsuccessful authentication attempts on smartphones and tablets.
3. Lack of Flexibility and Customization: The first version of 3DS was relatively rigid, offering little in terms of customization for different types of merchants or transactions. This one-size-fits-all approach was not efficient for all online retail scenarios.

In response to these challenges, 3DS 2.0, the next version of the protocol, was developed. In our next blog post in this series, we will dive deep into 3DS 2.0 and understand the impact it has on both issuers and merchants.

Connect with us to know how Zeta delivers 3DS 2.0 experiences!

Footnotes

1. CNET, Visa Program will target online fraud |  January 2022