Coalfire recently attended the Treasury Institute for Higher Education PCI Workshop. One hot topic was mobile payments. So, in this series of Compliance Talk, Dirk and Ken are back at their favorite coffee shop, this time joined by Dan Fritsche. Dan is Coalfire’s Director of Solution Validated Services and is considered a thought leader on mobile payments, P2PE and other emerging trends in the payments industry.
Ken: So, mobile payments are quickly becoming yesterday’s news in terms of technology, but the payments industry still seems to be a bit confused on how to handle it as far as compliance goes. Would you agree?
Dan: Well, from my perspective, there’s a lot of confusion out there and we can help clarify some of that. I’ve been working closely with various acquirers, the card brands, the PCI Security Standards Council and developers. And as you know, we have many mobile payment application clients and certainly many merchants that are using mobile payment applications.
Dirk: I think this is something that we see often in the audit world. The technology changes and the audit industry needs to catch up. The issue is that mobile payments proliferated the industry very quickly. I agree with Dan that the PCI Security Standards Council and the card brands have not aligned or set clear direction.
Ken: Coalfire has attended some recent events like the Treasury Institute for Higher Education PCI Workshop in Indianapolis where mobile payment application compliance was a very heated topic. Can you help me and our readers better frame this issue?
Dan: I think the best place to start is to describe the basis of mobile payment solutions. Think of it in terms of mobile payment solutions falling into one of three classifications.
Dirk: Wait…before we explain those, let’s first define the categories of the devices. You can’t really talk about mobile without first defining the hardware, right?
Dan: Right! Over a year ago they (the PCI Council) defined three categories. Category 1 is PTS-approved devices, such as a hardware swipe device. Merchants are going this route because it encrypts data at the swipe, which reduces risk and will eventually reduce compliance requirements. It leads to P2PE. Category-2 devices, there are only a handful of those and PCI is kind of weary of them. The simplest way to put it is that Category-2 devices are single-purpose devices and can only act as a payment app, they can’t play games, can’t surf the Internet, they are not a phone, essentially they're locked down. Category 3 is a multi-use device, so it can do those other things and function as a payment solution. Now, the PCI industry doesn't define Category-3 devices as including anything on iOS, Android or Windows, but any mobile solution with those operating systems will be rejected, even if the developer says the operating system is locked down and there's no way anything else can be done on it.
Dirk: Basically if it is a hardware-dedicated device, it's going to fall under either the 1 or 2 category. Category 3 relates to an application that is running on top of something else.
Dan: If it runs on iOS, Android, or Windows, that’s the simplest definition of a Category-3 device.
Ken: So if category-3 devices can't be validated, how come I go to the farmers market, the Apple store…really anywhere, and have my card taken using an iPhone?
Dirk: That goes back to the classifications of mobile solutions.
Dan: Right. Again, think of the different types of solutions. First, there are the merchant-of-record solutions, like Square. Second, there are the Bespoke-Custom Code solutions. And third, there are the consumer-focused solutions.
Ken: OK then. Let’s talk about Square. I know Coalfire has validated Square…please explain.
Dan: Alright, but let’s first talk about the Bespoke applications. A Bespoke application is a custom-developed application specifically for a merchant. That is, the merchant goes to a developer to create a mobile application just for them, or they develop one on their own. As you know, Bespoke applications fall outside the scope of PA-DSS.
Dirk: That is, any custom payment application falls under the merchant’s ROC or SAQ. That goes for both custom mobile payment applications and custom non-mobile payment applications. When you go to the Apple store, for example, they take your card using an iPhone. The application they use is only used by Apple. It's an Apple-only application, therefore it falls under their ROC.
Dan: A lot of merchants are doing this. In fact, there’s a cottage industry of developers that have foundational code, then they customize it for the merchant and create a Bespoke application.
Ken: That sounds smart! But are they skirting compliance?
Dirk: Absolutely not! The QSA still has to examine and test the application as part of the ROC or it has to be addressed as part of a SAQ. We’ve traditionally seen issues here, but we see even more issues for mobile payment applications.
Ken: So, one way to deploy a mobile payment application is to have one custom developed for my business. There may be some foundational payment code, but if the application is specific to my business, it would be considered custom and Bespoke. So it falls under my merchant ROC or SAQ. I’ve got it.
Dan: Now, back to Square. These are the merchant-of-record solutions. Square is the merchant. The application is validated not by PA-DSS, but under Square’s ROC.
Ken: I get it! It’s like PayPal!
Dirk: Well, this applies to only some of the PayPal services, but you’re on the right track. Essentially, if I buy a cup of coffee somewhere that uses Square, Square processes the credit card under their merchant ID, not the coffee shop’s.
Ken: And the merchant gets paid on the back end?
Dirk: Exactly. The coffee shop doesn't have a merchant ID, they have a Square account. Square takes on all the risk and compliance responsibility. Square has a merchant ROC that covers all their transactions…it’s just for them.
Ken: But Square can’t get listed for PA-DSS, right?
Dan: That’s right.
Ken: Nice. So, that covers the so-called merchant-of-record mobile applications and the Bespoke solutions. What was the third one again?
Dirk: The consumer-focused solutions.
Dan: OK, so let’s make a distinction. The first two classifications are merchant-based mobile solutions. As a consumer, you give the card to the merchant to process. The payment application they use is invisible to you. It's the merchant’s risk. Consumer-based mobile applications are those that you, as a consumer, elect to download from the store and use. You put your card information into the application, then the merchant may or may not allow you to pay with it. It is your credit card, your risk, your decision. This is a newer area, but it could take off. The problem is that the merchant has to accept that unknown form of payment. There isn't’t a whole lot of this going on today, but it could be the next form of payment.
Ken: I used to hear how I could use my smartphone, wave it in front of a vending machine and get a soda. What about that type of thing?
Dirk: Yes, and we don’t see much of this yet, though we're working with some of these exact solution providers. We'll see more of this in the future, no doubt. There are a lot of unanswered questions with that…mostly on the merchant side. For example, how does a merchant know what consumer-based applications to accept? There’s no standard for it right now.
Ken: OK. What other concerns are there?
Dan: Well, that goes back to where we started. The industry is moving fast. Merchants want to make money; they’ve got solutions and they want to use them. Some merchants don’t focus on whether or not the solution is compliant. We see a lot of merchants that simply believe the application developer when it comes to security and compliance.
Dirk: We also see a lot of QSAs that don’t understand the issues, so they skate over mobile application security. The key for the merchant is to understand what they're getting. Some mobile application developers are saying, “We meet all the requirements of PA DSS.” But, they offer no real proof.
Dan: That’s why we're so busy doing technical assessment white papers. Essentially, we validate the mobile solution to the PA-DSS standard as much as it's relevant. Then we provide the developer with our letter or white paper that says Coalfire has found that the solution meets the PA-DSS requirements even though it can’t be listed.
Ken: I need to summarize this again. If you're using a merchant-of-record application like Square, you should ask for their ROC summary. If it’s a Bespoke application, then make sure the developer gets it independently reviewed by a PA-QSA. If it’s a consumer-focused app…same thing, but those solutions are only emerging now. Finally, white papers that are independently written by a PA-QSA give the merchant more confidence. Does that cover it?
Dirk: Yes, but keep in mind that the merchant is responsible for their cardholder environment. We’ve seen some different situations where a non-payment application in the cardholder environment violates PCI. For example, an application may not touch credit card processing, but if that app saves passwords in clear text and the merchant uses it inside their CDE, then the merchant is out of compliance because they're storing passwords that are in the clear. Even though it has nothing to do with payment applications, you still can’t violate PCI within the CDE boundaries. This of course applies to any application in the CDE, but people seem to forget those issues when it’s a mobile app.
Ken: But WE don’t forget.
Dirk: [laughing] No, we don’t.
Dan: It’s all about protecting the client.
Ken: That sounds like the bottom line, so let’s stop with that. Thank you for joining us, Dan. And Dirk, as always…thanks for the insight. Oh, and the coffee, too!