A client is asking for a way so his app can receive credit card information and store them. He needs this to process scheduled payments from his clients.

I told him that I can build a asymmetrical (RSA) encrypted solution that would store the data and only he would be able to decrypt it if he has the correct key.

The private key would only be held by the client himself. So the system as a whole would not be able to decrypt the information at any point in time.

Would this be a legal solution? Since the data is always encrypted at rest, would this violate anything in regards to creditcards? The only way this could leak, is via the key of the client. If he keeps it say, would there be any trouble?

  • So the credit card information would be entered on the client, and both public and private would also be on the client?
    – user163495
    Commented May 28, 2020 at 19:53
  • No not really. The credit card information would be entered on the client, would be encrypted ON the client and submitted as encrypted data and stored encrypted at rest. The server would NOT know the secret key.
    – John Nett
    Commented May 28, 2020 at 20:08
  • You and your client would be well advised to talk to your card processor about what tokenization solutions they offer, so that you never have to encrypt and store PAN.
    – gowenfawr
    Commented May 28, 2020 at 20:09
  • @gowenfawrd with all due respect, the question is not "how to tokenise PANs" or similar. The question is, can credit card data be stored at rest - with encryption. Basically zero knowledge data storage.
    – John Nett
    Commented May 28, 2020 at 20:33
  • 2
    The only case it wouldn't apply is if you only ever saw the encrypted blobs, and never had access to plaintext cards or to the encryption keys - and in that case, the person with the keys (your customer?) is the one on the hook. DSS certainly applies to someone in this scenario.
    – gowenfawr
    Commented May 28, 2020 at 20:52

2 Answers 2


If your client is required to be compliant with PCI DSS, then yes, the card data must be encrypted while at rest. But, that's the easy part. The hard part is management of the keys used to decrypt the card data. There are 90+ pages of things you need to know for this (see https://www.pcisecuritystandards.org/documents/PCI_PIN_Security_Requirements_Testing_v3_Aug2018.pdf). Your process must be documented, you must keep audit trails, etc.

Most businesses feel that it's much simpler to offload the storage of card data for recurring billing purposes to a service that is setup for this, such as Authorize.Net. See https://www.authorize.net/our-features/recurring-payments.html.

  • Is this really the case, even if my service does not use the credit card data? I will just see the encrypted data - basically zero knowledge encryption.
    – John Nett
    Commented May 28, 2020 at 21:02
  • Your question seems to imply that your system would be encrypting the data ('I told him that I can build a asymmetrical (RSA) encrypted solution that would store the data and only he would be able to decrypt it if he has the correct key'). If that's the case, then you can't say that your system is zero-knowledge- the plaintext card info is passed to your system, and your system encrypts it. That in itself may or may not make your system subject to PCI, but whoever is holding the private key surely is. If that's your client, he might want to read the document I linked above.
    – mti2935
    Commented May 28, 2020 at 21:09
  • sorry for the confusion. The system also consists of the client part, which generates the asymmetrical keys and also is the sole holder of the decryption key. I still consider it part of the system. In this case, it looks like the client is responsible for handling the data.
    – John Nett
    Commented May 28, 2020 at 21:12
  • The PCI PIN Security Requirements only apply to entities processing PIN data. The key management requirements is PCI DSS are not as prescriptive (you may argue that they should be, PIN is a robust standard for key management, DSS is not). Commented May 29, 2020 at 15:29
  • 1
    Our QSA determined that if our organization ever holds or has access to the key, then any of our systems holding encrypted in-scope data are in scope for a PCI DSS audit, whether or not that system has access to the key. Commented May 31, 2020 at 6:00

You may find PCI SSC FAQ 1233 useful. "How does encrypted cardholder data impact PCI DSS scope for third-party service providers?" https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-does-encrypted-cardholder-data-impact-PCI-DSS-scope-for-third-party-service-providers

  • 1
    Please include the relevent parts of the link in your answer. Else this answer only lives as long as the link is active.
    – schroeder
    Commented May 29, 2020 at 16:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .