I'm concerned about my client being Payment Card Industry (PCI) compliant. Recently, I was tasked with rebuilding a payment processing component. As part of my analysis, I asked the project stakeholder if they wanted to be PCI compliant. The short answer from his is that "Becoming PCI compliance isnt in scope for this new component rebuild" As an engineer, Do I have any option to avoid building something that is not PCI compliant? I.E. Storing a customers credit card details into a system of records is just plain bad.

p.s. I would like to keep my client. Obviously I could just terminate my relationship with the client, but I'm exploring other options than this to start. I am proposing to my client that both achieving PCI compliance as well as rebuilding the components to be more streamlines could be achieved together.

At the end of the day, I want my clients business to have LESS RISK.

New contributor
jbooker is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 2
    I'm voting to close this question as off-topic. – Gregory Currie Mar 26 at 2:13
  • 2
    I thought that if you are found to be not PCI compliant, credit card processors will take away your ability to handle credit and debit card payments? – gnasher729 Mar 26 at 8:57
  • This question is maybe better addressed on security.stackexchange.com or softwareengineering.stackexchange.com . And, investigate Stripe and Braintree. Used correctly, both confer PCI compliance on your operation. And their processing fees are equal to or lower than the way you're doing it now. – O. Jones Mar 26 at 12:01
  • 3
    What is pci? Please explain st the question is understandable by itself. – guest Mar 26 at 18:13
  • Lesson for the future: Don't willingly offer your clients options that you are not willing to accept. – David Schwartz Mar 26 at 18:41

If you want your client to adopt the feature then state that you will offer it for free, as a standard feature.

(i.e. include the cost as part of the rate, take the choice away from the customer)

"I asked the project stakeholder if they wanted to be PCI compliant."

Be careful about asking binary yes/no questions where one of the answers is obviously stupid... people will occasionally interpret this as a legitimate question and assume there is a genuine choice to be made (and that both answers are equally valid).

Once you ask the question the customer may have thought:

  • do I need this?
  • will it cost money?
  • will it add complexity to the project?
  • conclusion: I don't want this

I'm not suggesting that you are in the wrong to ask, just that you might have been able to avoid the problem by not asking.

  • 1
    So in the feature request, they are asking explicity to persist credit card details into their system of records. This is what prompted me to ask the question. Its not that I am just offering this after receiving a high level request, which I would agree would be stupid to ask. The only reason for asking is because the request almost explicity is non-PCI compliant. So asking may at the very least provide them with insight into the fact that they havent thought of this security yet. I do like your input though and I appreciate all honest feedback. – jbooker Mar 26 at 2:27
  • 1
    Also, I would say its self evident to the person asking for the feature that its inherently stupid. In the mind of someone who is not educated in the area of software, they may feel honestly that this is the only way to solve their problem. I always like giving the client the benefit of the doubt. Even if I think the request to persist credit card details is stupid, I wouldnt necessarily tell someone who is paying my check that they are stupid. Hopefully that helps. Again, I appreciate your answer. – jbooker Mar 26 at 2:30
  • I like the answer anyways. :) – jbooker Mar 26 at 2:32
  • 5
    In this case, you wouldn't ask "Do you want to become complient?" You would ask, "So how are we handling the complience?" -- Asking them like this gives the impression that it is absolutely needed, where the first question makes it sounds optional. – さりげない告白 Mar 26 at 9:17

Storing a customers credit card details into a system of records is just plain bad.

True, but as it stands, that statement is merely your opinion. It carries no legal authority. Be very careful about how you advise your client in this matter.

Do you specialize in PCI-DSS compliance? What's you actual experience with PCI-DSS compliance? If you don't specialize in this area then my suggestion would be to advise the client that they may have PCI-DSS requirements and that they should engage with someone who specializes in this area to advise them on what, if anything, they need to do. If you don't specifically work in this area then anything you tell the client is merely conjecture on your part and so anything/everything you tell them may give them cause and legal grounds to sue you.

  • I'm not sure something can be absolutely "true" and be an opinion at the same time. Nevertheless, you ask some great questions and I really appreciate the input. Your thoughts have brought me more insights. Thank you for this. – jbooker Mar 26 at 16:47
  • And you are absolutely right, I am not an PCI expert at all. What I am trying to balance is advising the client on how they can best minimize risk, while at the same time not advising on something I am not an expert in. – jbooker Mar 26 at 16:52
  • Understood. I'm always very careful with clients regarding issues related to legal requirements, regulatory requirements, etc. If it's an area I don't have expertise in and there may be legal or business/financial ramifications I always advise them to seek out specialized expertise and I try my best to direct them to the right resources. – joeqwerty Mar 26 at 17:52
  • Good feedback. Thank you for being honest. The wisdom of the crowd could never be overstated! :) – jbooker Mar 26 at 18:17

In an ideal world, you could compile the information about PCI compliance and the potential hefty penalties for lack of compliance and present it to your customer. But ultimately you can not force them to accept your proposal and include PCI compliance as part of your project.

However, if they refuse to address PCI compliance you need to clearly document the issue and your customers' refusal to include it. I would go so far as to include it in the Statement of Work and clearly state that the customer has refused PCI compliance. Without it clearly documented, and signed off on by your customer, you could potentially be liable if the customer were breached in the future. A signed statement/document will help protect you from potential liability and negligence claims.

There is also the question of the merchant account/credit card processor; many require a signed contract that stipulates standards and security for use of their APIs. Fully read and understand the Terms of Use of the APIs and make sure that you are not liable for failure to follow them.

In addition, you should review your professional liability insurance closely. Most policies wouldn't likely protect you in a situation like this, or at the very least they would cover it then refuse to renew.

Having all of the above doesn't prevent a customer from suing; I've had customers sue even with a signed Statement of Work clearly outlining the potential issues and the customers' refusal to address them. The documents ultimately had the suit dismissed but I still incurred great expense and headache.

All of that aside I would speak with your attorney and make sure that you aren't putting yourself into an awkward legal position.

  • Good insights Steve, Thank you for this. And for the hint at potential legal issues.Its insane that I have to think about protecting myself from litigation when what prompted me to pursue the topic of PCI compliance was to minimize risk for the client. But its all good input. I really appreciate it. – jbooker Mar 26 at 16:50

In every endeavor, you have to decide for yourself what value you place on ethics, and what value you place on your own morality, and determine for yourself where the line is crossed.

In addition, you have to weigh the benefit of the customer relationship against the potential for damage to your reputation.

That being said, storage of CC info is not quite as simple as you may see it. PCI compliance is something I've had to dance with on more than a couple of occasions. First, know that the rules keep changing, so what was true 2 years ago may not be true today.

Storing CC information is required for a payment processing system for reconciliation. Exactly what can be stored and how it is stored and accessible is the "meat" of PCI compliance.

As I see it, you have these options:

  1. Decline the project, explaining that you are not prepared to have your reputation attached to something that puts consumers' information at risk for PCI non-compliance.
  2. Insist on engaging a PCI compliance consultant and following their guidelines.
  3. Research and become fluent in the relevant components of PCI to this project, and insist on implementing them.
  4. Accept the project as-is. Keep in mind that since you are a contractor, you may be incurring some liability for any financial loss from this system. Consider this option quite thoroughly before proceeding. Knowing that it is non-compliant going in, your Errors and Omissions policy may not cover you.

No one but you can make this decision, but don't underestimate the danger in option #4.


I'd ask the client if they know what the consequences of not being PCI compliant are. The first consequence is the possible loss of any ability to process debit or credit cards if their card payment handler finds out. The second consequence is liability for financial losses if people lose money because the company is not PCI compliant.

I suggest you publish the name of the client, so we can all avoid using their services and become victims of credit card fraud.

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