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:
- Where should we go to get expert advice relevant to our particular scenario?
- 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?
- Is there a magic bullet we’re missing – a library that’s already known to be compliant, for example?
Answer
I don't think the above replies answer the question accurately. I would urge anyone who needs information specifically about mobile application development and PCI to read the following, taken from the Security Standard Councils documentation:
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.
and this:...
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
Read the last paragraph of page 2 and first paragraph of page 3. In a nutshell, at this point (17 Sep 2019) there is no validation for PCI compliance for mobile applications - only recommendations and guidance from the Security Standards Council.