I'm currently attempting to wrap my head around PCI compliance - and what I need to do for my business to be compliant. I would like some confirmation on what I've found so far.

I accept payments in a mobile application. We take payment details and pass them to our own REST service (over HTTPS), and then that service instantly passes them on to a third-party payment gateway to handle the payment. We get confirmation, and the app gets that confirmation. At no point do we store the payment details. My business accepts just over 20,000 payments a year.

So, would I be correct in saying that:

  • An SAQ-D needs to be completed.
  • Every quarter I need to get some form of network scan from an ASV?

I would also like to know if there are any other steps necessary to be PCI compliant?

Also - if I use the PayPal mobile SDK, what (if any) additional steps would I need to take to become PCI compliant?

3 Answers 3


The mobile application cannot currently be validated or considered a compliant payment application. Guidance on security and compliance in mobile applications has been issued by the SSC here: https://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v1.pdf

As your environment is receiving and transmitting cardholder data, you are correct in your assertion you should complete SAQ-D. SAQ C would be more relevant if you were processing data in a payment terminal in an IP environment. There are lots of things you need to do to be compliant in addition to the scanning you reference above. The following is not an exhaustive list:

  • Firewall ruleset reviews at least every 6 months.
  • Server hardening in line with industry standards (CIS, NIST, SANS)
  • Anti-virus installed, running scheduled scans, generating logs
  • Systems patched and up to data Software development lifecycle - secure coding, peer review, separation of dev, test and production environments and separation of duties between those environments
  • Change control for software modifications and deployments
  • Access control with documented authorisations for Role Based Access Control
  • Two factor authentication for remote access
  • Password policies
  • Physical security of the in-scope environment (CCTV, badges, visitor controls)
  • Centralised logging
  • Consistent NTP configuration with internal peering and external sources
  • Quarterly internal/external vulnerability scanning
  • Annual internal/external penetration testing
  • IDS/IPS File Integrity Monitoring
  • Lots of policy and procedure documentation

Note that if the payment data was transmitted directly from the mobile application to the third party payment service provider, your systems would never handle cardholder data and PCI would only be relevant to the due diligence performed to validate the third party is PCI compliant and accepts their responsibilities.

  • Thanks a lot for the list. The documentation can be quite cryptic about what seems necessary, and when it's necessary. I may say if I can find a way of communicating directly with the payment gateway from the app so that PCI compliance is less of a hassle.
    – Seer
    Commented Oct 6, 2014 at 13:49
  • @AndyMac - You mention 'Firewall ruleset reviews`. How is this addressed from a documentation perspective? For example, if you have a firewall rule defined, is it a requirement that these are documented?
    – Motivated
    Commented Mar 16, 2016 at 17:28
  • @Motivated it's a requirement that the rules are justified for technical or business reasons. They don't have to be documented explicitly but without reference of function, it's may difficult to identify function or justify. Often the rule may have a change control reference or a comment for its purpose. The firewall ruleset review should be documented to demonstrate a methodology was used and actionable output created - response to the output should also be demonstrable.
    – AndyMac
    Commented Mar 17, 2016 at 12:06
  • @AndyMac - Thanks but that's confusing. So bear with me. So if you are saying that they are not documented explicitly or are without reference or function, does it mean a comment is acceptable? How does that sufficiently describe a methodology? What do you mean by an actionable output?
    – Motivated
    Commented Apr 12, 2016 at 8:36
  • @Motivated the comment can contain the justification for the rule. The methodology is relevant to how the ruleset review is done rather than how the rules are justified (i.e. in change control, in comment or in other documentation). By actionable output I mean that a ruleset review should result in something the business can react to - that is to say, the review report should result in actions taken to remedy issues identifed
    – AndyMac
    Commented Apr 21, 2016 at 17:58

If you're sure you never store the payment details, not even in things like swap files or core dumps, then I think SAQ-C will be sufficient. I think it's almost certain that you'll need to change some of your processes to complete the SAQ successfully; you won't just be able to fill it in and say that you're done.

  • 1
    I always thought that SAQ-C wouldn't apply to this, because it was aimed more at POS type systems? This app will be installed on a customer's phone, does that make a difference?
    – Seer
    Commented Oct 6, 2014 at 13:22
  • @Seer that's my understanding also, here's an article on it pciguru.wordpress.com/2015/12/07/using-saq-c
    – Richard
    Commented Dec 12, 2015 at 19:42

I agree with Mike Scott that SAQ-C should be ample in your case. SAQ-C does require you to be scanned by an ASV.

Do mind that you don't store any cardholder data at any point. It's important to verify that you:

  • clear logs
  • prevent crashdumps containing cardholder data

For mobile applications you should ensure to use non-serializable datatypes. This prevents crashlogs from containing sensitive data. For Java you have the example of the transcient datatype.

You should be good on the rest. Of course you can always improve your security organization beyond PCI-DSS. Compliance is about getting the bare minimum for a certain situation, it never hurts to evaluate things beyond a certain compliance standard.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .