We're developing a web application in which certain not logged users (clients) need to send their credit card details to other users (merchants) - which, we'll assume, are PCI compliant.

We are looking into getting PCI compliance, but the process will surely needs a lot of time. Therefore we are investigating other solutions which don't require us getting a certification and protect us from getting sensible data stolen.

Our plan is to:

  • Make the merchant generate a private and a public key
  • Store the private key inside his browser using localstorage (and provide a mean to backup it)
  • Provide the public key on the form used by a client
  • Before the client send the data, encrypt everything with the merchant public key
  • Store the encrypted data in our server
  • Provide the encrypted data to the merchant
  • Make the merchant decrypt the data in his browser using his private key

The idea was to use JavaScript and the library jsencrypt.

Do you see security issues in this workflow? Do you think we still need PCI compliance when employing a system like that? The reasoning is that, for anyone without the private key, those are just random bytes.

The only attack I can think of is someone compromising the server and replacing a merchant public key with his own key. But he could as well steal a token for another payment gateway and fake the communication needed to do something nasty.

We know about services like Paymill, Braintree and Stripe (which offer pretty good client side libraries) but they're not fitting for our solution (or better: they're alternative we'll make available for merchants - but it should be up to them to decide).

Thank you in advance

EDIT: I totally agree with you guys and I'd rather work with thirdy party solutions.

The problem is that we're working in a market in which most of our competitors are small companies working without PCI compliance (and most of them even without HTTPS!!). Our competitors simply receive CC data, store them and give access to the users.

We know about the risks of such approach, but the users don't and they prefer their solutions to ours because they'd rather have the whole CC data, instead of just having buttons to execute actions.

  • 2
    When the card brands come knocking with a breach notification it will not help you that your competitors were making the same mistakes. It sounds to me like being the PCI compliant player in the your market would be a value prop for your business. Commented Aug 1, 2014 at 10:53
  • Absolutely! It's just hard to justify the added costs to people who don't know about PCI compliance. Hence why we were looking into alternative solutions. Thank you for all your feeedbacks.
    – framp
    Commented Aug 1, 2014 at 15:25

5 Answers 5


(Disclosure, I work at Braintree)

If a server is providing a form that customers will enter credit card numbers into then that server falls within PCI scope. This is regardless of if you encrypt the data in the browser. The reasoning here is that an attacker can modify the page that is sent to the browser to siphon credit card data out of the page DOM before encryption.

You would need to work with a qualified security accessor (QSA) or your merchant account provider to know what your PCI process will look like. If you're processing under 1 million transactions then it would likely be a self-assessment process. The determination of which self-assessment questionnaire (SAQ) to fill out is based on how much access to the cardholder data you have and if you store it.

  • Thanks a lot for the fast response! If having a form is enough to make your server fall within PCI scope, do you need to be PCI compliant even to use Braintree API? Looking at this tutorial I was under the impression that the server wouldn't need to be PCI compliant - and the only difference would be that, instead of sending a Braintree token, we would be sending the encrypted data.
    – framp
    Commented Aug 1, 2014 at 1:49
  • 2
    Yes! Any business that takes credit card information needs to be PCI compliant. We definitely try to point that out in our FAQ. What the Braintree integration does is try to help reduce the burden as much as possible. When properly implemented, you would qualify for using the SAQ A-EP form of the self-assessment questionnaire. This is pretty much the same story as the other providers you mentioned. Commented Aug 1, 2014 at 3:03
  • 2
    You have to be PCI compliant if you are involved in storing, processing or transmitting credit card data. The question is what level of validation is required and what SAQ is most applicable to your situation. From the PCI SSC it comes down to who is generating the payment forms. They have put out some good FAQs lately on this. See this one, and this one.
    – Timee
    Commented Aug 1, 2014 at 18:03
  • Is this true even if the form posts directly to a PCI compliant 3rd party over SSL? (Our server would have no visibility of the card details)
    – NickG
    Commented Jan 4, 2017 at 17:42
  • @NickG yes because your server still impacts the security of the transaction. Things like malicious javascript can extract the credit card data out of the page. What you're describing is typically called Direct Post in documents. You can read more about the reasoning in Understanding the SAQs for PCI DSS version 3. Commented Jan 5, 2017 at 2:04

There are many 3rd party payment processors that allow you to transparently use their forms and processing - including paypal, google, worldpay, and many others. This can be pretty much transparent to the user if configured correctly. This is the best way of side-stepping the PCI requirements - never process any of the card information...

There are some problems with your scheme:

  • First you must have assurance that the page and code has not been tampered with including any dependent libraries. So HTTPS at a minimum but also good change control practices etc.
  • Secondly any XSS, XSF, MITB at the client could steal their private key.

Even large organisations are often choosing to mitigate the card handling risk by using 3rd party processors...

  • Thank you for your response. Am I wrong in assuming such attacks could be made also when using a 3rd party solution? The attacker could steal a token in the same way (even though the damage will be limited to the "permissions" given to the token)
    – framp
    Commented Aug 1, 2014 at 8:51
  • 1
    Depending how it's setup you could be subject to an XSS on your site that leads to a phishing version of your payment processors site however in this situation the user is entering details into the wrong site rather than it being stolen from the right site. The payment processors own code and site should be robust to direct attacks on their implementation given the pounding such code gets. Based on my understanding a token is restricted in terms of it's capability and does not fall under PCI-DSS as it reveals / contains no card information. (Disclaimer: not a PCI-DSS expert)
    – Andy Boura
    Commented Aug 1, 2014 at 9:01
  • @AndyBoura the solution you describe would still require the server that hosts the page to be considered in PCI scope. You can read about this in the PCI-DSS E-commerce Guidelines, specifically in section 3.4.3. The blue box there says "Merchants should understand that outsourcing to a third party via a shared- management implementation does not allow the merchant to outsource PCI DSS responsibility." (I run the PCI-DSS process for Braintree, a PCI Level 1 Service Provider) Commented Aug 1, 2014 at 10:49
  • Would this still be the case when it's an iframe or redirect? i.e. you are not serving the page? For example a cname resolving to a 3rd parties served page? I would expect not? But of course I would defer to your knowledge here. (if this is the case every website with a pay or donate via paypal button would be in scope!)
    – Andy Boura
    Commented Aug 1, 2014 at 11:00
  • Ah, useful reference there thanks. So you could massively reduce your requirements but not absolve yourself of responsibility?
    – Andy Boura
    Commented Aug 1, 2014 at 11:44

If you're storing the card data on your own servers, even if it's encrypted and you don't have the key to decrypt it, then you need to comply with the most elaborate version of the PCI standards and use SAQ-D. I would suggest that you don't store the card data at all, but get the merchant to store it for you. Then you should only need to use SAQ-C.


John Downey has given the best answer but just to expand on the biggest problem with this part of the workflow:

Make the merchant generate a private and a public key

Store the private key inside his browser using localstorage

So, lets say you have a dozen merchants with public and private keys stored in their browsers.

You don't store their keys but your server has a security hole of some kind.

An attacker gets control of your server.

The attacker modifies the pages that your merchants will use, adding some of their own javascript/etc.

The next time the merchants log in, the javascript retrieves their private key and sends it to the attacker.

The attacker now has almost all the private keys.

All data sent to the merchants is now open to them because they were able to gain control of your server.

  • This is very true. But if I were to use a 3rd party soluton and store a token, the attacker could simply use the token immediately, without waiting for users to login. Maybe monitoring the application with an external machine (with the capability to shut down the service in case of breach) can be a way to minimize private keys theft. I think the problem lies in the goal, which is transmitting CC data to the merchants. I don't think a 3rd party service would fare better. Using a token which enable certain actions and a restricted destination account is probably the safest thing.
    – framp
    Commented Aug 2, 2014 at 8:36

PCI standards exist for a reason. While the process of achieving that level of security may be arduous, it is necessary to protect your client's data. Let's be clear about that; it's not just your data, it is data that your clients have entrusted to your care, and if you fail to secure it using reasonable best practice, your company is opening itself to huge, crippling levels of liability.

If you don't want to do everything involved in payment processing, you are far better off working with a payment vendor. They can make the payment process easy and seamless these days, with minimal grief for your clients.


You must log in to answer this question.

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