6

I am rebuilding a clients eCommerce site using Wordpress and WooCommerce as the framework. Their current eCommerce site takes the credit card information and stores it for later manual processing. To "secure" the data it sends halve the credit card number through email and stores the rest. The client wishes to be able to manually charge the credit cards through their financial service software due to negotiated rates. This eliminates the option to use a payment gateway like stripe.

Their current process appears to be a valid practice according to a post by webengr on this thread: https://groups.drupal.org/node/22389.

"Many of you are probably aware how zencart/oscommerce does it. The basic offline cc processor for zencard saves part of the credit card then emails the other part. http://tutorials.zen-cart.com/index.php?article=67 There have been discussions about it this is good enough to meet the 'PCI compliance' Supposedly, your business is PCI compliant as long as you are not storing Track 1 CC data which consists of the full CC number, name, expiration date."

Is this truly a legitimate practice?

How can I securely store credit cards for later manual processing while adhering to PCI standards?

  • Is there a service that can store the credit card details and transaction via tokenization. Then login to retrieve the card details by the token and manually charge them through their financial service provider?
  • What other security practices do you suggest? Deeper answers then using SSL.
Originals
  • 73
  • 1
  • 6
  • This same PCI/local storage question was asked last week sometime... – Dave Oct 29 '15 at 23:34
  • Do you mind linking me to the specific post you are referring to? – Originals Oct 29 '15 at 23:36
  • Actually, in one form or another I've seen the question of "How can I securely store credit cards for later manual processing while adhering to PCI standards?" across several questions I've read. But I don't recall coming across a good, direct technical answer to it anywhere yet. Beyond the obvious, but sometimes unworkable, "You shouldn't". (Which, admittedly, would be the first response that crossed my mind if a client asked.) – mostlyinformed Oct 30 '15 at 04:40
  • @Originals One question: does your client store the CVV code (the 3 or 4 digit code on the back)? – mostlyinformed Oct 30 '15 at 04:43
  • 2
    And, uh, BTW, about that linked page.... "IMPORTANT NOTE: This module is NO LONGER included in Zen Cart because it does not meet PCI compliance requirements for ecommerce security. The BETTER alternative is to use a real live payment gateway service connected to your business merchant account." – mostlyinformed Oct 30 '15 at 04:46
  • Alas, looks like my edit to the original question has been shot down. (SE lesson: Wait to make sure your edit is approved and *then* put a bounty on the question). At any rate, in my view the useful questions the OP is *trying* to ask are (1) what specific types of services are out there that will store payment card info for a merchant and later allow the merchant to retrieve the full, original card info for entry into an arbitrary payment application/ gateway?; and (2) are there tokenization services that can allow a merchant to achieve the same thing except with, well, tokens instead? – mostlyinformed Nov 02 '15 at 16:39

3 Answers3

3

The relevant sections of PCI DSS v3.1 are as follows:

3.2 Do not store sensitive authentication data after authorization (even if encrypted).

However this is allowed if

  • There is a business justification and
  • The data is stored securely.

Also

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic- stripe data.

However, storing the CSV after auth is a complete no-no:

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not- present transactions) after authorization.

Regarding the display of the card number itself, it is OK to show the first six and last four digits:

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

The rest of requirement three (3.4.1 to 3.7) describes how you can store card data. The long and the short of it is that you must store it encrypted using industry standard accepted encryption protocols. Full disk encryption is acceptable. Then it comes down to key management. This is the tricky part. The key for PCI DSS is to document how this is going to work and how this meets these requirements.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Wish my edit to the original question had gone through; I read the question as sort of trying to ask about what sorts of services are out there that will (a) handle meeting all those PCI requirements that you well listed above and (b) do so in such a way that later allows employees client access to the original card info for manual entry into a third-party payment gateway. (Operating on the assumption that OP's client should retail that model of accepting card info, storing it somehow, and later using it via manual re-entry, which is definitely is a substantial assumption.) – mostlyinformed Nov 02 '15 at 16:00
2

There are PCI compliant methods to store credit card data for later offline manual processing: card data 'halving' (perhaps); strong encryption with proper key management (certainly).

Is this truly a legitimate practice? If the merchant attests that it is and can verify compliance to a PCI QSA if needed, then it is. If you are handling card holder data (CHD) on your network, you are fully responsible for securing that CHD to maintain PCI compliance. While these methods can be compliant, there is always the attendant effort and cost of ongoing compliance management: quarterly scans, onsite audits (if processing at certain volumes), reporting, regular penetration testing etc.

But if you and your clients' goal is to save money on transaction fees due to their preferred rates and reduce PCI scope, associated CHD handling liability, and related costs by not handling any CHD, then you should consider PCI compliant tokenization and storage service providers.

Tokenization and secure storage service providers like Auric or SecureNet specialize in secure storage of CHD for implementations like your scenario. These PCI compliant providers offer to keep sensitive CHD data is stored in secure "vaults", keeping it out of your environment completely, while providing secure access for later processing. They provide integration methods such as web service APIs using simple HTTPS posts, or embeded Iframes on a hosted payment page, to link your payment page to their service.

Pricing varies widely, but for example the Auric vault service charges $0.10 per token/month. Storing 1000 credit card tokens monthly would cost $100.00

Properly architected, this approach can significantly reduce your PCI scope and costs. Using PCI DSS validated service providers for hosting and tokenization of CHD can move much of your PCI compliance burden to already validated 3rd parties.

Rodrigo Murillo
  • 1,927
  • 11
  • 17
  • Thank you for your in depth breakdown. I'm exploring the option of using Auric or SecureNet. This sounds exactly like what I was looking for. – Originals Nov 13 '15 at 16:34
0

As per PCI DSS compliance direct storage of T1 Data is inhibited. Hence, Data Masking Solutions can be used to mask card data and temporary store the T1 Data. Also the systems that will use this masked data should be considered under the T2 scope of PCI Compliance. Instead of fragmenting the card number tokenization is better solution. As it minimizes the risk management and also a suitable PKI can be used preferably with 2048 bit key length for securely storing this Token.

Shashank Bajpai
  • 133
  • 8