Is PCI compliance required by law?

We are creating a website where we will accept customer card data and pass it to merchant API.

Everywhere on the internet you will find PCI is required. But what if my website is not PCI compliant and I am still receiving customers card data? Is that illegal to accept card data without being PCI compliant?

We do not ever store customer card we just transmit. What problem could I face by law if I am not PCI compliant?

  • 1
    This will exclusively depend on the jurisdiction you are in. Contact your lawyer. – SeeYouInDisneyland Nov 14 '18 at 14:56
  • 1
    This is a legal question not a security one. Ask a lawyer. – DarkMatter Nov 14 '18 at 14:56
  • 2
    It doesn't matter if the law requires it, because if you read the small print of your contract with your card services provider you will find that your contract requires it. You can't get a contract for card processing services without agreeing to be PCI compliant. – Mike Scott Nov 14 '18 at 15:01
  • 1
    What @MikeScott means to say is, if you're compromised (and at that point, by definition, in violation of your PCI compliance) then you face hefty fines from the card brands - the people who already have your money in their hands, and can collect by simply not passing your payments back to you. – gowenfawr Nov 14 '18 at 15:10
  • 1
    @DarkMatter Agreed, to an extent. I think we can provide important information and context around the situation, despite the obvious legal aspects of the question. For questions with mixed on-topic and off-topic aspects, I tend to err on the lenient side and just answer the on-topic part in the most helpful way possible without straying into the details of the off-topic part too much. PCI-DSS is clearly on-topic here and there is plenty that can be said about it in relation to this question. – Polynomial Nov 14 '18 at 15:33

First, a disclaimer. Your question is partially a legal one, and I am not a lawyer. I did, however, work as a penetration tester for a registered PCI ASV for nearly 6 years, and have done quite a bit of PCI-DSS compliance validation testing. I last worked on PCI stuff when PCI 3.2 was the latest release, and it seems PCI 3.2.1 is now the latest, so there may be some changes since I last looked at it. I do not expect that changes in the new release affect the validity of my answer, though.

PCI-DSS compliance is not required by law in any jurisdiction I know of (although according to comments on the other answer by phyrfox, it is now part of state legislature in some jurisdictions in the US). It is, however, generally a requirement of your contract with your payment provider.

PCI-DSS is generally required whenever your infrastructure handles card data in any way. This can be storage or just transmission, and the card details do not even have to be textual - I have personally been involved in a situation where a company tried to argue that acting as a live video streaming service where customers showed their credit card to an agent for identity verification purposes did not fall under PCI-DSS because they "only" routed video data and never "handled" card data. Let's just say that their payment provider was less than convinced.

Before considering implementing PCI-DSS and all the headaches that come with it, you should try to avoid needing PCI-DSS compliance at all. You can do this by not having any card data hit your server. There are usually a few ways to implement this, and most payment providers use one of these models:

  1. When you go to check out, your web application sends the basket data (or at least a total cost) along with some information about your store (merchant ID, etc.) to the payment provider as a POST request. The user then enters their card information on their payment page, and a payment confirmation is then sent back to your web application. No card information is ever sent to your site, nor is it ever entered into one of your site's pages. This allows you to avoid the requirement of PCI-DSS compliance entirely.
  2. Same as the above, except the provider's payment page is embedded in an iframe in your checkout page. This gives a more seamless experience to the user without requiring your site to directly take in card data - the iframe is considered a separate origin, and SOP should prevent your page from gaining access to data within it. This is marginally more risky than option 1, partly because of potential browser exploits, but also because a user familiar with the site expects to see the page asking for card details, and an attacker might be able to use UI redressing attacks if they compromise the page (e.g. via XSS) in order to steal card data. This is still considered sufficient to avoid PCI-DSS compliance requirements though.
  3. Have card information entered into your web page, but have the form post the data to the payment provider. This means that payment card information is entered into your web page, but it never reaches your server. This is currently a bit of a grey area in terms of whether it triggers PCI-DSS compliance requirements, and whether or not this is acceptable is dependent on your provider and ASV (in the case of needing an audit). The reason that this is risky is that an XSS vulnerability in your page allows an attacker to directly read card data. I would generally avoid this option entirely.

The most common examples of the first approach are PayPal and Google Pay, where the merchant website (you in this case) hands off information to the payment provider and the rest of the process happens on their website, which is PCI-DSS compliant. This means you don't need to worry about card information at all.

These approaches are more completely detailed in the Best Practices for Securing eCommerce paper released by the PCI council. The most relevant parts of that paper here are sections 2 and 6.

Critically, PCI-DSS does not have to be mandated by law in order for you to see consequences by not being compliant. If you are contractually obliged to be compliant as part of your contract with your payment provider, and you are later found not to be compliant, they can force you to very quickly become compliant (which may be very expensive for you) or simply sue you for breach of contract. Additionally, in the event of a breach that reveals payment card information, you may find that a lack of compliance where compliance should have been required will count negatively against you in any subsequent legal or regulatory action. The Information Commissioner's Office (ICO) in the UK has previously fined companies large sums for breaching data protection laws, and the magnitude of those fines was often tied to whether or not the company was compliant with industry security standards, and whether they were knowingly negligent in their duty of protecting data.

I would strongly suggest option 1 or 2 wherever possible. Otherwise you're probably in for a difficult and expensive experience with PCI compliance.

  • Thanks for details explanation, i really appreciate you gave your precious time. – cool cool Nov 14 '18 at 17:11
  • Can you please also put some light on what if i am not pci compliant but i am processing cards, what problems could i face if my system is compromised. while we are not saving any card details at all. – cool cool Nov 14 '18 at 17:13
  • @coolcool If your site is compromised an attacker could simply steal all the card data entered for purchases after the compromise, by either modifying the page's checkout form to point to their own server, or by injecting a script into the checkout form to post the card details to them. The same goes for a stored XSS in the payment page. – Polynomial Nov 14 '18 at 17:21
  • The iframe approach has one other disadvantage which results in the first option being the predominant one for cases like this: iframe usage makes it significantly harder to make sure your site works correctly with assistive technologies for people with disabilities. – Austin Hemmelgarn Nov 14 '18 at 19:32
  • 1
    @Polynomial Not anything specific, just based on personal experience actually dealing with assistive technologies (and discussion with numerous other people who use them) and having serious issues accessing websites that use iframes. Overall, they cause two issues, first that you're dependent on the embedded site for how well they provide support for assistive technologies, and second they tend to screw with things like link ordering because many browsers have odd behaviors when it comes to choosing where focus goes when an iframe is involved. – Austin Hemmelgarn Nov 14 '18 at 20:13

PCI-DSS is required by law in some jurisdictions. If you plan on operating in those areas, make sure you follow all local laws. As an example, PCI-DSS is not required as the US Federal level, but some individual States require PCI-DSS or a similar protection. Also, major credit providers require PCI-DSS, and may charge non-compliant organizations a monthly fine every month that they are not in compliance. These fines can easy cost 100,000 USD or more per month, or may result in termination of your merchant account.

Overall, there is no One Definitive Answer as to the consequences, if any, of not implementing PCI-DSS. The effects may range from nothing, to heavy fines and loss of merchant accounts, to court-mandated punishments, including fines and jail time. The specifics of what will happen to you and your organization depend on the jurisdictions to which your website is held accountable to. If in doubt, you should just opt for compliance, as most third-party payment processors make this very simple, to the point where your website doesn't even need to handle the raw credit card data directly.

  • Can you point to where there is a legal requirement in state law? My understanding is that PCI-DSS falls under contractual obligations with the payment provider, rather than law. – Polynomial Nov 14 '18 at 14:57
  • 1
    NOTE: Not A Lawyer. Per Wikipedia: In 2009, Nevada incorporated the standard into state law, requiring compliance of merchants doing business in that state with the current PCI DSS, and shields compliant entities from liability. In 2010, Washington also incorporated the standard into state law. Unlike Nevada's law, entities are not required to be compliant to PCI DSS, but compliant entities are shielded from liability in the event of a data breach. – DarkMatter Nov 14 '18 at 14:58
  • Interesting, but yikes, that sounds like an awful law! I hope shielded liability for compliance doesn't catch on elsewhere. – Polynomial Nov 14 '18 at 15:00
  • 1
    @Polynomial As DarkMatter says, Nebraska's AB179 is an example. Three states total have laws like this. Others may choose to do so in following years, no telling what could happen. The point is, navigating local law is a legal landmine field, so simply "just doing it" is the best practice. – phyrfox Nov 14 '18 at 15:02

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.