How does browser-based authentication work for 3DS2?

The PSD2 deadline for Strong Customer Authentication (SCA) is fast approaching, and the new protocol addresses a market trend that has needed attention for quite some time now: authentication for mCommerce transactions. This authentication is something that was left out entirely in 3DS version one.

We learned from “What is 3DS2?” that shoppers will now be able to use biometric authentication, such as fingerprint and facial recognition to authenticate themselves from a mobile app. However, non-mobile devices lack the capabilities to take advantage of biometric characteristics for authentication. These functional differences beg the question: where does this leave browser-based authentication in the 3DS2 picture? Let’s dive into the notable improvements on the browser side.

Richer Browser Information

One of the key elements of 3DS2 is the ability to exchange ten times more data than ever before. These 150 new fields capture and exchange data elements such as cardholder account information, purchase information, prior transaction authentication, and device information. The fields captured for device information vary based on the method in which the consumer is performing the transaction: mobile or browser. While there are overlapping fields for the two different methods, there are distinct fields that are captured for browser-based authentication.

3DS2 allows the issuing bank to capture and perform a real-time risk assessment using richer browser information. For example, the 3DS server captures browser-specific fields such as time zone, size of the user’s screen, and the language of the cardholder’s browser.

This data is then passed on to the issuing bank’s access control server (ACS), which uses risk-based authentication to analyze the data and return a risk score for that specific transaction. If the transaction is deemed low risk, the ACS will respond to the authentication request from the 3DS server and approve the transaction as low risk with no further authentication needed.

The value to the customer is an entirely frictionless checkout experience as the authentication process happened behind the scenes of the browser.

Trouble-free Challenge Flow

Approximately 95% of transactions are expected to follow this frictionless process due to the robust data capturing abilities of the 3DS server. Still, there will be a number of transactions deemed high risk due to their size and nature.

For example, some transactions might be deemed high risk merely based on the Merchant Category Code (MCC). Merchants that fall under categories such as cruise lines, limousine services, and furniture dealers are deemed as high risk merchants by credit card associations and might require further authentication.

Other reasons for further authentication might include transactions over a specific transaction amount threshold. The Payment Services Directive version 2 (PSD2) identifies the requirements for a transaction needing Strong Customer Authentication. One of those requirements for SCA includes transactions over 30 euros. In the case of one of these scenarios, the 3DS2 challenge flow includes notable improvements to the customer experience that aims to reduce the high percentage of cart abandonment rates that we saw with 3DS1.

The former 3DS1 challenge flow required customers to authenticate themselves using a protocol that redirected the user away from the merchant’s website to the issuing bank — leaving the checkout screen entirely. At the bank’s website, the only way to authenticate was by logging into his/her account using a static password. In the case of a lost or unknown password, users either needed to go through a full reset or, in the case of about 50% of these users, abandoned their cart.

One of 3DS2’s notable improvements allows the user to authenticate themselves without leaving the merchant’s page. The new and improved 3DS2 challenge flow allows a one-time password (OTP) to be sent to the user’s phone to verify the transaction. This smoother flow requires far less effort on the customer’s side which is expected to significantly decrease cart abandonment rates.

Improved Customer Experience

Merchants have been searching for ways to combat eCommerce fraud for years. Technological innovations have paved the way for the shopping experience to become more convenient as customer’s shift from shopping in physical stores, to online, to their mobile devices. While noble efforts have been made in the payments industry to keep fraud low as more payments shifted from card present (CP) to card not present (CNP) transactions, most efforts have fallen short.

The first version of 3DS was introduced in 1999 and left much to be desired. The intent of the initial protocol was to provide the ability to authenticate transactions. While meeting this need, adoption rates were not positive due to dwindling conversion rates and a lack of a positive customer experience. Luckily, 3DS2 is receiving a much needed face-lift that aims to make up for its short comings.

3DS2 improves the user experience by allowing the customer to complete the checkout flow in a secure and uninterrupted way. For the ~5% of transactions that will require a challenge, the new browser flow will allow the customer to stay on the merchant’s page to authenticate themselves in a quicker and more efficient manner. These new improvements will ideally increase conversion rates and decrease cart abandonment while still keeping security front and center.

‍

Download the Payments Orchestration eBook Below