M-commerce and the Single Device Experience

It is now old news that e-commerce spiked in 2020 as a result of lockdowns and forced digitalisation across the world. Yet m-commerce in particular, usually seen as just a part of overall e-commerce numbers, soared. In the United States alone, m-commerce sales grew 41.4% in 2020, and 15.2% in 2021 (emarketer.com). By the end of 2021, m-commerce sales are expected to make up a staggering 72.9% of all e-commerce transactions globally, according to uptech.com. 

The sharp rise of m-commerce can be explained by several factors, beyond the general growth of e-commerce. First, network coverage and the speed of networks made mobile devices more convenient to use rather than cumbersome PCs. Secondly, eWallets contributed to the contactless effort. And lastly, stores began appearing on social media as mobile-first.

Authenticating at checkout to complete a transaction on the very same device that started the transaction does have an impact on both security and the end-user experience. This problem is what issuers need to solve within the PSD2 security framework. But if PSD2 is a constraint, it actually makes authenticating on a mobile device not only trustworthy, but a great experience.  This is because the extensive use of smartphones made it a natural choice for a lot of issuers to use them as the possession factor, which would be the first factor used to authenticate the customer. 

However, the intensive usage of smartphones for online payments also makes them a natural target for fraudsters and hackers. New types of attacks are on the rise, on top of existing scams. This is why issuers must pay special attention to how they handle security on their smartphone while providing the best experience to their users.

With PSD2, issuers are responsible whenever they require SCA to be performed. This is rather tricky, as they have to ensure security on a device on which they have limited control. This is the mobile headache, as devices are not always updated by end-users or even maintained by manufacturers. This is a risk because vulnerabilities (including zero-day vulnerabilities) could be exploited by root-level malware on the device. 

Since the introduction of PSD2 on mainland Europe, we have seen an increasing move towards app-based authentication, and away from OTP by SMS (which is still tolerated under certain conditions). The move represents three things: 

1. A reaction to the inherent weaknesses of SMS - it can be easily intercepted by malware (it is not even encrypted!). 
2. Releasing responsibly from PSPs in the event of a malware attack. 
3. Better end-user experience options becoming available. 

We have all experienced receiving an OTP by SMS, and then having to type it into a web browser. Not great when we have two devices (a mobile and a PC), and even worse when we have to navigate through different windows or apps on a single mobile device. 

After PSD2’s implementation, the end-user is required to perform a stepped-up authentication with a second factor once the possession factor has been verified. Here are some important steps in this process that help create the best and most frictionless experience for authentication:

1. The issuing bank notifies the end-user via push notifications.  
2. A click will prompt the end-user directly to the bank UI, requiring the end-user to authenticate on the same device. This helps clearly separate the environments (e-commerce and the SCA environment for out-of-band verification).
3. Biometry should be used as a first choice. Using the natural biometric capability of the phone with the appropriate security is the best frictionless experience and will maximise acceptability. Users are now used to authenticating this way in many instances.
4. If biometry is not available or has not received consent, a memorable secret PIN (4 or 6 digits)should be used as a fallback. Using an OTP (by app, not by SMS) is still cumbersome. The use of a password is also annoying as users tend to forget them, or need to look them up in yet another app and copy/paste. Worse, they also tend to use the same password everywhere.  

PSD2 has been perceived as a constraint by the payment industry. Unfortunately, as a result, this has led to a lot of implementations being made to simply tick the compliance box. Yet there are two very important security requirements that should not be forgotten: the implementation of a separate Secure Execution Environment (SEE), and the protection of the Dynamic Linking. “Separate” means an environment that is not linked to the app where the transaction is initiated. We have seen quite a few  cases where these requirements were overlooked, as the focus was more on the two factor implementation. 

The implementation of an SEE is actually the right security solution. This secures the out-of-band authentication using the very same phone that initiated the transaction as possession factor. Even if the phone is compromised by, for example, malware at root level, the transaction authentication can still happen in a safe environment. This is exactly what was intended by PSD2. This way, issuers can trust that their end-users will always validate the genuine transaction while enjoying a better user experience. 

———————

This is the essence of Okay: when it comes to single device transactions, we created our SCA solution with security and a great-user experience in mind. Contact us to find out more!