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

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.

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.