Where to start with PCI-DSS in a mobile app?

We’re developing a mobile app (iOS and Android) for a client which has its own payment processing solution. The app is public-facing, and will be used by individual consumers on their own phones.

The app has to interface with the payment processing solution over a SOAP API. We need to accept the input of the user’s payment card details, and pass them across that API. We don’t have the option of embedding their website within an iframe, or anything like that; we have to use this specific API, which means that our app will unavoidably have to (briefly) possess and process the user’s payment card details.

All the app needs to do is to collect the details (by having the user tap them in on the phone’s keyboard), send them across the API, and then discard them as quickly as it possibly can. It won’t store the data beyond the time taken to complete the transaction, and it won’t send the data anywhere except across the API to the client’s server. We will never have the data on our own servers, we will be careful never to write it into logs, and generally we will be treating it like radioactive waste for the brief period it’s in the app’s possession.

We can safely assume (at least for now) that the client’s systems already do whatever they need to do with regard to PCI DSS. And of course the traffic between the app and the payment server is encrypted.

We’re struggling to get to grips with what we need to do regarding PCI DSS, and we’d appreciate any pointers to help us get started. We’re perfectly happy to (indeed want to) use a consultant to help us achieve compliance – but we don’t really even know who we’d talk to. Everything we can easily find online (including material from the PCI itself) seems to relate to subtly different scenarios, or advises us to sidestep the problem by using something like an iframe, which isn’t an option for us.

To be honest, we’re surprised by how hard it’s proving to find some clear pointers. Lots of apps do process card details! This surely must be a common problem.

So, our questions:

1. Where should we go to get expert advice relevant to our particular scenario?
2. Completely informally, and on the understanding that we are going to get properly qualified advice later… how much of a nightmare should we expect this to be? We’ve got to the point of wondering whether we need to worry about key loggers installed on the phone. Is that really the case, or are we going too far?
3. Is there a magic bullet we’re missing – a library that’s already known to be compliant, for example?

I feel your pain, you'd think with something as ubiquitous as taking credit card details there would be a wealth of clear concise information to help you guide you through the process, sadly not the case.

For your first question you need to find a QSA, check out the PCI council website for a list of those and all the official information. I would recommend shopping around a bit, quality and pricing does vary, you'll want someone familiar with your scenario. As you say you should get official guidance before using the views I provide.

For your second question, the first thing to say is PCI is contract based. It's completely your client's responsibility (depending on the agreement they have with their merchant bank or payment processor). So if your contract doesn't say you need to provide a PCI compliant solution, you don't have to...though I would be careful this could be a matter for the lawyers if you've implied it or fit purpose etc. Pragmatically there's a few options depending on the situation, it gets a little tricky here so i'll try my best:

• If the client has no control over the code or the system, they just receive the results of it, you'd likely be considered a service provider and you would need SAQ D for service providers at the minimum.
• If you just give the client the source code and they implement, then they are fully responsible for, they would have to do code reviews, penetration testing etc etc if that's in scope.
• If your client want's to plug your app into their system, and they don't want to be responsible for the PCI details of it then you would need to be PA-DSS compliant.

Ultimately it'll depend on what PCI scope your client can take on, they will likely need SAQ A at the very minimum (yes you may both need to prove PCI compliance), regardless of what course you take.

In terms of the nightmare, I'm not sure for native apps but for web apps if the PAN (cc number) touches your server it's full scope, SAQ D, in a nutshell yes that's a nightmare if you don't already have a secure setup. The best scenario would be SAQ A, but you would need a iFrame for that, if that's not possible then perhaps SAQ A-EP, you can use that with a direct POST so might be ok with the SOAP interface if that is directly from your app. I'm not sure if an app is considered 'e-commerce' which can use SAQ A and A-EP, if not you may need SAQ C. Take a look at requirement 6 at least, it covers software development.

For your last question, check out spreedly.com, they provide a PCI compliant connection to multiple gateways may be useful.

Good luck! And it'd be great to hear what you eventually decided to do.