Ira Chandler on Providing Secure, Electronic Payment Capabilities Using IBM i
Ira Chandler discusses secure, electronic payment capabilities available using IBM i.
In this sponsored advertising content series, iTalk Business with Tuohy, Paul Tuohy talks with Ira Chandler from Curbstone Corporation about his work with secure, electronic payment processing and creating electronic music.
Paul: Hi everybody and welcome to another iTalk Business with Tuohy. I'm delighted to be joined today by Ira Chandler of Curbstone Incorporated. Hello Ira.
Ira: Hello Paul.
Paul: So Ira, you are working in an area of the industry that I think is becoming more and more relevant everyday, an area that I've had a little bit of dealing with over the last two or three years-oh, I'm sorry, indeed I should say frustration with over the last two or three years. So maybe to start with can you just tell us a little bit about who you are and who Curbstone is please?
Ira: Yes. I appreciate the comment about the frustration. Ira Chandler. I'm with Curbstone Corporation. We are a software and service company specializing in payments exclusively on the Power system running the IBM i operating system. We provide payment capabilities for anybody who is accepting credit cards on this platform. Been doing this for a while. Curbstone was formed in 2002. I got back into the credit card processing software business in '04 so we've been doing this for a while.
Paul: Okay well actually, when you say you've been doing it for a while unless I'm mistaken you have been doing in longer since 2002 though right?
Ira: That's correct. Back in '88, I formed a company to do bar coding and data collection software based primarily on UNIX platform that I was familiar with. We got a contract with the state of Georgia to implement a system based on the new at that time AS/400 which I didn't know much about. I did that, fell in love with it and started doing serial communication, acing serial communication software on the 400, got a call from a company who wanted to talk to a credit card processing network over a modem, asked me if I could do it, and I said yeah, sure. We did that and wound up building ROI corporation around that software selling credit card software to a bunch of companies, acquired some other companies like those software, took it public in 2000 and then sold that company to Verifone. It became their software division.
Paul: Oh, cool. And so then you sort of decided in 2002 that just come to back and start dealing on something that was just basically IBM i specific.
Ira: Yeah. I fell in love with the platform so I certainly couldn't think of doing anything else on anything anywhere else. We anticipated that Verifone was going to eventually not support the IBM i platform vigorously which came to pass as they got out of the market about a year ago completely.
Ira: When my noncompete expired, I wrote Curbstone Card and built Curbstone around that. Now we have hundreds of customers using our software for retail processing card present, for telephone orders, which is card not present or what is called MOTO, mail order telephone order, and for ecommerce.
Paul: Good. Okay I've been putting this off as long as I can but let's talk about compliance. I'm sorry. My twitch has started again as I ask that. So this is something Ira that over-well definitely over the last five years has been getting tougher and tougher, and tougher. You want to talk a little bit about what is going on with all of this compliance stuff.
Ira: Well the security is certainly reaching a much higher awareness lately with the quantity and quality of the hacks and the thefts of data at every level and every type of system. Back-a couple of years back, five years ago, we anticipated that the reporting requirements for merchants were going to intensify which means that the requirements of the banks who give merchant accounts, who allow merchants to accept credit cards and then buy their transactions from them, that those reporting requirements were going to intensify. There is actually some very recent news relevant to the last day of this mon-January 31, 2017 and that is that even the smallest merchant now which is change dictated by Visa and the payment card industry, even the smallest merchant is now going to complete an audit. Now it's a self-audit, self-assessment questionnaire but in a worst-case scenario if you are touching credit card data with your terminals, with your workstations, then you are going to be responsible for a self-assessment questionnaire. They have several flavors. The D or Delta is the most draconian, the most ponderous of them, has over 500 questions and it has taken merchants literally months to complete it. This is now an annual requirement so at least to the credit of the industry which I don't think has been as proactive as I would like to have seen over the years, the payment card industry which was formed in '05 is now dictating that every single merchants, even the smallest mom and pop running IBM i must complete and submit this SAQ to their bank in order to maintain their ability to process credit cards. This is only the latest salvo in imposing work responsibility and regulations on merchants who process credit cards. Luckily PCI provides a very good best practices standard that is pretty easy to follow.
Paul: Uh-huh. Yeah. I haven't been through this or like involved with it. It was most Jon Paris who was having to deal with it on the hands on but the little bit where I got involved and I remember an awful lot the questions that used to be on the questionnaires, you are looking at them going but that doesn't apply to IBM i. That doesn't happen you know.
Ira: Well and you know it's funny you say that because we have been audited. Having done this since obviously in 2005 when PCI was formed, we are audited every year. We are audited to the PADSS standard for distributed software. We are audited to the service provider standard for being a service provider and touching other company's credit cards in our portal that we run which by the way is based on IBM i of course as well as being a QIR which is an installation trained organization to install in a PCI compliant manner. The fact is that we work with the auditors; it was a learning curve for them where Windows or Linux would deploy a separate server to do every single thing, the integration functionality of the 400 blew them away and luckily things like the ability to run different subsystems and run programs in different subsystems that have different purposes has served to satisfy some of the segregation requirements that they otherwise would have had us having multiple Power systems doing what one system does so beautifully with some great inherent segregation and security.
Paul: So true. So then Ira, I mean so how exactly then would-I mean if it’s a thing that I need to do credit card processing on my system, how exactly then does Curbstone in terms of not having to handle all this compliance stuff?
Ira: The big challenge historically-back in the old days when I started this in '93 and through the 90's and the early days of Curbstone, we would put a software component onto a 400 as we called them back then and there is a very simple API that is very RPG friendly. The ERP or order entry app would collect the data, the credit card data in a screen, typically a green screen, sometimes a GUI i screen, pass it through the API, Curbstone software back in the day ROI software would dial out or connect out over the internet to the network, bring back the result. We would store that data securely in an encrypted file and everybody was happy. Now the requirements if you do that, if you touch that credit card data with a workstation, key it into a workstation that is connected to other system in your network, you now qualify under the SAQD, the largest self audit that you can do. It's 85 pages, 19,000 words, 500+ questions so what we have done over the years as we have moved away from the distributed software that has you touching the credit card data in your order entry, the big challenge for us was to ensure that you could have the integration so the unique data that you had for that order, the shipping address, the shipping zip code, the amount, all the key elements that you didn't want to rekey somewhere else, our challenge was how to have people key in the credit card, expiration and security code somewhere other than the workstation but still have the two come together so at the IBM i level, at the application level, you would be requesting the transaction without the card information but giving us all the details that you needed. We developed an isolated payment terminal technology using an alternate device on the order entry person's desk. That would prompt them for the credit card expiration and security code; we would put them together on our portal, get the authorization, and send the result back to both places. The key was keeping the keyboard entry away from the workstation so it wasn't touching credit cards, which puts you entire network in scope, and at the same time maintaining the deep integration into our order entry so you don't have to rekey so with this system, they can now store the credit cards on file for reuse. They can sell something on Monday, flag the transaction on Thursday with a different amount. They have full access to it; they just don't have to touch the actual credit card numbers on the IBM i. It takes them out of scope at that level and that is the approach that we've taken. It took us actually four years to bring the portal to bear. We had to get security certified to the same level for instance PayPal is.
Paul: Right. Right. So I got to tell you Ira, sooner you than me. [Laughter]
Ira: Had I known four years ago what we were going to go through doing this, I would have given a second thought. I'm not saying I wouldn't do it but it has been-it has been a challenge. Everything from deploying the portal at a datacenter, doing the communications, having the uptime, the performance, the integration but knock on wood. It has turned out quite well. We are transitioning our customers from the old model of distributed software to the software as a service. They're pretty much thrilled. Their reporting requirements have changed now from 500+ questions to only 81 and of those 81, only about 40 of them are relevant to the hardware and software they are using so it's a way simpler reporting requirement so with the new mandate of January 31, 2017 for everybody to submit that self audit, we made their life a whole lot easier.
Paul: Sure. Just before we leave this topic though Ira, there is to me always an interesting sideline to this and that is that doing these compliance audits actually-one of the things it highlighted for us when we did our first one is the number of potential security risks that you can inadvertently have on your system.
Ira: Yeah. That's why there is 500 questions. [Laughter]. You know what PCI did and I got to give a lot of credit. PCI was formed by MasterCard, Visa, American Express, JCB in 2005 to carry on Visa's cardholder information security program, security initiative. One of the things that PCI has done which is valuable to any IT professional who might be listening to this is that when you get on the PCI website, they have a library documents. Their data security standard, the DSS which is now version 4.-I'm sorry 3.2. I can't keep up with it. They keep improving it. That data security standard that they publish is a best practices document. It is very, very long. It's got hundreds, literally hundreds of points. It is 12 categories but hundreds of points of inspection that you would do on your infrastructure touching on not only the electronic aspects of it, the equipment aspects, the configuration, the passwords, the firmware, the antivirus and all that but some of the human practices that make up best practices to ensure security so if anybody is looking for a framework whether they do credit cards or not, looking for a framework to improve their security of their system, you would do very well to go to the PCI website, PCIsecuritystandards.org, Google it and download the data security standard and go through it because it is a beautiful roadmap of all the things that over 12 years now PCI has come to refine the standard to include that will help any organization be more secure relative to credit card or to protect you from industrial espionage if you have trade secrets for instance.
Paul: Yup. Yeah, I was surprised when we did it actually the number of places where we have potential SQL injection attacks.
Paul: But okay.
Ira: You know it is funny you mention that. We actually have avoided-in our product we do not use SQL whatsoever in any way, shape, or form specifically for that reason so we tell the auditors there is no chance of SQL injection because we don't use it. Go ahead. [Laughter].
Paul: Okay so-
Ira: Thank God for DB2.
Paul: Indeed. Okay so before we leave Ira, it is interesting. Just when we were chatting before and it turns out that we sort of came from a similar starting point in the IT industry so do you want to share with people who it is that you actually got into IT originally?
Ira: Yeah. It didn't turn out the way I expected. I went to college thinking that I was going to study to maybe be a lawyer. My dad was an attorney and I had some extra time in my pursuit of my BA for that. I said well I'll fill it in. I can get a degree in electronic music. It was 1971, which was obviously early in the scheme of things and our electronic music program at my university, USF, University of South Florida; we had a wonderful program. We studied musique concréte which was defined as music, any sound you can hear that occurs between two points in time and we work on a PDP1110, Digital Equipment Corporation PDP1110 and strangely enough Paul, I know that your background is on a predecessor of the 1110. I'm not saying you're older than I am. [Laughter] I started doing that in college and you know one thing led to the other and I just fell in love with computing at that point. You know the old VD52 terminal on a box. We obvious used Linux-UNIX back then and come '80ish I got an Osborne PC. I did DBASE2, the first database available for microcomputers. I wound up writing their documentation for multiuser DBASE, the first PC based database and certainly the first multiuser database ever released and just been with it ever since. I wound up-I was going to put a UNIX system in the state of Georgia and the IBM rep had convinced them at that time 1991, convinced them to use this new three years old AS/400 of which I'd heard but I knew nothing about it. I wasn't an IBM guy. I'm a UNIX guy. They insisted and I said hey, you know it is just another computer I thought, got into it, fell in love and I've been on the AS/400 and it successors since '91.
Paul: Yeah. Cool, absolutely cool. So listen Ira, thank you for taking the time to talk to me today.
Ira: It's been a pleasure. Thank you.
Paul: Okay everyone, that's it for this iTalk Business with Tuohy. Keep tuned for the next one. Take care now.
About the author
Paul Tuohy has specialized in application development and training on IBM midrange systems for more than 20 years.
See more by Paul Tuohy