3

Consider a client-side-only application. It may allow a user to make a payment by redirecting them to payment gateway website, where they enter the credit card details. If I understand correctly, in this case only the payment provider must be PCI compliant, as the app itself does not know anything about payment info at all.

Now, what if the app remembers credit card details (for convenience) and automatically populates the payment form on that website? The whole thing happens at client-side. Are there regulations regarding how the card number has to be stored on the client? Is it ok to remember it at all?

1

(Edited to reflect the uncertainty about the exact situation)

Note : not a QSA, just have some PCI experience

PCI DSS is a standard set by the payment companies - VISA, MasterCard and the rest. In general, it does not have the force of government regulations (though some state laws, I believe, reference it - consult your local lawyer). Rather, the Payment Companies require you to comply with the PCI (whether you need to be certified varies on your situation) when you have a relationship with them (directly or indirectly) to process cards. The way they can force you to comply is to, again directly or indirectly, prevent you from processing cards if you do not.

If you are not processing cards, if you are purely client, if you do not have this relationship with them (or a relationship with a card processing service provider that has a relationship with them), then they cannot require you to comply with it.

However, that said, the PCI DSS is a GOOD standard - you should be doing at least what it says if you're handling credit card numbers (PAN) as far as security. As well, PAN are considered Personal Identifying Information (PII) for almost all PII statutes I am aware of. That means that if you handle credit card numbers, you need to comply with all the PII rules. Again, your local statutes may apply here (as may the local statutes of your clients...)

If you are a merchant and providing the app, you need to comply with PCI if you are going to remember/store credit card numbers, even client side. If you are not a merchant, you probably still should, but may not legally have to. Fuzzy.

  • Mostly agree, but at some point the person who configured the software to point at a processor must have a relationship with that processor, else they won't get paid. And that relationship is governed by, and subject to, the DSS. An application that posts directly to the processor is more analogous to the merchant's web server than it is the customer's web browser. – gowenfawr Nov 18 '16 at 16:37
  • Agree - I misunderstood the question. I was reading the question as being a consumer app, owned by the consumer, for their convenience. If a merchant app, provided to the consumer, definitely qualifies for PCI, through that indirect relationship with the PCI companies through the provider. – crovers Nov 18 '16 at 16:41
  • That's exactly the fuzzy - if I throw together a branded App and tell my customers "Download the GowenJavaBuzz! App to pay for your coffee," it's in scope. If I tell my customers "Go to GowenJava.Com in your phone's web browser to pay for your coffee," it's out of scope. (And remembering the card data, which Chrome will do, is not within the scope of the merchant.) – gowenfawr Nov 18 '16 at 16:44
  • Edited to hopefully reflect this discussion and the uncertainty – crovers Nov 18 '16 at 18:45
1

Your application processes cards so it must be assessed against PCI-DSS. The fact that it is client-side only or that the processisng is done on the server does not change the fact that at some point, someone is inputting a credit card number via your application.

In the case of client-side applications you have three possibilities:

  • SAQ A if you have an IFRAME or redirect the curtomer to the processor
  • SAQ A-EP if you still do not store cardholder data but use some elements from the processor's site in your appliucation (typically APIs and Javascript)
  • SAQ D-Merchant if you store the data (your case).

The point here is the protection of the cardholder data from "something" accessing it when it should not. Imagine that you store the data on a SD card in the open and that this data is available to other applications - typically it has not been secured enough.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.