 Hi everyone. And we recently had to undergo new payment integration projects and I'm going to talk to you about them today. How many of you in the room are developers and how many managers have servers? So we really have people on both sides of the equation. You might be the ASTOR or you may have been the ASCII, but this narrative goes something like this, your manager calls you and insists, hey Jennifer, can you join my room and I've got something to talk to you about. You know, we really have a problem. The stylist called me up and they said, we can't get signed up on the contracts unless we PCI complains. I know we signed off a couple of years ago that we were PCI compliant, but I'm not sure we still are and we might not get some renewals either. Well, I thought to myself, I don't know much about PCI compliance at this time, but what's it really talking about? What's the real issue here? And the issues that were being discussed were risk and compliance. The risk that... I'm going to start on the back. Well, the first time on stage, it's like that great. So what they said to me was they already reached out to their providers and the provider said, all you have to do is put a little bit of job on the top of your payment page and they'll do the rest. They also said that it should be done in less than a month. And to me I said, well, I've been doing integrations for a pretty long time and I had a pretty good idea that this felt like they wanted to pull a rapid out of the hat. But now let's talk about what was really being discussed and what was being discussed was risk and compliance. You know, the risk that you would have credit card reach and put possibly a card network with full business from you or put you under a microscope. And then there was the risk that sales wouldn't get through business and that renewed contracts wouldn't be signed. So in order to understand the problem as being asked, you have to understand a little bit about compliance and data security standards. And we're all used to standards and they're usually huge documents and this is no exception. There are really 12 basic rules but about 280 sub-rules or requirements and there's about 140 plus documents that help you learn how to implement those requirements and then test against those requirements. You know, most of what's in there from my perspective is common sense. However, it can be daunting for any integrator to think about implementing the full 280 requirements. To make it a little less daunting of a task, we really have to understand how to comply. What are the ways of complying? So one can either file a report of compliance or an SAQ self-assessment questionnaire. And today I'm going to talk about reporting compliance to all because that's really something for larger companies, companies that are doing more than 6 million payments a year and today my conversation will really revolve around SAQs of which smaller companies are more likely to file one. So the year really ate SAQs but today I'm going to let down a little further to free that deal with e-commerce if we're not present payments and those are SAQA, AEP, and SAQD. So from a developer's perspective and from the team's perspective it can be really interesting to think about implementing SAQD. In fact, I think sometimes it can seem like a really cool thing to do when you start digging into a standard but once you and your manager really dig into the requirements there you'll come to realize that it's a big effort and not only that, the time and resources on your company, the ongoing effort will make it unreasonable to even attempt it. So when we get back to conversation SAQA probably, when the manager said we reached out to our partners they probably meant they reached out to one or two of their gateway providers and that SAQA option would be something like an iframe that was delivered from your gateway usually tightly coupled and usually delivered with tightly coupled tokens to either the gateway and or the gateway and the merchant account. This can be a great solution if you're only ever going to have one gateway or if you don't think of future and think of scalability and also being able to switch gateway providers based upon the need or check them. So we're going to eliminate SAQA that type of SAQA and we're going to eliminate SAQD because we don't want to have to deal with the whole 280 requirements. So we're really going to focus on the SAQA solution that is a 3D solution where you've got these flexible universal tokens the service representing the credit card and not the gateway specific one where you've got a flexible UI no dom, you don't have the full dom control but you have flexibility and you're using these, the proxy in order to access all of your gates. I wanted to mention a little piece of trivia the SAQs really have no... the lettering is just... they chose it randomly to use the alphabet however, SAQAEP they really wanted to name SAQAPE because they thought the lettering was more... the Security Council thought it would be better to name it but they were afraid of all the monkey jokes that would instill it but we eliminated the eight from the room so let's move on so we've talked a lot about how it's nice to be here because we all understand each other the terminology we're using but what I found is that payment teams on large legacy projects are really multi-disciplinary and so you might have somebody from accounting you might have somebody from business and you've got to tag people and really the terms that are being used can be really super confusing and I find that it's really the integrator's job to make sure that those terms are being used in context so take gateway for example in the accounting department I might be dealing with three or four or five different gateway providers and they might automatically in their mind go directly to when the gateway is being used to that dashboard they generally ask us to see how they're doing payment life your business team is probably actually going directly to the sales side at which you're still in that gateway and your implementation team might even be going to the concrete implementation inside your code base or the factory that's producing those pathways so during those meetings it's really not necessarily important to say you're using a term wrong or you should be using it this way but to make sure that everyone understands how the words are being used during that time because in fact I think they're all valid to be used so words in context are really important so speaking of context I'm going to give you some technical context for what we're dealing with so our primary application had about 150 end users taking about 2,000 card amount payments card amount present payments per day and doing this on behalf of our customers to multiple gateways and our customers were municipalities not everyone is digging into that diagram but I actually just pulled it from the internet it's meant to just show a typical system a typical legacy system where you've got years and years of code things running against the system usually against one data source so you've got things like batch processes third party monitoring tools already in existence several SOAP services PUAPIs RESTful services, webhooks you've got people FTPing in and out of your system over the years you can see multiple Java script frameworks that might have been implemented at some point your code base may be C sharp it may be Java or it could be anything actually but in general this could be 15 years plus so it poses a big challenge to the integrator so my husband he's in the same area of work he works for TD Ameritrade and runs their trust company and their applications and we really had big argument over whether I should include this slide and the reason I did is what they argued was everybody outsources this in fact we outsourced REST assessment everybody outsources this there are big companies that really are super good at this don't include this slide but my argument was the team is already out they're looking at the PCI standard they're looking at what they would have to do and as I said a lot of times the integrator would be excited about doing it as a Q&A so they probably came across PCI requirement 6 which is to build and maintain secure applications and then they went to the OWAS site and said let me see the 10th top things and they were already doing it and it's a warm up it really provides I think if you have a little bit of time let people get in there because those large systems are going to have holes and when you find one it can be pretty much a thrill it's an excitement so things like letting them look at for cross-site scripting opportunities or injection opportunities or have them go out and dig into creating content security policy if you don't already have one static code analyzers but it really gets the team looking at the code base and when they find things it really helps everybody to understand the magnitude of the problem of these old systems and why it's so important to move your code from the current situation that you're in to something like offloading for a steel company so just a quick review of the architectural changes that you're making in your system you move from these tightly coupled tokens from the gateways to universal tokens you used to have full control of your UI to the DOM now you've got flexible but vendor hosted fields and you're going from multiple individual gateway implementations to using a proxy and most likely you probably have additional business requirements like incremental cut over and minimal downtime I like to think of doing all this in a really old system like teaching an old dog new tricks so some of the things that we found useful here is to an older system you really need to lay out what is existing so creating a heat map for yourself is a great tool for both the integrator and the manager to really understand the application and how to deal with it what we did was we used colors for the magnitude of the problem and so green being the least magnitude of what we've done and red being the most and then letters for whether we knew what we were doing there or whether it was an unknown to us so green is a really good task for like junior developer or somebody that's into the team that you really want to be spreading the code base looking at the code base and all the different repositories and this can be things like seeking out and destroying the card data that you may already have stored things like law.publish.war and law.publish.error you'd be surprised especially if you use tools like Logly, DataDog, and Nurella that you'll find that over 15 years of coding that this stuff actually makes it to those not only your own logs but it can make it to third party services as well and then your red unknowns would be the ones that you basically, if they're unknown you have things worth that you need somebody that knows the system a little bit better probably has a little more experience to dig into and come up with some solutions for. These are not hard and fast rules but these are some of the things that we found really helped us where I like to start are all the parts of the system that are integrations and we basically I guess the word integration of third party integration implies lack of control so you have no control they're basically the youngest in the black box so I like to work quickly there and the heat map helps you identify where those points are so what we found was to immediately implement all the calls that we were going to need to specifically create a test harness and do it relatively quickly and the reason why this is important is not only because it gives you a chance to develop a relationship with your new integrator but it allows you to fail forward fast so inevitably one of your calls isn't going to go through there might be at first a bunch of them don't go through because you're not formatting your call correctly but it might be one that really needs to work on too and allows that to get done really really quickly so you as an integrator can go back to the manager and say the problem calling is going to work we're going to make this happen so let's fail forwarding fast what we found for us was the best way to do this was to put 3D behind our current interfaces as we were using several different gateways and we found that keeping that interface let our consumer applications continue to run during the migration process because we did have that requirement for indifferent inches incrementally cut off so cut over so the other thing we did there to facilitate that was expose metadata so we would allow the concrete implementation of the gateways to tell the consuming applications whether or not they supported universal tokens or not and we all know this but developing tests and you've got a pretty big team make sure you don't push them without ignoring them especially if they're breaking because then you get a lot of people mad at you when they're waiting for their bills to occur and that's the use of ignoring so in a really old application older application the reason why mapping it out is because I found that nobody knows it all I mean there's just too many things going on and even if you knew it all at one point you might have forgotten so what we did is we found that we had an older integration older legacy integration at the UI level and that was I think I mentioned we had 150 users I'm not sure I mentioned that they're on the phone they're in a call center and during the call their calls are being masked but their calls are being recorded for quality assurance and when they start telling the operator their credit card number the call gets masked and so that we don't store that credit card information so the heat map revealed that we had events being triggered on the DOM so when somebody entered their cursor into the credit card field it triggered a jQuery plugin and the jQuery plugin triggered the software and then we masked the call so we mentioned that we went from this really you know complete control of the DOM to the flexible IPhrase fields and that caused a small problem the heat map helped us really reveal it we built a bridge or an advanced corridor I'm using the term bridge in the colloquial term colloquial way right now not in a design pattern way but basically we needed to forward some events that Springy was giving us off the jQuery plugin okay so I know that there's at least one person from Shopify here but when preparing for this presentation I was thinking about the business logic and the older system and how it could be so complicated and how any developer going into it could be intimidated and I found this great hope by Peter McCracken over at Shopify who said wading into legacy code can feel like walking blindly into a minefield and I have to say it's just totally how you feel and if you're just coming on whether you're senior or not anybody that looks at that kind of code and says they just feel too only comfortable it's got to be because it can be extremely intimidating and so what we found here is that oh it can be extremely intimidating but it's also the area of code that's probably making the money for your business it's your special sauce it's the business critical options if something goes wrong here everybody knows it and it's a big problem and you can lose a lot of money so what we found worked really well here was the use of feature toggles and using them so that we could feature toggle new clients on and off the system independent of deploy so like for example we started with like by business demands we started with some of our smallest clients and we were able to feature toggle them off of their current gateway oh look what you didn't feature them off of them feature toggle them off of the current gateway we feature toggled them to the proxy which was going to use their same gateway and then if there were a problem we could easily just give a UI so we could have gone into or you could feature toggle a UI and then flipped it back so they were using their own method of direct gateway access um pair programming I know that um I like to operate a lot alone um but I found that business logic layer was more valuable than having somebody there with you and there are a couple reasons for this one is they said it's very intimidating but two because I think there are different approaches like somebody might come in and say well what the heck is this person thinking this code all stinks they did it all the wrong way I'm going to rewrite everything and then you got the other person that says no no you know the management says we need this in about three weeks we're going to do developers and they usually come up with a nice solution that winds up getting the project done most efficiently um we have somewhere in the order of about 5,000 automated tests and while I find them useful I feel that the business logic layer is some place that really warms a lot of user acceptance testing manual scripted testing where they get it in their hands um and especially you can do this using your feature toggles um because it allows them to see has anything gone wrong for that particular client and um I would not skip the manual scripted test although I think it's sometimes easier not to know well this might seem a little happy but it was the best image I could find and um despite all of where he did try to make things happen not quite so significant but we had exposed additional metadata to the client that indicated whether funds could go to um primary account or fees account and we had other people writing software at the same time and one consuming our API the fly was there it was documented but as things happened that fly went to another and it was kind of scary it was one of those sweating moments where you're like oh my god what am I going to do this is absolutely awful and even though you didn't do it yourself you felt the responsibility more because you're the one that exposed all this data put this video out there but important thing is that you talk about our interdisciplinary team and this whole time you not only force the lines this is Zach this is what happened we've got this problem Zach and accounting and the short period of time he was able to sure be that we're going to able to take the funds and move them where they needed to be and it was a great great so before I finish today then I'd like to talk a little bit about accounting and how important it is to drag them into your project if they don't voluntarily account um our accounting team was able to not only out of that big mess or what we thought was a big mess they were actually a lot like us and they were willing to they fought the same way I think the developers did and they were willing to help us dig into data issues we all know we get so many do not uh rejections from our companies right but during a large migration nobody knows what's really going on we're always willing to blame the technology team so they're constantly paying you uh so we found that feature toggling in the transaction response from uh screen these correspondents with the gateways with great health and we gave access to that just to the accounting department and they did a lot of digging into the data for us and so of all the errors we got because we do not honor or other reasons they were able to identify them to us happily and get us only the issues that were important to us so the things that they did were to facilitate quick responses from gateways so at one point we had a situation where during all this we were one of our primary gateways we were also switching off of their old system to their new gateways so transaction classic to transaction express which is what it's really supports as well but we had a situation where that gateway went down and it was a big deal relationship with the gateway we did actually think somebody mentioned yesterday called Spreedy first and think oh maybe something was wrong with them but you guys were perfect it was the gateway so accounting is super important from that and from our perspective too they managed our compliance documents they actually did all the work for filing the documents which are kind of simple but your company will probably take it very very seriously and I remember it was there and it was kind of intimidating to be part of signing off of that but so in the end it's really important to get a accounting on board and they do more than just get you out of the states they do all this kind of stuff so I think that's pretty much it I know magicians aren't supposed to give them their codes and I don't think I did so today but I hope I gave you a few tips that will help you grab it out of the packs thank you