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

Question

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?

Censurable

PCI advice comes from certified "QSAs", the council maintains a list: pcisecuritystandards.org/approved_companies_providers/… – Veliavelick

The best option would be to develop the app according to best practices then completely hand it off to the client and make it clear its their responsibility to perform the necessary documentation and code review tasks. – Veliavelick

If as a third party you are developing this for more than 1 client, PA-DSS may also apply. – Veliavelick

What ended up happening here? Do apps like this need to worry about PCI-DSS? – Calciferol

@Calciferol : Ultimately this project never came to pass, so I'm afraid that for me, it became a non-issue. I'm relieved to be able to close that can of worms for now. – Censurable

Answer 1

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.

Bastardy

I saw this on SAQ C, so guess that's not for you; pciguru.wordpress.com/2015/12/07/using-saq-c – Bastardy

Answer 2

I am a PCI QSA.

Like a lot of things with PCI there are several gray areas in the scenario. You can ask 10 QSAs the same question and will likely get 10 different answers, which is a sad reality of the lack of clear guidance around such scenarios (and there are many oddball scenarios).

So, in my professional opinion (I said opinion), a mobile app where 100% of the card ingestion, processing and transmission is handled on the mobile device AND the cards used on said mobile device belongs to a single user, the risk is very low. If I read the question right, you are the app developer. You are not the merchant, and if all you are doing is writing the code for some merchant or service provider, this problem sits more with them.

They will likely need to have an application penetration test performed and some traffic analysis to confirm the cardholder data flows straight from the device to the acquirer (the processor). You as the software developer are not on the hook for anything PCI, unless you are selling this app on the App Store or some such way. In that case, the above answer is more accurate. You would likely need to put this application through a PA-DSS review with a PA-QSA. Assuming it passes, it would be listed on the PCI SSC website under PA-DSS validated applications. This does not make the processor PCI compliant, but it can help with the assessment process.

As for the magic bullet, there is nothing. However, if you use Stripe as the processor and their mobile SDK to handle and transmit the cardholder data, then Stripe will assume the PCI responsibility after you complete a short questionnaire on their website each year.

I realize this question is pretty old, but I thought the answer could help someone downstream struggling with this issue. Also, I have no connection with Stripe, but I recently encountered this problem and was surprised to see how Stripe handles it. Pleasantly surprised I might add.

Superfluous

Can you reformat this answer so it isn't one giant paragraph? – Twiddle

Done. Sorry about that. – Superfluous

Answer 3

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.

Errol

Answer 4

This FAQ may help: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application?q=mobile&l=en_US&fs=Search&

This basically says that you are just responsible for following a "Secure Software Development Lifecycle", with such controls outlined in Req 6.3, 6.4, & 6.5.

Fraught