Checklist for eMerchants: what to do about the changes in customer authentication?
Ramifications of the new PSD2 payment services directive will start to hit European e-commerce in late 2020. If the merchants are not prepared, online commerce could grind to a halt for real this time, since the EU is not likely to grant another extension to the application of PSD2. In the near future, the responsibility […]
Ramifications of the new PSD2 payment services directive will start to hit European e-commerce in late 2020. If the merchants are not prepared, online commerce could grind to a halt for real this time, since the EU is not likely to grant another extension to the application of PSD2.
In the near future, the responsibility for identifying the customer will lie exclusively with the card issuer – in most cases, the bank. Merchants will not be able to skip authentication, even at their own risk. The issuer must be able to identify the customer in connection with every purchase, and there’s nothing the online store or cardholder will be able to do about it any more.
Now, more than ever, it is paramount for merchants to be familiar with online payment solutions. In this post, we will run over the basics of authentication technology and the differences between 3D Secure versions. At the end, we’ve put together a checklist for merchants to prepare for the implementation of the new regulation.
Last time to act, check out Qvik PSD2 audit.
Old tech is still widely used for authentication
Online shoppers paying with their credit cards are identified with a solution called the 3D Secure protocol, standardized and maintained by EMVCo, an association of international credit card organizations.
The first version of the protocol, 3DS1, was published as far back as 2001. Even though it’s no longer fully compliant with today’s requirements and versions with major upgrades have been released at a steady pace, the first version is still used by a significant number of online stores. After the implementation of PSD2 in the fall, this version of the protocol will make payments very awkward for the user.
The early version is extremely inflexible and basically gives the vendor two options: authenticate all customers or none. The merchant bears the responsibility for card misuse if customer authentication is bypassed.
Still, many merchants have been willing to take the risk to make payment as smooth as possible for the customer with a minimum of confirmation steps.
In most cases during the transition period, online merchants have been able to choose whether or not to carry out strong authentication of the customer in connection with card payments. But after the transition, the new authentication methods have to be ready, tested and operational.
3DS2 offers a flexible option for the on-off model
PSD2 gives more flexibility for card issuers in the authentication of customers. This option is supported by version 2 of 3D Secure, itself available in two versions, with a third one in the works.
The new 3DS2 versions feature intelligent logic and rules for performing authentication unobtrusively in the background. The issuer will decide whether to excecute friction free authentication or standard one.
But the benefits of the latest versions are only realized if they are supported by all parties to the transaction, that is, the card issuer, payment service providers, and merchants.
What is the difference between the 3DS2 versions?
The latest versions of authentication technologies seek to provide a better and safer payment experience. Every new version has introduced improvements to flexibility, directly reflected in the customer experience.
Version 3DS2.1 – most common, still serviceable
- Card issuers assess the risks related to transactions in real time. If merchants share data on their customers – such as location and device types – low-risk transactions can be handled frictionless.
- Version 3DS2.1 focuses on purchases made through mobile applications and improves the communication between the e-commerce and authentication applications with a new 3D Secure SDK, or Software Development Kit.
- The authentication application (usually provided by the bank) installed onto the phone communicates and shares data with the shopping app. If apps are compatible, the customer can be directed into the authentication application without passing through the bank’s website.
- This version also supports authentication not connected to payments, such as logging into your mobile wallet or a vendor’s app. Such authentication features are not in widespread use yet, but service providers will probably learn to make more use of it in the near future.
The new 3DS2.2 – only picked up by early adopters
- Customers can whitelist vendors in connection with authentication, after which the vendor will be trusted and authentication will not be required during future purchases from the same store. Card issuers have an obligation to maintain a list of merchants flagged as trustworthy and to offer customers an interface for editing the list. Few such services have been implemented to date, but the support is now there, and we hope to see more of them in the future.
- The version supports MIT transactions (Merchant Initiated Transaction / 3RI) that will be accepted frictionless without visible customer authentication process. This MIT exception lets customers use their cards with apps like Whim and Wolt without strong authentication.
- With Decoupled Authentication, authentication does not have to happen at the same time as the transaction. Rather, merchants can give customers up to a week to authenticate themselves and approve the purchase.
- Depending on the rules applying to the sector and service, merchants can include transactions under the MIT exception.
- The version also supports delegated authentication which means that the customer is authenticated by the merchant, but we shall see whether this option will be permitted in the PSD2 zone.
Version 3DS2.3 – in development, slated for release later this year
- Will enable even smoother interaction between 3D Secure SDK and the authentication app, such as automatic app-switching.
- Features support for purchases made with consoles and voice-controlled smart speakers.
- Improvements to whitelist features.
The merchant’s checklist – how to prepare for the change
There is no quick way to implement this change – at least not well. Your preparations should already be under way. Checking every item off this list will require hard work, but is critical for a smooth purchase experience.
- Check with your payment service provider (PSP) that it has implemented the updates required by 3DS2.2 or will do so in good time in 2020.
- Plan out the payment flow to make it as agile and clear for the customer as possible. Every extra click and input is a potential lost customer.
- Find out whether you can make use of the MIT exception or other back doors in the regulations applying to your sector.
- If you are offering an m-commerce app
- Integrate the latest version of 3DS SDK, for example in cooperation with your PSP.
- Add ApplePay and GooglePay to your payment options – they will take care of authentication in the device’s wallet.
- In addition to card payments, you can integrate invoicing services like Klarna into your store. They are not subject to the authentication obligations applied to card payments.
You don’t have to do it all yourself. If implementing the change feels confusing, Qvik’s payment experts can help you with interpreting the regulation and planning and implementing your changes. Contact us today to schedule a meeting!