View entire CC# in Admin?

[stevesh]

You might also want to find out what their current CC merchant account provider thinks of them manually entering Internet transactions. I've never seen one who allows it without changing to a different type of account. If it isn't allowed, and they get caught, they could lose the account they have.

[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.