1

I am looking for advice on PCI compliance. I am being told that I am not currently PCI compliant although I am not sure if this is accurate.

We outsource the payment management and card storage to a 3rd party service and only store the external ID and last 4 digits of the card.

I collect the CC data on the frontend and pass it to a Node application which sends it to our 3rd party service. This is required because the API key/secret should not be exposed to the client for obvious security reasons.

However I am being told that passing the data from one application to another is against compliance, now I am being asked to send the CCs directly from the browser which would mean each person using the app would have the API key/secret being sent to their local machine and if known someone could easily use this to access our payment instruments.

What do I do? Is it actually against compliance just to transmit the data from one service to another?

  • Who is telling you this? What does your QC say? – schroeder Jan 28 at 10:14
  • The discussion is between a backend coworker, my CTO and myself. They are both telling me we should send the data from the client and PCI forbids me from sending the data to another service. We are a small/medium sized company, our QA doesn't handle such matters. – Marcus Horne Jan 28 at 10:29
  • 1
    Sending from the client to the payment processor is the normal way to do it. If it breaks your API flow, then you might need to redesgn your API flow. – schroeder Jan 28 at 10:57
  • It's not so much the API flow I am worried about. Surely exposing the API key/secret in the browser would allow just anyone to control our 3rd party payment processing service? I'm not sure if I feel comfortable doing this. – Marcus Horne Jan 28 at 11:10
  • That's part of the API flow, isn't it? Where the keys are, and what triggers the API are all part of your flow. – schroeder Jan 28 at 11:13
1

You’re right, that is a dilemma. I’ll try to answer point-by-point.

I collect the CC data on the frontend and pass it to a Node application which sends it to our 3rd party service. ... However I am being told that passing the data from one application to another is against compliance,

It’s not so much passing data that’s non-compliment (after all, you need to pass it to the 3rd party) as passing it through your server that’s the problem. I like to describe PCI levels in terms of what would need to be compromised in order to steal card data. If the answer is “my webserver” or “my application”, they you’re under SAQ-D, the most onerous. If the answer is “my communication channels with a trusted third party”, then you are probably A or A-EP, like most ecommerce.

This is required because the API key/secret should not be exposed to the client for obvious security reasons. ... from the browser which would mean each person using the app would have the API key/secret being sent to their local machine and if known someone could easily use this to access our payment instruments.

This isn’t as obvious as you’d think. What can someone actually do with these credentials? If all they can be used for is to give you money, they’re not really that sensitive. If they can be used to refund it, they’re critically sensitive. If they can be used to retrieve information that isn’t the PAN, that’s important but not as bad.

This is a big reason why the API credentials are almost certainly not what you log into their portal with. You may also have a different set for non-payment operations.


In the end, you should talk to your payment provider. You’re not the first person to have these issues, and they may already have guidance on how to handle it. (If you are the first... run!)

Many payment systems I’ve seen ask the server to make some kind of setup call, using secret credentials, which then returns a one-time-use value (url, transaction key, etc) to be delivered to the client. Others just restrict what you can do with those creds so they’re safe to expose to the user.

It’s also possible you’re using the wrong API/endpoint. You might be using one intended for in-person payments, and there’s a different one for ecommerce. I’ve seen that too (and made that mistake myself).

  • Thanks for the thorough answer. After further investigation and a short pen test session, I can confirm that the credentials are scoped to not allow the user to perform any essential functions like issuing payments or refunds. I guess I can consider the credentials as non-sensitive in this case. – Marcus Horne Jan 29 at 10:42

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.