View entire CC# in Admin?

[schoolboy]

If it isn't allowed, and they get caught, they could lose the account they have.

Not only that, they could get "black-listed" and no CC merchant clearing bank will allow them to open an account.

The fact that they are a "small" (and currently PCI ignorant) retailer makes no difference. PCI compliance applies to EVERYONE taking card payments.

If they've been "doing it this way for over 10 years", then they ought to consider themselves lucky they haven't been caught by fraudsters... but tomorrow could be a different story!

[scott_see]

Not only that, they could get "black-listed" and no CC merchant clearing bank will allow them to open an account.

The fact that they are a "small" (and currently PCI ignorant) retailer makes no difference. PCI compliance applies to EVERYONE taking card payments.

If they've been "doing it this way for over 10 years", then they ought to consider themselves lucky they haven't been caught by fraudsters... but tomorrow could be a different story!

Very good points. I agree. Seems like it would be prudent to refer all ecommerce clients to the PCI Compliance web site. Perhaps that would take care of the CYA aspect of all this.

[schoolboy]

Scott... you have to protect yourself as well. If you are knowingly building a website that flouts PCI conditions, then you could be considered an "accessory" if a fraudster grabs all those card numbers and uses them to perpetrate a massive card scam.

Believe me... banks will go for everyone involved, no matter how "slight" that involvement.

Even if your client is willing to indemnify you against liability, it's not worth the risk because you (the builder of the site) actively enabled a feature that lead to a crime.

If your client has a merchant account, then they will already be paying a fee. In some cases, some banks even charge lower fees for gateway transactions. The cost of compliance is negligible, and as Merlin said earlier, "The gateway fee is part of the business" - it's an operating cost that has to be borne.

[scott_see]

Scott... you have to protect yourself as well. If you are knowingly building a website that flouts PCI conditions, then you could be considered an "accessory" if a fraudster grabs all those card numbers and uses them to perpetrate a massive card scam.

Believe me... banks will go for everyone involved, no matter how "slight" that involvement.

Even if your client is willing to indemnify you against liability, it's not worth the risk because you (the builder of the site) actively enabled a feature that lead to a crime.

If your client has a merchant account, then they will already be paying a fee. In some cases, some banks even charge lower fees for gateway transactions. The cost of compliance is negligible, and as Merlin said earlier, "The gateway fee is part of the business" - it's an operating cost that has to be borne.

All I know is that they're using Zen Cart, and that presently captures part of the credit card info and emails the rest. That's the beginning and the end of what I know.

[DrByte]

All I know is that they're using Zen Cart, and that presently captures part of the credit card info and emails the rest. That's the beginning and the end of what I know.

It's worth noting that the next version of Zen Cart WILL NOT include the module that is causing you these questions/confusion.

In the meantime, this FAQ article explains how that basic offline card module works: https://www.zen-cart.com/tutorials/index.php?article=67

[steele]

I have had problems of this very nature with clients. The basic credit card module puts a burden on the merchant and makes things less secure.

1) Zen-Cart is not used by Wal-Mart, or Ford or Coke. It is used by small merchants whose profit margin is low and for many of them, the fees of a payment gateway would negate any profits. These merchants do things by hand to save money.

2) The FAQ page states that PCI DSS regulations and the merchant account TOS prohibit storing all digits of the credit card. This is absolutely false. The PCI DSS regulations state that a credit card number must be handled securely, stored securely and presented to the customer only partially (it allows for the first and last few digits upon PRESENTATION). The earlier drafts of the PCI DSS stipulated that credit card numbers be stored encrypted, but that was removed and is no longer a requirement (but I recommend doing so, nonetheless).

https://www.pcisecuritystandards.org.../pci_dss.shtml

Storing credit cards is allowed by the PCI DSS. The merchant is compliant if they do so and have proper controls in place to protect that information. That, of course is no guarantee that they won't get sued if there is a hack, but it provides a strong defense. Consider that the PCI DSS regulations also state that ALL customer data be protected, not just credit card numbers. Zen-Cart does nothing to protect the rest of the customer data. The merchant can still be sued if there is a hack and personal information about customers is stolen, even if that information does not include credit card numbers.

3) By splitting up the number, you are forcing the merchant to do extra work. People do not like doing extra work (humans are lazy by nature) and what they are going to do is A) print out the order (with XXXX'd out digits), then go to their email and WRITE in the missing digits on the order printout, in order to make sure they do not make a mistake when entering the number. You have then defeated the purpose of splitting up the number.

4) Email, is by its very nature and by definition, unreliable. People generally forget this because in most cases, email is reliable. However, network outages, server problems, spam filters and so on can interfere with email delivery. By using a non-secure and unreliable method of transferring part of the credit card number, you have made the process less secure, not more so. In addition, it leads to all sorts of problems, when the email gets deleted, or never arrives.


A much better solution would be to store the entire number, but encrypted. Encrypt it with Public Key encryption, such as RSA or Diffie-Hellman. A public key and private key are generated. The public key is used to encrypt the data which can only be decrypted with the private key. In order for the system to present the credit card number to the merchant, it needs the private key, which must be stored on the server. How to protect this private key from hackers??? Encrypt it with standard symmetric encryption, such as Rijhdahl (AES). The merchant puts in their password, which the system uses to decrypt the private key in memory and then decrypt the credit card number.

Why the extra encryption step? Why not just have the system encrypt the credit card directly with symmetric encryption? Because, that would require storing the password on the server so the system could ENCRYPT the credit card number when the order is placed. The above method (public key encryption with symmetrically encrypted private key) means that even with access to every bit on the hard drive, a hacker would not have enough information to decrypt the credit card number.

As it is now, I have to tell clients that lost an email or never received it, that they are out of luck and have to call the customer to get the credit card again. That makes them look like a Mickey Mouse organization and in turn, it makes me look that way too for choosing a system like Zen-Cart for them.

As a result, I have to stop using Zen-Cart for customers until this issue is fixed, which is too bad, because, otherwise, Zen-Cart is a great system.

BTW, I have not run into any other cart system that mis-handles credit card numbers in this way.

[stevesh]

It is used by small merchants whose profit margin is low and for many of them, the fees of a payment gateway would negate any profits. These merchants do things by hand to save money.

I can't reasonably reply to all the points made in your post, but I'll certainly tackle this one.

If ~$40 a month is real money to youir 'business' and negates all your profits, you're not a businessperson, you're a hobbyist. Nothing wrong with that, but my usual advice to those who 'can't afford' a real merchant account (or won't use Paypal) is to get a part-time job and save up a year's worth of basic expenses (hosting and CC processing fees, pretty much) and then open your store with the idea that you'll be making money by the time your savings run out.

#4, as well explained as it is, doesn't address in any way the issues I raised in post #4 of this thread. Encryption or not, sooner or later the site owner has all my CC info in clear text.

[DrByte]

steele,
There's a flaw in your logic:
Comparing your point #3:

3) By splitting up the number, you are forcing the merchant to do extra work. People do not like doing extra work (humans are lazy by nature) and what they are going to do is A) print out the order (with XXXX'd out digits), then go to their email and WRITE in the missing digits on the order printout, in order to make sure they do not make a mistake when entering the number. You have then defeated the purpose of splitting up the number.

... with your so-called "better solution":

A much better solution would be to store the entire number, but encrypted. Encrypt it with Public Key encryption, such as RSA or Diffie-Hellman. A public key and private key are generated. The public key is used to encrypt the data which can only be decrypted with the private key. In order for the system to present the credit card number to the merchant, it needs the private key, which must be stored on the server. How to protect this private key from hackers??? Encrypt it with standard symmetric encryption, such as Rijhdahl (AES). The merchant puts in their password, which the system uses to decrypt the private key in memory and then decrypt the credit card number.

... still results in a major problem: even though you've gone to all the trouble of encrypting, your admin users are STILL going to WRITE DOWN the numbers somewhere ... (and that's AFTER they have to type in another special password that they hopefully don't have written on a post-it note attached to their monitors!!) and then all your hard work on "security" is out the window again ... not to mention the PCI problems you started with.

The basic credit card module puts a burden on the merchant and makes things less secure.

I'm with stevesh on this one.
If that module isn't desirable ... don't use it.
Use a live processing gateway instead, and then all the other headaches you are ranting about will quickly and securely go away ...

In fact, you can breathe a deep sigh of relief knowing that the problems of the basic credit card module are gone in Zen Cart v2.0 ... because that module is not even included in it. No more need for your clients to tell you that you look bad because you made them use something that makes them do extra work!

[steele]

Merchants need not necessarily write down the number at all. These days, a physical terminal is used more and more only for physical brick and mortar stores. Increasingly, at home, merchants use virtual terminals.

They can open the order, highlight, copy and paste the number into their virtual terminal and never have to write down the number at all. If you split it into multiple pieces that travel different routes, they cannot do this - not easily.

Zen-Cart is the only cart that I am aware of that handles credit card numbers this way. Many other carts let you process charges manually and yet they are PCI compliant.

[DrByte]

LOL. I suppose maybe they are. But, "many other carts" are incapable of numerous other things.
No matter. This isn't intended to be an argument. Pick the tool you prefer, and enjoy it!