How should merchants prepare for 3DS 2.1?

In an earlier blog post, I explained the history of the 3-D Secure security standard and how it is changing. With 3-D Secure version 2 (3DS v2.1) arriving soon, I thought it was a good time to explain what more merchants can do to prepare for the change.

3-D Secure version 2.1 (3DS v2.1), which launched on 14 April 2019, requires merchants to provide issuing banks with more data around every card transaction. With more context around each payment, issuing banks should be able to make more accurate authorization decisions in a way that provides a frictionless experience for the consumer. Ultimately, 3DS v2 will lead to greater authorization rates and a more streamlined customer experience that prevents drop offs.

The new standard removes some of the more disruptive aspects of version 1, with an authentication flow that will, in most cases, be invisible to the customer. Depending on the amount and quality of the data shared by the merchant and its payment services provider, the issuer responds in one of two ways. Either the data is deemed enough to determine that the real cardholder is making the purchase, the transaction qualifies for a ‘frictionless’ flow, and authentication occurs without interrupting the customer experience. Or the issuer determines that payment deviates from the usual cardholder spending behavior, the transaction follows a ‘challenge’ flow and the customer must provide a ‘one-time password’ for the payment to be authenticated.

What 3DS v2.1 offers over 3DS v1 is that it lets merchants integrate the ‘challenge’ flow straight into the mobile checkout experience without redirects. New mobile SDKs will create native flows within apps that mean customers won’t need to complete transactions in a separate browser-based flow. Generally, 3DS v2 facilitates more mobile integration and anticipates future mobile and IoT use-cases.

This is a huge change for merchants

You’re just not used to sharing qualitative data throughout the payment chain. And that’s not your fault. In the past, all you needed to provide the issuing bank with was the customer’s card number, the expiration date, eventually the CVV, alongside some additional pieces of information, and that was enough for the issuing bank to authorize the transaction.

However, under 3DS v2, the card issuers are responsible for deciding whether to authenticate a transaction. While this shifts the liability away from merchants, it places the responsibility on them to share more high-quality data to issuing banks. The more data the merchant shares, and the higher quality that data is, the more likely it is that transactions will be authorized and the consumer experience (CX) will be without friction.

The data fields merchants should focus on

The information about the data points that need to be provided to issuing banks have been provided by EMVCo, and issuing banks will have locked 3DS v2.1 implementation on their end to these specifications, eventually adding one or two data points which are considered impactful for preventing fraud (e.g. Carte Bancaire asking for the number of items in the shopping cart).

There are around 100 data points in total; 20 are required and the remaining are optional (although some are highly recommended). A number of these are data points that merchants can easily provide and will contribute to a frictionless customer experience, ultimately leading to higher conversion.

For example, customer information like name, email address, billing address, shipping address, and so on, is useful customer information. Furthermore, you can provide data that gives context of the relationship between you and your customer: the age of the customer’s account with you (how long ago the shopper created an account); the last time the account was accessed; the last time a new card was added; whether any account information has changed in the last thirty days or a year; whether the address been changed recently; whether the password has been changed recently.

These data points can give the issuing bank more confidence that the shopper is known to the merchant. A recently created account or a recent password change, for example, are potential warning signs that an account has been compromised (Account TakeOver or ATO) and a following transaction may be fraudulent. Having a guest checkout, as opposed to customer account, can also lead to lower conversion because the issuing bank is more likely to challenge the transaction.

As far as merchants are concerned, these data points represent a win-win because they are passively collected from the customer with minimal interactions. Providing this information to issuing banks adds no friction to the customer experience and increases the security of any transactions.

The data fields merchants will require assistance to collect

Of course, there are other data points specified by EMVCo’s specification that you as a merchant may not be capable of providing. This will be very specific information, like the screen resolution of the consumers’ device or the acquirer BIN used to authorize the transaction. Merchants may find it challenging to collect and share this information.

Luckily for merchants, your payment service provider (PSP) can leverage device fingerprinting technology to help you capture these data points. PSPs can detect the device type, browser type, the language of the browser, screen length and width, the timezone set – the sort of information that is incredibly useful in fraud prevention fields but that merchants aren’t equipped to track. Your PSP can directly populate the relevant information on your behalf and send it through to the issuing bank at the highest standard of quality.

Priorities for merchants ahead of the deadline

This might sound obvious, but the best advice I can give is to focus on the data points that are the easiest for your business to implement. Of course, you have to make sure you can provide the mandatory fields – that’s why they’re mandatory! But there will also be optional fields for which the specifications are clear and the implementation will be straightforward. Focus on the ones that will give you the least trouble.

I think it’s worth mentioning at this point that EMVCo’s specifications are largely based on a theoretical idea of a checkout page. Once the PSD2/ RTS/ SCA regulation comes into effect and merchants open up their data pipeline to issuing banks, I think we’ll see that in practice some of the data points are either not often used or are used in a different way to how EMVCo expects. Furthermore, some other data points may be detrimental to merchants and need to be leveraged carefully.

For example, the 3DS v2.1 specification regarding shipping address splits it into separate ‘house number’ and ‘street name’ fields. In practice, most checkout pages will have just one address field and the customer will know to put both the house number and street name into that field.

Other mandatory fields are just not used. And then there are regional differences in the checkout experience that the specification will not account for. For example, German merchants like to include prefix as a field, whereas in most other European countries it’s not seen as important.

Other fields do not have clear definitions. It’s unclear, for example, whether “Suspicious Activity” refers to the number of chargebacks over a given period of time or behavior during the checkout process. Similarly, the data field “Shipping Address Usage”, which refers to the first time a shipping address is used, is not clear whether this is the first time the merchant is seeing this address for all of their customers or just for the customer in question.

My point is, focus on the data fields that are easy to do or not up for debate. Chances are, the ones that you’re uncertain about or are having trouble providing to the issuer will be causing similar problems for other merchants. I believe that the practical realities of 3DS v2 implementation will differ from the theoretical specification, and there will be inevitable teething issues.

How 3DS v2.1 aligns with PSD2/ RTS/ Strong Customer Authentication (SCA)

The other big deadline looming for merchants this year is the implementation of Strong Customer Authentication (SCA) on 14 September 2019. This regulation requires that any online payment occurring where both the acquiring and issuing bank are within the European Economic Area (EEA) must use two different authentication factors to verify payments. For transactions where either the acquiring bank or issuing bank are outside of the EEA, your PSP will raise an exemption claim for the transaction for you.

For card payments that fall under the remit of SCA, 3DS v2.1 will be the main way that businesses comply with the new regulations. It is the primary method of ensuring transactions are authenticated under SCA in a way that does not impact the user or harm conversion rates. Card networks are currently refining the way the authentication and the authorization flows work together to capture who eventually raised which exemption along the payment chain. Some industries, such as travel, are operating with a special arrangement while these new processes are figured out.

Most nationals banks (NCAs) are considering a transition period where 3DS v1 will be considered as a valid strong customer authentication method to avoid disruption of the payment chain for the next six months or so. This is you currently support 3DS v1, this will be sufficient to comply with PSD2/ SCA during the period. 

Conclusion

The aim of 3DS v2 is to eliminate fraud by providing more context around every card transaction. It will improve authorization rates in a frictionless way for the customer, ultimately leading to greater conversion rates and shifting liability to the issuing bank.

However, 3DS v2 implementation will be an iterative process (v2.1, v2.2, etc.). Such a huge shift in the way merchants collect and share data will not happen overnight. There will be a period of adjustment, and you can take some comfort in the fact that many merchants like you will be going through the same thing. What 3DS v2 asks of merchants will change as the practical realities of the new standard become clearer. I think the specific rules around the format, and quality of data required, will change over time.

But there’s no need to worry. At Ingenico there is a wealth of expertise and support we can offer to help you make the transition to 3DS v2 as smooth as possible. You don’t have to do it alone, so please get in touch if there is anything we can do to help or find out more on our developer portal.