View entire CC# in Admin?

This has been asked a few times, I believe, but nobody seems to have an answer.

My client does not want to pay for a processor, instead she wants customers to put in their CC# and then she will manually process it herself (with her CC machine) and mark the order PROCESSED herself once the charge goes through.

This is not smart. It's stupid and dangerous... I know that.

BUT it's what she wants because she does not want to pay processing fees.

I have set up her payment module as credit card (cc). Just a standard setup. BUT new orders, in admin, are XXXX for certain numbers.

I know processors hide this information for protection but she does not have a processor and needs to see it. Can this be done?

I just noticed this problem looking at admin, seconds ago.

I know this is a security issue, but I've used Cs-Cart before and they post the whole CC# because sometimes the card fails and I'll charge it again without having to call the customer back to get the card.

No. The numbers that are XX'd out in admin are sent to you in an email when the order is confirmed.

It looks like you have a good handle on how horribly insecure this method is, and I'm sure you've tried to educate your client.

I'm not sure if site designers would have any legal responsibility if something went wrong, but I wouldn't work on a site like this, nor would I buy from one.

Okay, I'm sure this is a stupid question, but...

If part of the credit card number is emailed, and the other part of the credit card number is viewable in /admin/, that sounds pretty secure to me. What am I missing?

Thanks,

My issue with manual credit card processing from a website is that the owners/operators of that site, and their employees, and their kids, if they work from home, and their kid's friends, and the office cleaning people, and any passer-by who wanted to scrounge through their trash, if they don't shred the scrap paper they wrote my CC info on, could end up with my card number and expiration date.

Unprofessional, in my opinion. Yes, I know the card I gave the restaurant server was out of my sight for 5 minutes, and could have been copied multiple times. The difference is that, unless I want to wait and pay on the way out, the restaurant doesn't really have any options, save installing CC readers at every table.

Internet merchants do have options - proper online payment processing is cheap, considering you're laying off almost all of the risk.

Ask your client if they are willing to pay the settlements that their clients will win if their database is compromised.

the gateway fee is a part of business,
if they dont want to pay this fee I would suggest that they only use paypal ( wait theres a fee for that ) or checks and money orders

I realize this sounds harsh, but part of your job as the developer is to educate the client....
the old adage that the customer is always right, dosnt apply to all industries, and this is one of those times.....

We'd decline any project that stipulated full CC numbers need to be captured. One tiny security slip, and you're in line for a joint liability suit from the bank involved. If you have unlimited cash (like a recent Euromillions win) steer clear of doing this!

stevesh:

My issue with manual credit card processing from a website is that the owners/operators of that site, and their employees, and their kids, if they work from home, and their kid's friends, and the office cleaning people, and any passer-by who wanted to scrounge through their trash, if they don't shred the scrap paper they wrote my CC info on, could end up with my card number and expiration date.

Unprofessional, in my opinion. Yes, I know the card I gave the restaurant server was out of my sight for 5 minutes, and could have been copied multiple times. The difference is that, unless I want to wait and pay on the way out, the restaurant doesn't really have any options, save installing CC readers at every table.

Internet merchants do have options - proper online payment processing is cheap, considering you're laying off almost all of the risk.

Good points. I'll be sure to talk with them about this. I'll advise them not to print out the email with the missing credit card numbers. No need to, really.

Is your client aware of PCI compliance?

schoolboy:

Is your client aware of PCI compliance?

They're a small retailer. I'm sure they know you're not supposed to give other people's credit card info to strangers, but I'm sure if you posed your question to them, you'd get a blank look. Don't forget, they're a small retailer. We're not talking about a Fortune 500 corporation. They've been accepting credit cards for nearly a decade, and they're still in business.

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.

stevesh:

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!

schoolboy:

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.

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.

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.

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.

scott_see:

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

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/security_standards/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.

steele:

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.

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

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":> steele:

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.

steele:

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!

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.

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!