Arc’teryx and the 2019 PSD2 Mandate

Andy Badke with Arc’teryx, joined the PAYMENTSfn 2020 event providing us with a keynote presentation outlining the impact the 2019 PSD2 mandate had on Arc’teryx, a global outdoor clothing retailer.

Rolling out 3DS to meet the PSD2 mandate

Andy gave us a first-hand account of how Arc’teryx had to learn, adapt, and execute a complex strategy in a short timeframe to meet the mandate requirements. He presents the detail of the story from his team’s perspective including the changes the mandate required, how the team created and executed their payments strategy, the results, and the lessons learned from the initiative.

‍

‍

WANT MORE? Andy is back with us for our new PAYMENTSfn Fireside Chats series. He will be joined by Daniel Pelegero with RPGC. Join us July 15 at 1pm EDT as they discuss and answer your questions about 3DS2. Register here.

‍

‍

‍

Plus! Join us on our payments-focused slack workspace. we post jobs, news, and offer a space for networking. Apply to join us!

‍

Rough Transcript of Arc'teryx and the PSD2 mandate (edited for readability):

Hello everybody. My name's Andy, and welcome to this online presentation on Arc'teryx and the 2019 PSD2 or Payment Services Directive mandate. It's a pleasure to be speaking to you today in this online presentation format, as part of PAYMENTSfn 2020. Today, I'll be discussing with you the epic journey that our team embarked on to ensure that Arc'teryx was ready for this mandate that was set to affect European merchants, banks, and customers in late 2019. So thank you for taking the time to join me today and for taking interest in our story.

So, first, what are we going to be covering today? The aim of this presentation is to share a real world case study on how our team dealt with the mandate. We'll be covering topics such as a background on Arc'teryx, the team and the corporate e-commerce structure that we were operating in. We'll do a brief intro into the PSD2 mandate and the deadline of September 14, 2019, and what that deadline actually affected. We'll go through some of the challenges that our team faced and the outcome and insights that we had from the experience.

So, first a quick intro. My name's Andy Badke, I'm a project manager for Arc'teryx Enterprise Business Systems. This is me enjoying one of my favorite pastimes of mountain biking in Whistler, Canada. I'm originally from the Gold Coast, Australia, and I've been based in Vancouver for the last six years. My background is 15 years in enterprise IT and software development. Half of that time was in design and full stack development. The other half in a variety of roles in people, product and strategy. I started working with Arc'teryx last year in March 2019. And this was my first engagement working with the team.

Speaking of which, meet the team, the heroes of this story. This is a shot of our team in our makeshift war room in our go-live day for this implementation. We had a combination of onsite and remote workers from multiple organizational departments. The overall team involved in this project was around 15 to 20 people in size. So you may wonder in the top corner on the screen, you could see why Jon, our BA, is in medieval garb, and we've got an alien hugging our lead developer, Brian. But we'll get to that a little bit later on.

So, Arc'teryx the brand. Some of you might say, "Oh, Arc'teryx. I've heard of them." Or some might say, "Well, what the hell's Arc'teryx?" So Arc'teryx is a global retailer in outdoor technical clothing. You may have seen Drake recently wearing Arc'teryx at fashion shows, but the brand and clothing is specifically designed for high exposure outdoor scenarios, like our rock climber hanging out here. The name is a shortening of Archaeopteryx, which essentially stands for first bird or first creature to evolve from flight. The logo is taken from the image of the first complete fossil discovered of this bird. So it was founded in North Vancouver in Canada in 1991, and it has global operations in Europe, Asia, and North America. So let's quickly look at the retail model. The Arc'teryx retail network includes ownership of its own brand stores plus a large distribution network, and of course, any commerce stream. It owns 37 brands stores globally, with stores in key cities, such as Toronto, New York, Beijing, and London. There's also unique brand stores in specialized target market areas, such as Sharmini, Whistler and Vail ski resorts. The distribution network covers over 3,000 stores across 40 countries.

So this, this is a small summary of the growth journey of Arc'teryx. From the founding days in 1991, it's been a case of big fish eat little fish in the retail world. Arc'teryx was bought by Salomon in 2002, Amos Sports in 2005 based out of Finland in Europe, and most recently an investment conglomerate. The primary reason why I mentioned this here is the impact that these mergers have had on the organization structure and the payments operations. The IT system structure through this process has some centrally consolidated elements, and then some that Arc'teryx still has full freedom of control over. So for the payment stream, this means there are different corporate legal entities per country. There are different payment processes per region. There's different underwriter insurance and acquiring banks. This introduces some complexity to the overall big picture, makes it not as easy to implement broad changes as one would like in this space.

So, let's zoom in on e-commerce specifically. This is the setup prior to the PSD2 mandate 2019. Globally, e-commerce revenue averages about $100,000 Canadian, eh, per day. The image on the right is a shot of the primary website, arcteryx.com. And the graph on the left shows the geographical divisions and their respective gateways and processes. You can see here there's separate gateways per region. We've got the North America, there's Orbital and Chase. We support two currencies and a base level of payment types. In Europe, it's CyberSource, WorldPay and Streamline, seven currencies, Norwegian Krone, Swedish krona, Danish krone, Swiss francs, Polish Zloty. And there's a base level of payments that are supported as well. For Japan and Australia, these are separate corporate entities. So today we'll be focusing on the top two. They're managed out of the Arc'teryx HQ in North Vancouver and the other two are completely separate. So we wouldn't be worrying about them today.

So enter our challenger, the PSD2 mandate. February 20, 2019 I'd just arrived at Arc'teryx when our program had received the following request from Rob, our global credit manager in finance. [inaudible 00:05:54] "For the PSD2 mandate, we must support 3DS by September 14 or approximately 70% of our EMEA's credit card transactions will be declined." So the first thing that pops out there is 70% declined transactions in Europe. That's a big number. Okay. You have our attention. And it needs to be done by September 14 and this is a date that is written in law. Okay, so this wasn't on our radar until this call. I pulled this infographic on the right from a MasterCard article that came out around about the same time as when we received this request. You can see here the primary question of, "Are you ready?" And the answer is no. No, we weren't.

We were part of the 75% of merchants stated here in the survey who were unaware of the mandate and the regulation and the 86% who weren't currently supporting strong customer authentication in our e-commerce stream. So the challenge had been laid out before us, but what does this actually mean for us? So a primer on the PSD2 mandate. The mandate was to implement strong customer authentication on card, not present payments scenarios specifically in Europe. So you would need two of the three items mentioned here, like a PIN code sent to the phone or requesting biometrics. The most common form of implementation being 3DS or Three-Domain Secure, the three domains being the merchant and their bank, the customer and their bank, and the payment infrastructure that facilitates the transaction. The benefits of implementing these are that the banks assume some of the liability for online fraudulent transactions instead of the merchant.

So it's called a liability shift. There's increased identity security, reduced fraud, and all of this helps increase data security for open banking. Okay, so what does Arc'teryx need to do to meet this mandate? So let's have a look at the scope of this change. There are three primary areas where payment information is taken at Arc'teryx. So this is the first, arcteryx.com, the primary modern customer-facing website. This site is localized by region, which determines which content you see and which payment flow you follow. So you select items, you add it to the cart and you go through the checkout by filling out your card details here. So for this site, we chose to implement the 3DS1 workflow, and we'll get to why in a second. And we were going to use the Spreedly iFrame solution to take credit card information so that our site never sees the credit card PIN. Okay. So that sounds good. What else?

Item two or three is TAS, or the Arc'teryx system. TAS is our current ERP. It's old school. It's a Windows forms-based BB6 monolith application built from the ground up in the Arc'teryx startup days. It's 25 years old. The system harbors a large amount of technical debt, and there's lots of risks around making sweeping changes to this app. You can see the credit card information screen here. So this is used by our customer sales reps when they're processing payments over the phone, doing troubleshooting with customer support, refunding, et cetera. So how do you implement a 3DS workflow in this app? The short answer is you don't. You touch this as little as possible. The roadmap for this of course is to move to another ERP that's more sustainable for future growth, but we can't do that in three months. So our plan was to hook the payments mechanisms up to the Spreedly vault and to use one of the PSD2 exemptions in this case, MOTO, or mail order and telephone order. The customer support reps were authenticating payments with customers so we figured that this would be fitting for this exemption.

Okay. So this is the best that we can do here. What else have we got? The third item, item three of three, is called TAS web. It's a separate web front end of the ERP. And it's sort of like an intranet for authenticated staff. Now this is a legacy system as well. The roadmap would be to move these authenticated users to the public site code base, but we aren't there yet either. So you can see the credit card info collection that's being done on the right hand side here. This side is affected because our parent company, Amos Sports, is based in Europe. So anybody ordering Arc'teryx products, the staff there, would be subject to the mandate. You can see this interface, it's visually a different code base. It's completely different to the customer-facing web front end, so there's additional scope here that we need to address. And the plan for this one was to add the 3DS workflow hooked up to Spreedly here as well.

So three items of scope, let's summarize the plan. So the team had worked through all the variables. We'd come up with our minimum viable product, which was start with implementing 3DS1. Do it for Europe only, as it was the only region that was affected in the mandate. We'll leave North America alone for now. We could do this by splitting the payment flow at the very start of the customer experience by region. So you can see here everything Europe would be going currently through CyberSource, and we would be proceeding to Spreedly first so that we could get the benefit from a clean and speedy 3DS user experience and implementation. Everything North America would continue unaffected and would be processed by Orbital.

We chose 3DS1 first over 3DS2, because it was a known quantity. It was already well-established and 3DS2 still required some additional effort to implement. And it was unsupported by a few integrations that we were looking to use. Most of the gateways that we were talking to had 3DS1 as a fallback. And it wasn't completely specific in the PSD2 mandate at the time of the project to say that it was 3SD2 that was required and that we could upgrade to this later if we needed. So 3DS1 to start, 3DS2 moving forward. Okay. MVP established. Now let's get started. So this is the first draft of the overall timeline for the team. By the time we were set up to begin execution and get all the resources and everybody ready on the ground, we had around three months from start to finish to have this released and operational.

So we had one squad on TAS and TASweb, the enterprise side, and we had a second squad working on arcteryx.com. We needed a fully collaborative and flat working structure as the teams needed to share their 3DS implementation details between each other and any new discoveries as we went. We had a regular review with the entire stakeholder community every two weeks so that we could update on the project landscape as we progressed. There was a lot of uncertainty. We were learning. We had to innovate on the fly. This was the only way that we could really do the project like this. And it turned out to be a good thing because we ran into a few technical challenges. So on the left, you can see here the scribbling of the environment integrations that were required between Spreedly and CyberSource. On the right is a larger payments landscape of the affected partners that we needed to work with.

The biggest two concerns we had during our execution was both related to testing. So we needed to do a 3DS end-to-end integrated scenario testing across Spreedly, CyberSource, all the way. We also had to do testing with multi-currency and multi-region. So we had the seven supported currencies in Europe. We needed to be able to test each of those flows all the way through each of the configurations of the MITs. As we know, 3DS involves a variety of identity challenges, bank redirects, payments states, and events that we had to handle. Our team identified early on that individual black box partner testing, so Spreedly doing it in the sandbox and CyberSource doing it in its sandbox, that wasn't going to be enough for us to be fully confident it was going to work smoothly, end-to-end. And the last thing that we needed was payment issues to appear for our customers in production when we implemented.

So we needed to create a working end-to-end environment. To do that we had to integrate not only the production environments, but the two partner test environments. So Spreedly had to be able to communicate to CyberSource test, and this isn't something that's regularly supported. It required some special development effort from the Spreedly team, thank you very much, to allow us to hook up to the CyberSource test environment. And it was a very good thing that we did because we highlighted additional configuration requirements that we needed to make inside source to our MIDs to support 3DS1 and our currency accounts. So this was a lifesaver. Without having it, we would have discovered production configuration issues. So that was a big win and it highlighted the need for our end-to-end testing. The other one was multicurrency that I'd mentioned. We had difficulty finding ways to test all of the scenarios for our currencies.

So we had some test accounts for the test environment, CyberSource had test accounts in its test environment, but we had some multicurrency gaps. And we had to do authorizations with our own cards and cancellations to try and find methods through this gap. We would be trying to set up different currencies to those ones that we had to make sure that we could get through all of those scenarios. And it was difficult to do. Other things that we needed to consider was ensuring the count, which is our fraud prevention tool, continue to operate without major rework or major scope required, given the timeframes that we had. So that was an essential requirement, to say, count needs to work as it currently is now at a bare minimum. For the MOTO exemption that we'd mentioned, this also required custom development so that we could pass the correct parameter between all partners to say, "This payment transaction that's coming through is specifically not a 3DS workflow because it is a MOTO exemption.

And then there was the payment landscape itself. So while we were solving these technical challenges amongst the team, we were seeing mixed messaging in the community on the banking state of readiness for the mandate as the date approached. So I pulled this infographic here on the state of open banking APIs in August 2019. We were seeing those messaging such as the EBA can't legally postpone a date that was set out in law. And the messaging was fractured. It started to fracture as we moved close to the deadline. There were two stories that we were hearing. The first was the official line from all of our payments partners saying, "Please continue with your implementation, be ready for the date." And then the unofficial line after you'd hear all this underneath was, "Everybody is expecting this to delay because nobody's ready." So questions that we were asking ourselves are, "Okay, which banks and/or countries are ready for the deadline? Which ones aren't? And if they're not, what are they going to do if they're not?"

So the reality of this situation for us was that any bank that was prepared and was adhering to the mandate could mean declined payments for our customers. So we'd even subscribed. If you see the picture on the right here, we even subscribed to PSD2 magazine and added it to our reviews so that we could keep on top of changes in the industry as we progressed through this. Another note to mention here was that Brexit was going on and we had no idea how that was going to be impacting the payment landscape either. So because of the shifting landscape, our team motto was prepare for anything. So what if we aren't ready for launch what's the contingency plan? How do we enable and if needed, disable this functionality quickly and easily? How do we enable three different payment flows across all those applications at the same time?

What's the status of our operational PayPal account in Poland? Our team chewed on these issues and proposed these elegant solutions for all three scenarios, even for our VB6 TAS monolith application. So our release approach was going to be that we would dark launch. The new 3DS payment flows turned off prior to the mandate. So get all the hard implementation stuff out of the way, just leave it disabled in the environment so you can enable it. We'd be able to enable the 3DS payment workflows via feature flags for the online website and for the ERP, we'd be able to online it from a date-driven database field. In this way, we could quickly switch on all three payment flow areas from their existing flows to the 3DS enabled flows and disable as well, if necessary. So leave the current infrastructure in place.

And if all else failed, our plan C was going to be to create emergency overrides and redirect all online payments into PayPal and disable the ability to take credit card information. All right, so solution is in development, the release plan is ready, and this brings us to mandate day. We gathered everybody for our regular review and we were almost ready, but not quite. We hadn't covered all of our testing scenarios. And you can see in this picture from the previous one, the addition of a few extra streams of work that we had to track, including our PayPal backstop or emergency plan. And this presented the group with a dilemma to discuss. So, that Friday night Europe would be waking up to the mandate in legal effect, which was a Saturday. So we're sitting in the review meeting to say, "All right, what do we do?"

Scenario one, the mandate's in effect, the banks aren't ready, nothing happens. Payments continue as per normal. Cool. Scenario two, banks that are ready will mass enroll their customer cards for three years and all e-commerce orders could be declined. But which banks in which countries, as we've mentioned before, how do we find out who they are? We would have to check with each individual bank in Europe to determine their readiness and to try and separate by currency or by country. And that wasn't viable in the timeframe that we had. We had a day or two before we were going live for this. We did however, have a contingency plan set up so that if we started seeing declines and we weren't ready to release, then yes, we would redirect all of our orders through PayPal. So, okay, the group sat there and chewed on this and the agreed direction, to quote Benji, our director of finance, was, "Let's see what happens. Let's see what happens."

A global retailer, global retailer, huge dollars of revenue at stake, an entire continent potentially affected. And on the day of implementation, we didn't know which way this was going to go. It was a total cliff edge scenario, but we had to play the game. So we had monitoring in place to look for evidence of declines that would start appearing. We had a stakeholder chat channel set up so that we could do live updates, if we started identifying these declines. We had on-call staff in the instance the declines that would be happening we would divert the e-commerce channel through to PayPal and disable the credit card transactions. So we mentioned this to the team to say, "Okay, how does this sound? We're not going to release for the day. We've got our contingency plan in place. Sound good?"

Yeah, sweet. No dramas. The plan's in place, we'll be up Saturday morning nice and early to confirm and broadcast any updates. So Saturday morning rolls around, the mandate's in effect, and what did we see? Well, we saw nothing. We see nothing. The payments continue like they always have without a 3DS flow and any 3DS challenges taking place at all. So we had mixed feelings about this. I mean, for one, because we weren't ready, we're glad that it didn't happen and we started seeing declines. Probably agitated as well to imagine how many other merchants were in a similar situation to us. And potentially disappointed as well that we collectively hadn't implemented our best practice security solution for our European customers, by the time that was allotted. But overall, the best thing about it was the customers weren't negatively affected. So, okay, well, this bought us the time that we needed so that we could finish our 3DS implementation and go live.

We knew that for each passing day, we increased the risk of starting to see declines from any of those seven supported currencies, as banks could potentially switch these on for their customers. So we continued with our development, and once development complete, we were ready for release. And that brings us to our own personal team go-live day. And it turned out to be Halloween, October 31st. So of course the team dressed up for the event. So Brian, our lead developer had a alien outfit and that was a hit. And we had Jon who was our medieval Knight on webcam. And we'd commandeered this event space that you could see here to create a makeshift war room, assembled the whole team there so we could go through the deployment. This photo essentially captures the poetry in motion where we'd simultaneously switched on all three payment flows, so websites and TAS, to process and vault payments via Spreedly and go through a 3DS challenge flow.

We enabled the 3DS1 workflows for all customers in all regions in Europe in what for them was the middle of the night. And the instant we switched this on, we started monitoring via Spreedly's dashboard and our logs for evidence of successful transactions that were occurring across each of the seven currencies, so we could confirm that the setup was correct. And the good news in this case was that everything worked as expected and to the team's credit, it was an extremely smooth deployment. Now, the timing of this release specifically was just as important as the mandate date itself on September 14, because we were about to enter our busiest shopping period as a company. So this was right before Black Friday sales started and it was right before Christmas and our winter season kicks off. Now Arc'teryx generally enters a code freeze of sorts for this period to avoid disrupting the sales pipeline.

And you can see here on the left, the spike that we had in sales, as we turned it on, which were as high as three times what the regular daily average is, which is that Black Friday traffic hit. Some of the numbers that we've had since launch, for Europe 2,000 transactions a week, $18.5 million in revenue total taken over the past five months through the new workflow. So who doesn't love a happy ending to the story? Well, PSD2 the sequel is just around the corner. So the European Banking Authority's published opinion had delayed the implementation to 12 to 18 months, but the approach remains the same. The new requirement is to have full 3DS2 compliance by December 2020. And we're now actively looking at this while we're working on a large-scale ERP transition.

So some personal insights on this to close. The intent and motivation, of course, of the mandate is a good one. We're moving in a positive direction. It's an extremely complex undertaking, though, when something of this magnitude with this many industry players are involved. We're talking government, we've got national banks, we've got all of the merchants, all of the customer banking. And for some merchants like us, the complexity of this implementation is challenging and we need some time to get there. So while sometime pressure does help the industry move towards this goal, it needs to be balanced with each of the merchants' intent and our unique situations.

So in closing, come December this year, let's see what happens. So thank you for your time and attention today. If you would like to connect and discuss any of the items that were discussed and brought up today, please feel free to reach out. Please like, subscribe, leave a comment below. But thank you very much. And from wherever you're watching, have a wonderful day.

‍

Download the PCI Compliance eBook Below