The “roaring 20s” of the 21st century has begun. Payment providers around the world have been able to turn lemons into lemonade as consumers are relying on digital commerce transactions more than ever before — especially in a mobile environment. In a previous post, we explored the notable 3-D Secure version 2 (3DS2) improvements on the browser-based side, which included passing richer browser information, an improved customer experience, and a trouble-free challenge flow compared to 3DS version 1.
While 3DS browser-based authentication is expected to increase success rates and create a frictionless experience, 3DS2 is anticipated to have an even larger impact on the mobile payment experience. When 3DS1 came about in 1999, mobile payments had barely just begun. At that time, SMS technology was just becoming available but had little to no traction as very few payment participants were ready for this innovation. As such, 3DS authentication was not included in the protocol on the mobile side.
Trends over the past few years clearly indicate a rapid rise in the mobile payments market and the unexpected global pandemic has only accelerated that growth. Markets that have traditionally been more comfortable with local payment methods and a face-to-face system were forced to lean into eCommerce and mCommerce as quarantine restrictions went into effect. This forced customers into using alternative payment methods they had traditionally been resistant to use.
This shift towards mobile payments created security concerns as merchants worried about fraud vulnerabilities in mCommerce — a fear which threatened the adoption of mobile payments. The long-awaited 3DS2 protocol aims to ease these concerns for merchants by including mobile SDKs and digital wallet compatibilities within the scope of 3DS2 to meet Strong Customer Authentication (SCA).
Mobile SDKs
Since 3DS1 did not account for mobile payments, users had to make purchases via their mobile browser. When the user would be redirected for authentication, a new page would often appear on the customer’s mobile device to verify cardholder identity, or, the authentication page would not appear at all. This led to a clunky and nearly impossible checkout experience that left the consumer feeling concerned about security vulnerabilities. New 3DS2 protocols include mobile SDKs within the scope of SCA. The new standard allows for authentication to be performed during in-app transactions. An in-app purchase improves the customer experience since it allows the merchant to keep consistent styling throughout the entirety of the checkout experience. Mobile authentication might even have a leg up from browser-based authentication, as most applications on mobile devices are able to tap into biometric capabilities such as fingerprint and facial recognition when using 3DS version 2.1.
These added layers of authentication are necessary as mobile commerce has become increasingly more popular. Mobile fraud is nearly the same as browser fraud, with average annual mobile fraud loss coming in at 0.8% and browser fraud at 0.9%. The passing of richer device information to the access control server (ACS) also increases the likelihood for a cardholder to be authenticated without having to be challenged.
It’s important to note that the device information varies based on whether it is iOS or Android. For example, Android passes 136 data elements on top of the initial common device information compared to iOS’s 12 additional elements. These additional elements include fields like default time zone of the device and preferred language.
Mobile SDKs allow for merchants to natively integrate with the 3DS process in order to perform in-app transactions. This integration makes it easier for the merchant to pass vital information regarding the cardholder’s identity to the card issuer’s network under the 3DS2 protocol. A mobile SDK can securely collect payment information, and in order to implement 3DS validation, is only one or two extra calls that can be done by adding very few lines of code.
Compatibility with Digital Wallets
Solutions like Apple Pay and Google Pay have been key factors in the growth of eWallets. Consumers are becoming more comfortable with reaching for their phone to make a payment than a physical wallet. This has allowed for authentication to exist outside of the payment environment and shift to an issuer approved, non-payment environment. Consumers can enter payment details for their credit and/or debit cards when adding the card to their digital wallet. This improves the customer experience so that cardholders will not be asked to enter in their card details each time they make an in-app purchase.
The rise of eWallets is only expected to increase as more players enter into the market. After the initial setup of a user’s card in the digital wallet, it only takes seconds to verify the identity of the cardholder using the 3DS2 protocol at checkout, which would request authentication using iris or fingerprint recognition. We know that SCA requires a cardholder to verify themselves using two out of three metrics: what you know, what you have, or what you are. Browser-based authentication relies on the first two, while mobile 3DS2 is more likely to rely on the latter two.
3DS2 Adapting to Payment Trends
After trailing behind the times for the past 20 years since its inception in 1999, 3DS is finally mobile payment compatible. New standards for 3DS SDKs provide a seamless user experience that creates visual compatibility within the app. Mobile payments, which have a 78% cart abandonment rate, experience a 11% higher cart abandonment rate than desktop purchases.
Up until now, consumers have been thrown off their tracks when a mobile purchase leads to a redirect to a new tab in their mobile browser, resulting in them to give up on the transaction. The new 3DS2 version 2.1 protocol allows for the use of biometric authentication to confirm cardholder identity when making a purchase with a card — all in a more consumer-friendly way.
Download the Payments Orchestration eBook Below
.png)
.svg){kind=icon}
.svg)
