PSD2 and SCA Compliance: Lessons from Payments Specialist Adyen

James: 

Good morning and welcome to the re:platform podcast. This is episode five and I’m joined as always by the masterful Paul Rogers. Good morning Paul.

Paul: 

Good morning.

James: 

How are you today mate?

Paul: 

Yeah, good. How are you?

James: 

Yeah, good. I’m looking forward to this episode actually, because today we’re going to talk about the sexy topic of the EU payment services directive PSD2, which came into effect in September, 2019. We’re going to be looking at what it is, why it is, and what impact it will have on retailers and merchants.

And it’s an incredibly important topic because payment security is essential for anyone trading online. And there’s quite a few myths out there in the marketplace about what it is, what impact it is going to have. There’s a few horror stories about it, such as it’s going to kill people’s revenue and conversion – so we’re going to speak to a specialist today and try and debunk some of those myths and provide you with practical advice.

So delighted to welcome Fred Potter from Adyen as our guest. Adyen is a leading payment technology provider, working across a wide range of clients, including a lot of retail eCommerce companies. So welcome Fred. Thanks for coming on.

Fred: 

Nice to be here.

James: 

Do you want to give a bit of an introduction about yourself, your role and also Adyen? What does Adyen do and how did it get started?

Fred: 

Yeah, sure. So I’ve been working in payments for about five years now, previously on the issuing side, and now I’ve moved over to the acquiring side. I basically sit on the product team at Adyen, looking after various products in the UK. Specifically more relevant to today, our 3D secure 2.0 protocol, which is obviously being rolled out to our merchant base.

Fred: 

Adyen itself were founded in 2006 by a group of entrepreneurs that came from a company called Bibit, that were later sold to RBS. One of the things that they wanted, or I guess got frustrated within the payments world, was the fragmentation of the payments space and the patchwork of different systems. Adyen was founded with the idea to combat that patchwork and combat that fragmentation. We are one platform that merchants integrate to, we connect directly to card schemes, and we are a processor and acquirer for merchants locally and globally, for both cards and local payment methods.

James: 

Thanks for that. It gives a good flavour of Adyen and where it stands in the market. So we’re going to start with a bit of scene-setting.

So I’d first like you to think forward to the impact on retailers. Can you give us an intro to what are the changes that are happening under the new payment services directive? And also just let’s explain the acronyms because there are so many rolling around like SCA, 3DS2, et cetera. What were the key changes and what do these acronyms mean?

Fred: 

Yeah. So the second payment service directive is a very chunky piece of legislation that is being implemented over multiple years. It’s probably important to note that it does touch on various other areas, not just strong customer authentication, which you’re talking about today. It also covers the regulation of marketplaces, and the flow of funds, and how the marketplaces should avoid being in the flow of funds for example – as well as topics such as surcharging, so essentially charging consumers for using credit cards for example.

So it’s a very wide-reaching piece of regulation. The bit I think is more relevant today is the strong customer authentication requirements. In essence, what it is, is regulation to provide strong customer authentication, commonly shortened to SCA – on eCommerce transactions where the issuer, so the shopper’s card issuer, shopper’s bank and the merchant acquirer, are both located in the European economic area.

Strong customer authentication is currently defined as either 3D secure version one (3DS1) or 3D secure version two (3DS2). 3DS1 in layman terms is when you’re completing the merchant checkout, you get redirected to your bank page and either you type in a static password or the page just disappears if your bank trusts it.

James: 

And what’s the difference between 3DS1 and 3DS2? Is it a fundamental process shift?

Fred: 

They are entirely different protocols. So 3DS1 is a redirection from a page, so you’re always redirected to the issuer’s environment. Traditionally that flow has been seen as having a really low conversion on mobile phones for example, because of more timeouts and the screen pages aren’t necessarily adapted for the mobile phone environment. 3DS2 is a much more improved protocol. So it is what we call native authentication. So no redirections. It’s an iframe that gets rendered on the checkout page of the merchant’s website. And the authentication occurs in a two-factor form. So essentially using two different bits of information about yourself, to verify that the transaction is legitimate. The most common form of authentication being one time passwords delivered to your phone for example.

James: 

Oh, okay. So this is happening in real-time?

Fred: 

Exactly yes. Rather than a static password that you have when you sign up with your bank, and forget after a few months, it’s real-time authentication, and the data’s consistently updating – or the forms of authentication are consistently updated.

James: 

Okay. Excellent. And are SCA and 3DS the same? Or is 3DS part of SCA? How can merchants debunk this to understand what the relationships are between all these different acronyms?

Fred: 

Yes, so SCA stands for strong customer authentication, currently defined as 3DS1. We do expect this to eventually be classified as only 3DS2 . But for the time being to allow merchants more room to be ready, currently, both versions of 3D secure one and two are classified as strong customer authentication. But the term is more general to allow for new forms of authentication in the future, rather than just saying it has to be 3D secured.

James: 

I get you. So at the moment, it’s only 3D secured, but that doesn’t mean that it won’t change in the future and therefore merchants need to keep on top of this and keep having those conversations with their payment providers to understand where that’s moving exactly. Okay, that makes sense.

James: 

And how about the impact on retailers? Have they got to do anything fundamentally different? Is there anything that they need to change in how they are managing their websites?

Fred:

I think when we talk about impact, the most common form or definition of impact for a retailer, is conversion loss. So essentially how many customers will I lose because I’m adding an extra step to the checkout?

Fred: 

I think when you look at impact it will really depend on what the merchant set up is today. So merchants currently applying 3D secure on all of their transactions, will see much less of an impact than merchants that are applying no 3D secure for example. We also look at the merchant’s business model. So recurring merchants or subscription merchants, such as Spotify and Netflix, will have different requirements and therefore different impacts under PSD2 than a one-off e-commerce merchant.

Fred: 

And then finally I think elements such as transaction value will also have an impact. So we know that through exemptions, which I’ll talk a little bit about in a minute, lower value transactions will be less affected than higher value transactions for example. So there are lots of different elements including your PSP and acquirer set up that will determine how much impact the regulation has on your day to day business.

James: 

And I think this is a really key point is not to read any articles out there that say your business will be impacted by X without doing the validation piece. A lot of people do turn on and off 3DS1, depending on whether it’s device-specific or whether it’s based on a card or a customer they trust. So, therefore, the level of impact will vary. And linked to that before we talk about the exemptions and out of scope transactions, which is going be I think really interesting, but there’s risk side.

James: 

So when compliance changes come in, often there can be risk associated or punitive problems for people. GDPR for example, people would be fined if they are in breach of it. Is there any liability shifted? Are merchants liable to any fines or punishment if there’s a lack of compliance or a problem with the process around payments?

Fred: 

The regulation is currently issuer facing. So essentially it deals with the bank side of things. There’s a possibility of merchant facing mandates that will come from the schemes, but as we sit here today, there is nothing official from the schemes that’s been announced. The main risk for retailers and other merchants is essentially an increase in declines. If you as a merchant, are not ensuring that you are authenticating transactions that fit the criteria, then you run the real risk of your transactions being declined by the issuing bank. And MasterCard, Visa and other schemes, have implemented specific decline codes for transactions that don’t get authenticated, which essentially goes along the lines of SCA required. So if you then as a merchant receives that decline code and are not able to essentially implement logic to then prompt an authentication, then you’re in real danger of losing that transaction altogether.

James: 

So I guess then from a development point of view, developers need to understand those changes to the authentication codes. And there might be some incremental processes put in place around checkout for some merchants. If there are new status codes, does that mean that developers need to think about something differently based on a new status code or again, would that be handled at the moment with the payment gateways and issuers?

Fred: 

That’s a good question actually. It depends on what your acquirer setup is. If your acquirer doesn’t have logic to apply 3D secure when that bank requires it, then you as a merchant will need to know when to apply 3D secure. You will have to trust that the issuer is sending back the right code. Which we know historically issuers don’t send back the most accurate decline codes, for instance, ‘05: do not honor’ is the most common decline code. It doesn’t tell us a huge amount about why the transaction was declined. So if your gateway doesn’t have any logic, or it doesn’t help you to present 3D secure at the right moments, then yes you as a merchant would have to ingest a decline code, which is SCA required – trusting the bank sent it correctly, and then apply 3D secure on that transaction.

Fred: 

With Adyen it works slightly differently. We have logic that’s platform-wide, which essentially applies 3D secure to payments when we know that that bank mandates it. So what we do is look at platform-wide data. We look at BIN level data, the bank identification number, which is the first six digits of any card. We look at BIN data platform-wide because we know that typically issuers tend to build logic on BIN level, or build BIN level logic. So we look at a specific BIN and we do an analysis in real-time of whether that BIN requires authentication or not. And essentially that is looking at platform-wide data and transactions going through on that BIN. And if we notice that no transactions are approved when there is no 3D secure, then we will automatically apply 3D secure on that BIN for that merchant, if that makes sense.

James: 

Yes, that does. And that’s really nice actually to have that process automation within the platform to decide when you have to apply a protocol. And, I guess it’s a scoring mechanism, to know that the likelihood of this being a failure if we don’t do this.

Fred: 

Essentially, we make sure that we are quite accurate in that prediction so it would have to be a high number of declines, with no 3D secure, to ensure that we push through to secure that transaction. We don’t just look at the decline code because we know that, as I said before, issuers don’t always send back the right decline code. Uh, we look at other blanket declines as well, from the issuer.

James: 

Yes, that makes sense. Slightly tangential, but something’s just popped into my head actually. Some retailers, especially those with large transaction volumes, and those who work in markets where there’s higher incidence of fraud – fast fashion is a classic example – turn to additional fraud management tools like Signifyd on top of their payment stack. Have you seen any evidence, or do you think this might nudge more people to use something like a Signified? Or do you think that what the payment gateways like Adyen are doing gives people enough reassurance to not think so much about going down that additional fraud protection route?

Fred: 

I can’t comment for external fraud providers. I think the main change to the regulation is, when merchants need to push transactions to 3D secure and when they don’t. Whether external fraud providers are providing that data to merchants, I’m not entirely sure. But I think the main goal for the merchant has to be to ensure that they are compliant. And where I’ve seen these fraud providers come in and provide value is essentially on managing transaction-level fraud, rather than the 3D secure mechanism.

James: 

Yes, I get you. So they are related but not the same thing.

Fred: 

Exactly.

Paul: 

Presumably, if someone’s gone through 3D secure 2.0, at that point the bank takes the risk anyway, so they’re less likely to then want to push it through something like Riskified or Signifyd.

Fred: 

Yes – the bank’s liable in that case.

James: 

So for things like chargebacks?

Fred: 

So for chargebacks with a fraudulent reason code. So essentially I don’t recognize this transaction. Anytime a transaction goes through 3D secure and is successfully authenticated, the liability goes to the issuing bank. It transfers from the merchants to the issuing bank.

James: 

Yeah. And that makes sense. Excellent. So one of the other things I want to talk about is what’s the difference between exemptions and abstract transactions? Because again, I’ve read a lot of information about this. There are times when compliant payment gateways can make a decision about when a transaction is out of scope and therefore doesn’t need SCA, et cetera. Could you just talk people through that? What does out of scope mean? What are the exemptions?

Fred: 

So out of scope are essentially transactions that don’t fall within the mandate. So I mentioned earlier the mandate is online transactions where the issuing to the shopper’s bank and the merchant acquirer, are both based or located within the European economic area. So out of scope transactions are things like inter-regional transactions. So that is where you might have a transaction from a card that’s issued in the US for example. So they’re also referred to as one leg out. Another example of out of scope is a mail order telephone order. So MOTO transactions commonly are where the customer is not able to authenticate because they might be on the phone, for example. MIT, merchant initiative transactions. So they are subscription payments. A Spotify subscription for example. Those are out of the scope of the regulation, as long as that first signup is authenticated.

James: 

Okay. That makes sense.

Fred: 

I think the final out of scope category is anonymous cards. Non-reloadable prepaid cards for example, where issuing bank just simply doesn’t bother, there’s no information on the customer. But the values are low and the limits are low on those types of cards.

James: 

Okay. So for MOTO payments, if an eCommerce team has bought a platform which gives a contact center capability for customer service, which sits directly to that eCommerce platform admin, those orders are currently placed by the customers and seen as out of scope versus customer going is the front end and placing an order?

Fred: 

That’s right, yes.

James: 

Okay. Are there any murmurings of whether that will be brought into scope with things like two-factor authentication through mobile devices through one time codes or is that distant thought?

Fred: 

It’s not too distant. So 3D secure versions that we have today, is 3DS 2.0. There is 3D secured version 2.1, these have released their technical documentation only this week. And what I think we’re seeing is a reaction to the regulation that is building a framework to allow 90% plus business models, to be compliant within 3D secure two requirements. And what I think we will see more and more in the future is an enhancement of that framework. So whether it means bringing MOTO transactions in-house or making them more secure – because the essence of the regulation is to make online transactions more secure for customers, and we’ve seen rising fraud levels, consistently. So we know that MOTO tends to be a high-risk area, so therefore it’s feasible that MOTO might be looked at in more detail, as an area moving forward. But as of today, it’s an out of scope transaction, and merchants are able to continue transacting as they do.

James:

Okay. That’s good. I mean it’s nice for people to understand the delineation of what is required now versus what might be in scope later on. How ready do you think retailers are? So I remember working on sites when the original PSD stuff came in when you had loads of problems with, especially on mobile, conversion being absolutely destroyed by clunky processes that didn’t work. And depending on which bank the experience was different. Even on desktop, it was a bit of a minefield to get a page that worked seamlessly. I think a lot of a) retailers weren’t ready for it. b) I don’t think the people providing all the payment services, and the bank, certainly wasn’t. So from a retail point of view, do you think retailers are more ready, given your experience of working across a load of merchants. How clued up do you think people are on this?

Fred: 

Readiness in the industry is a really big topic and it’s obviously really hard to apply a blanket approach. We’re seeing different types of companies, different sizes of companies, being ready. Large technology providers were some of the first on, at least with Adyen, to transact in new 3DS2. I think it’s probably important to say that the PSD2 and the date that the regulation is enforced, was and still remains the 14th of September, 2019. What we’re in now is a managed roll-out phase. So the EBA, which is the European Banking Association, essentially the organization overseeing the implementation of the regulation, back in June, allowed each member state to implement their own kind of timeline as to when they could roll out.

Fred: 

Some states like France and the UK for example, actually already came out with some draft plans. So the UK has an 18-month rollout plan for example. And then we noticed that the EBA, probably about a month ago, essentially released their own timeline as to how each country could achieve the rollout. So we’re kind of in an interesting scenario now, where you’ve got some countries that will likely follow the EBA opinion of, I think it’s 31st of December, 2020. And you’ve got countries like the UK and France that have their own rollout plan that aren’t necessarily in sync with EBA. Also, you’ve always got the possibility of issuers within a certain country, not reacting inline with their own country’s regulation.

Fred: 

So you’ve got a really kind of fragmented market in Europe, and obviously a very sort of difficult environment for retailers to navigate.

James: 

I guess the big challenge is for retailers that are working across different countries, where they might be taking payments from people all around Europe, is understanding, which payment providers they are using and whether across the base they are covered and whether there is local issues that need to be followed up as a priority.

Fred: 

Yeah, exactly. I think for retailers their main focus is obviously their own business. Payments are often a peripheral part of a retailer’s, or any sort of traditional merchant’s, interest. Let alone the regulation behind payments. You know, it really is something that most merchants are really not prepared to face, in terms of the complexity of the rollout at the moment.

James: 

Yes – I guess one of the key takeaways from today is, it’s not just understanding what this is and what the impact is, but also making sure that you’ve done a proper audit of your payment processing across all of your websites; countries; customer bases; to know if there are any gaps where an issuer might not be providing you the coverage, and what their plans are. Because if you’ve already got 80% coverage, you don’t want to be having to have conversations for no reason. You want to focus on where there’s an issue.

Fred: 

Yes, exactly. And I think the advice that we’re giving merchants, is to make sure you can perform at least 3DS1. Because as we know that’s a compliant version. I mentioned earlier about how we’re helping retailers use 3D secure, only in scenarios where the issuer mandates it. So merchants that are transacting with Adyen, can maintain their current logic, as to when they want to use 3D secure. It might be on higher value, higher risk transactions for example. And then Adyen will apply the authentication as and when the issuers start mandating across Europe. So we’re essentially taking away the responsibility of the merchant to manage the roll out across all of the countries that they transact.

Paul: 

Thinking about this from an integration perspective, or from a client development perspective, if I’m a merchant and I’m using Magento or Salesforce Commerce Cloud for example, where I’m using a module, how will this affect me? Do I need to upgrade the module, from an integration perspective? How do I handle the on-site elements? Will it be an iframe? Or do I have to do any additional development work?

Fred: 

Yeah, so I guess it’s probably good to separate out, into what we call redirect authentication flows and native authentication flows. So redirect are what I mentioned before, 3D secure version one. If you’re using 3D secure version one today, Adyen has a version control on that. So if we notice that the issuing bank is enrolled through 3DS2 and has a good conversion rate, we’ll redirect to a 3DS2 page.

Fred: 

Then I guess you move on to merchants that want native authentication flows, so no redirect, iframe rendering on the checkout page.

Fred: 

So for merchants using plugins and modules such as Magento or any of the other platforms that we support as ready-made modules, we simply ask merchants to upgrade to the latest version of that module. Which obviously isn’t a huge amount of technical work. And then for the merchants that aren’t using modules, may be using their own platform that’s integrated separately, we have a set of preset components that manage a lot of the logic behind the authentication flows. So we’ve really tried to make it as easy as possible for merchants transacting with Adyen to achieve those native flows.

Paul: 

Okay. Makes sense. Do you think this will be an industry-wide thing or is Adyen likely to be a bit beyond some of the other providers out there?… Obviously that’s a bit of a tough question.

Fred: 

Yeah, it’s a really tough question. There are a lot of providers in the space and a lot of different technological capabilities. I believe Adyen were if not the first, one of the first, PSPs to certify our 3DS2 SDK on a server. So we know that we are, if not leading, certainly quite far ahead in the race to enable this technology for merchants. But yeah, there really is a lot of variety in the industry, so I couldn’t comment on other providers.

Paul: 

James has already touched on this earlier, but so far with the people that have been early adopters and have introduced 3DS2, have you seen any data that suggests that it’s more performant than 3DS1? Or maybe it’s kind of because it’s a bit of an unknown that it’s maybe had a negative impact on conversion. Have you seen anything so far that indicates any change in performance?

Fred: 

It’s really probably too early to say. So we know that there are very few banks out there that have proper 3DS2 flows. We see a lot of enrolment for 3D secure, but not necessarily banks that are able to manage the entire two-factor authentication flow. I think, when you talk about customer experience and how that will be impacted, I think that will depend a lot on the merchant setup. So are you using a native or a redirect? So are you asking that customer to go off of your page or can they stay on your page or authenticate? And the second thing that we really, really important is which bank are you. Banks have a lot of up-to-date customer information, banks like Monzo, Revolut, you know, all of the more digital banks. They require you to have a phone number to use those banks, so obviously they’ve got much more updated records and will tend to have better authentication flows. A lot of them are using authentication flows anyway. The user experience in that sense is really reliant on your bank, because they are essentially the ones that control how you authenticate, um, and which data points you’re using to authenticate.

Paul: 

Long term, from an authentication perspective, do you think it’ll become a more seamless process for the end-user?

Fred: 

The goal of the regulation and the 3DS2 protocol is actually generally quite a good one. First of all, it opens up an API between the issuing bank, the merchant acquirer. So customer data can be shared, important customer data such as the device fingerprint and lots of other fraud data that are used in, essentially allowing that issue to make a better decision as to the risk factor of that, on a transaction level basis.

Fred: 

And then once they need to, once they can make that analysis and they decide that they maybe do need to step up, the forms of authentication should improve because you’ve got native forms of authentication, you’ve got better data points to use. So the goal in that sense is two-fold. It should not just allow issues to make better decisions as to when to authenticate, but when they do need to authenticate, the flows by which they’re authenticating should also improve. I think that will take a few months, maybe years to fully realize. And I didn’t really speak much about exemptions, but exemptions are criteria that transactions can meet to not go through authentication. I think those will also become really, really important as this rollout gathers pace because it essentially allows issuers with the increased amount of data that they have on customers, to make better decisions as to when do you apply exemptions and when not to.

Fred: 

And just a final piece on that exemption handling will become very important for merchants as well, because we know that issuers will react differently; more favourably or less favorably, to certain exemptions. So having a PSP or acquirer that can apply for, or have logic to apply for exemptions on your behalf as a merchant, is important if you want to ensure the most amount of conversion, or the least amount of conversion loss, by using the best or the most adequate exemptions.

James: 

Excellent. It’s been really useful. One final question from me. Where can people go if they want to read more? I know that Adyens got loads of resources. What are the most popular resources that you guys got that help people who are at the coalface? You know, merchant side to understand a bit more about this?

Fred: 

I think it depends on what level of understanding you want to have. There are lots of merchant facing publications, really useful guides from Visa, MasterCard and other schemes. If you want, perhaps drier, but more factual material, places like the FCA website or the European banking association website are also useful. And then as you mentioned there, PSPS have quite merchant friendly communications. And then some of the best information is always taken from conversations with your PSP partner, speak to your account manager, speak to the product team at your PSP. They should be able to help you or guide you through your specific setup. Because I think as you mentioned before, that the variety of setups within the merchant space is really huge. So it’s really not going to be a one size fits all in terms of integration for merchants.

James: 

Sensible advice. So just a huge thank you for coming on, taking the time to clarify PSD2. I know that I personally gained plenty of practical insights. I’m sure it will have clarified things for listeners as well. So thanks for taking the time to do that. And thanks to our listeners as always for tuning in. Keep your eyes peeled. The next podcast coming up will be on project management, looking at things to do with effectively managing development cycles and releases. So it should be another very useful one. And if you’d like inbox updates to stay ahead of what’s coming up, please go to replatform.fm/subscribe and add yourself to the newsletter. Any other parting comments, gents?

Paul:

I don’t think so. I think that was really useful. Definitely very practical, I particularly enjoyed learning more about the upgrade path for merchants, and what needs to be done from a technical perspective. Thanks for coming on.

James:

Great. Do share the podcast link with anyone else you think might be interested and as ever, if you have any questions let myself or Paul know via LinkedIn, Twitter or by adding a comment to this post on the website.