PCI Compliance

As long as the merchant’s environment does not receive, transmit or store cardholder data, and all such data is directly processed by the PCI compliant payment service provider, no further PCI regulation exists. What remains is for the merchant to follow best practice security guidelines. And here the PCI Security Standards Council is very helpful.

The key is to follow structured security practices throughout the development process of the mobile app. The FAQ article referenced above goes on to say that “it is recommended that applications be developed using PA-DSS as a baseline for the protection of payment card data”. It specifically calls out PCI DSS requirements 6.3, 6.4 and 6.5.

In summary, these requirements are:

  • Apply industry best practices and incorporate information security throughout the software development life cycle (internal and via third party).
  • Follow change control processes and procedures, and review regularly. This would include, for example, separation of duties between development/test and production environments.
  • Train developers in secure coding techniques, especially how sensitive data is handled in memory, and so prevent common coding vulnerabilities in software development processes.
    No merchant wants to subject themselves to undue fraud and risk. In the absence of further PCI compliance regulation, the focus should shift from compliance to security best practices.

Even for merchants who rely on a PCI compliant service provider, and who can satisfy their obligations with SAQ A or SAQ A-EP, the question of security is still critical and should be viewed as a broader concern. The guidelines provided by the PCI Security Standards Council are certainly helpful, however, they are limited to cardholder data. Many new and emerging payment methods are used today, and are not within the PCI compliance scope, but can still be compromised. Merchants of all types and sizes would thus do well to consider the best possible security measures that are reasonably achievable.

Various supporting safety measures can be built into mobile apps. A good example is the ability for the merchant to block a particular version of the app if that version is found to have a security vulnerability. This is extremely important, since even if the vulnerability is fixed consumers don’t always upgrade their apps to the latest version, and would not be aware that a vulnerability has been detected in the version they have. For a fraudster this could become an easy target. The merchant can then gracefully encourage customers to upgrade, while limiting activity in the vulnerable version to only browsing and searching.

Since there is a good chance that the PCI Security Standards Council will at some point create compliance rules, following best practices now will also help; both to make the app safer and to make it easier to become compliant in the future.

Finally, the following points would be useful in your assessment and planning:

  • If you qualify for SAQ A or SAQ A-EP, make sure that your payment service provider is PCI compliant, and listed by Visa and Mastercard as such. If you process cardholder data within your own environment, make sure that you are completely PCI DSS compliant yourself, and that your assessment is up to date and all processes and procedures remain compliant.
  • Make sure that your mobile app connects securely to the PCI compliant data center and that data cannot be intercepted in transit.
  • Provide authentication in your mobile app such that shoppers cannot proceed through checkout without successfully authenticating. At the same time, offering a mechanism that is understood and trusted by the shopper is important, to avoid creating too much friction.
  • Add as many checks and balances into the development and go-live process as possible, especially making sure that no one person could submit a change without review.
  • Conduct regular vulnerability tests, both internally and using external testers.