Split credit card info - question

I've done some searching and nobody seems to have mentioned this particular issue before, so I'm a bit confused :dontgetit
For each order I get an email called [NEW ORDER] which contains the outer CC info like this 4111XXXXXXXX1111. This is the copy of the confirmation email sent to the customer, right?
Then I get an email called [EXTRA CC ORDER info] which contains the remaining middle digits.
I thought the reason for splitting the CC number in this way is to prevent either the database keeping the full number OR the full number being transmitted via email?

Maybe read this article. It states:

WHY do we split the CC number up like this?
Your merchant's Terms of Service (TOS) will be very clear that you're not allowed to store customer credit card numbers in a retrieval system, and that if you do and your system is hacked and your customer's CC info is stolen and used fraudulently, YOU will be liable for all unauthorized purchases made with those CC numbers. Hence, to protect you and your customers, the full numbers are not stored in Zen Cart, but are split up into 2 separate mechanisms for safety, but still simple to use.

Yes I've read that - I know why the card info **is **split, what I can't understand is that your email delivery system which is inherently weaker than zencart is somehow okay to send the **whole **info whereas the database isn't! I was under the impression that **half **of the info got delivered via email and **half **stayed in the database, meaning that you couldn't get the whole number without access to both.

travellers:

what I can't understand is that your email delivery system which is inherently weaker than zencart is somehow okay to send the **whole **info .

It sends both parts in separate emails, so the whole is never in the same place at the same time. In order to get the whole a hacker would still need to gather the information from two separate sources, whether this is two emails or one email and one database entry, or perhaps two database entries isn't important.. the fact is the whole is never availalbe in the same place at the same time.

Yes, it is true that email is inherently insecure, but the way the internet works, there is also a very good chance that two emails from a given source to a given destination will take two different paths, making difficult (if not impossible) for the whole to be obtained via packet sniffing techniques.

Cheers
Rod

okay, thanks for that.

And ... if you configure the module to actually send the second email to a DIFFERENT address, then it'll naturally be more secure. Using the same email address as order confirmations is ... foolish.

DrByte:

And ... if you configure the module to actually send the second email to a DIFFERENT address, then it'll naturally be more secure. Using the same email address as order confirmations is ... foolish.

How disappointing then that that advice isn't within the Guide. Or the book, for that matter... :P

I figured common sense would suffice. I don't know why we even bother writing help text or instructions or FAQs ... most people don't read them or just ignore the advice in them anyway.

It's no big deal ... that module is being removed from all future versions of Zen Cart, so all of your issues above won't be an issue anymore. It's WAY safer to use a real gateway, and WAY more PCI/DSS compliant.

DrByte:

I figured common sense would suffice. I don't know why we even bother writing help text or instructions or FAQs ... most people don't read them or just ignore the advice in them anyway.
Ah I dont know about that - I think most people considering e-commerce are at least going to read the FAQs. I certainly do. And I've half **memorised **that :censored: book :D
DrByte:

It's no big deal ... that module is being removed from all future versions of Zen Cart, so all of your issues above won't be an issue anymore. It's WAY safer to use a real gateway, and WAY more PCI/DSS compliant.
Woah! Zen's going to remove the ability to take credit cards directly? Why? So now merchants like me who have a POS terminal to transfer orders into have to use a gateway and pay them a commission!

travellers:

Woah! Zen's going to remove the ability to take credit cards directly? Why?There are serious PCI liability risks in handling the data the way that module does, plus 95% of new users think that just using that module is enough and don't have a clue about the need for a POS or merchant account; thus we're removing it.

If you want to assume the responsibility for the security of the data, you're certainly welcome to use an addon that can collect the CC details so you can process them offline. There's already at least one such addon in the downloads area, which will probably get more attention when that time comes.

Sorry, "pci" liability? Ummmm, que?
Okay lets cut to the chase. We have a POS terminal, for the existing non-virtual shop, so it makes sense (all else being equal) to use the same method for sales on the online shop. Of course, all else isn't equal, since the building rarely suffers from some oik trying to look over your shoulder as you type in the number. Well, this **is **a remote Scottish island!
So yup, the ideal scenario is a gateway that doesn't snaffle all the profit - is there such a thing? - but the method of doing that is one of the less well covered Zen questions. The method of actually **configuring **zen isn't tough, but how to set it up with the bank might as well be brain surgery. Off-mainland banks still look at **chequebooks **as "those new-fangled things" :smartalec:

travellers:

Ah I dont know about that - I think most people considering e-commerce are at least going to read the FAQs. I certainly do. And I've half **memorised **that :censored: book :D

I'm with DrByte on this one. If people read the FAQ's, I suspect that at least 80% of the questions being asked in these forums wouldn't exist.

For reasons I've never been able to comprehend, most people seem to think that their questions/problems are so 'unique' that they deserve 'personal attention' and head straight to the forum with a 'please help' message rather than reading the FAQ's

Many (most?) of the more knowledgeable forum participants (including DrByte and the rest of the dev team) happily oblige with forum responses, all in the name of 'support', even though the same answers can be found elsewhere.

Just occasionally we tend to forgo this personal touch and simply supply a link back to the FAQ's or previous Forum posts.

Cheers
Rod.

ps. I have no statistical data to support my observations, just many years of experience in customer support.

travellers:

Sorry, "pci" liability? Ummmm, que?
Okay lets cut to the chase. We have a POS terminal, for the existing non-virtual shop, so it makes sense (all else being equal) to use the same method for sales on the online shop.
And, that's probably just fine.
The risk you run is that you're emailing credit card details, and email is inherently insecure, and almost always plain-text.
Until recently you were sending those emails all to one email address ... so ... all anyone needed to do was intercept the emails being sent to you, and they'd have all the info they needed to mount fraud attempts. Actually, they wouldn't even need to intercept ... just "sniff" by monitoring internet packets as they go by. Pretty easy to do, and commonly done by folks who want to commit fraud.
At least now you're separating the emails so they're going to different destinations ... hopefully even different servers/domains. That doesn't solve everything, but certainly shows a measure of diligence in protecting the data.
Whether you would pass a PCI security audit is uncertain.
As long as nobody commits fraud with any data gained from transactions originating on your store, you'll probably get away with what you've got. And, many do. But there's a huge initiative underway to crack down on insecure systems, and you're likely to receive a note from your merchant bank one day asking you about your website, and requesting a security audit. They may or may not like what they see. That's up to you. At that time they might push you to a live gateway and the service charges you're luckily avoiding right now. Or they may not.

So ... that's the long way of saying what I've tried to say earlier.

RodG:

I'm with DrByte on this one. If people read the FAQ's, I suspect that at least 80% of the questions being asked in these forums wouldn't exist.
Hmmm, yeah, guilty as charged. What have I got - 120ish posts? Probably 25 of them then that are 'stooopid' questions that have been asked countless times before. In fairness, I've answered some others too!
Thing is there, at least for me, is that the physical book is a great resource, but it lacks a search facility - you can't simply put your finger on the page that details what you need. And running a search here gives the opposite result - you're completely **overwhelmed **with responses, which makes finding the one with the answer you're looking for like finding a needle in a haystack. Maybe, and I'm talking off the top of my head, the fine people answering these 'newbie' questions are actually **adding **to the problem rather than curing it, by sanctioning multiple threads with the same answer. Perhaps a better way would be to 'move' the question into the 'one true thread' (TM) for that particular question!
Sorry, that's not intended as any form of criticism of either the book **or **the forum - I use both extensively and think they're fabulous resources, and I've shown my appreciation monetarily to both.
DrByte:

At least now you're separating the emails so they're going to different destinations ... hopefully even different servers/domains. That doesn't solve everything, but certainly shows a measure of diligence in protecting the data.
Whether you would pass a PCI security audit is uncertain.
Thank you for the expanded answer - it was very useful. The two emails now jet off to different destinations, avoiding the potential issue you referred to. Now though, the question is, why does the second email contain the outer digits which can already be found in the database? What I'm thinking about now is, can I strip the part of the email template that displays the outer digits, thus preventing that leak potential, and let the receiver of the order just get that info from the db once he's logged in?

travellers:

Maybe, and I'm talking off the top of my head, the fine people answering these 'newbie' questions are actually **adding **to the problem rather than curing it, by sanctioning multiple threads with the same answer. Perhaps a better way would be to 'move' the question into the 'one true thread' (TM) for that particular question!
Sorry, that's not intended as any form of criticism of either the book **or **the forum - I use both extensively and think they're fabulous resources, and I've shown my appreciation monetarily to both.

Critisism or not, you do have a very valid point ... doubly so when I know that I have on (hopefully rare) occasions attempted to help people with issues only to find out later that my responses haven't always been as accurate as they could have been if I'd (re)read the FAQ's before responding.

On the other side of the coin though many of my responses are to questions that wouldn't/couldn't be found in the FAQ files because they have referred to very specific customizations that would be outright confusing to everyone else if they were in a FAQ file.

There is also the social and personal aspect to it as well, I'm sure that many people are attracted to zencart because they know they can ask questions in the forums without being made to feel like they are total idiots. This is in steep contrast to other forums/sites where newbie questions are frowned upon and they are simply told to 'read the FAQ's and get little or no other support.

Personally I think we have a pretty good balance here... the FAQ's are available to those that like to 'go it alone', and the forums add that 'personal touch'

The moderators also do a pretty darn good job of keeping the forums clean of spam, they are efficient at correcting misinformation when it does occur, and know when to step in on those odd occasions where personality clashes start to escalate into 'flame wars' (These observation are all based on personal experience).

Cheers
Rod

Just to finalise on this, can anyone point me to the relevant chunk of which particular php file I'd need to copy across so that I can add text entered by the customer in the 'Comments' box to the [EXTRA CC INFO] email?

The customer comments are included on the order-confirmation email, and thus are not needed or relevant to the CC middle-digits email.

DrByte:

The customer comments are included on the order-confirmation email, and thus are not needed or relevant to the CC middle-digits email.

As per the advice further up the thread, the store no longer receives a copy of the order confirmation email. This prevents the security issue we talked about further up the thread where the whole cc number arrived in two emails. However, now that the store doesn't get that email, the only way the person who makes the order up gets to see any comments is to click the Invoice button on the order page, and scroll to the foot. It seems to make logical sense, then, to add the comments to the one email the order taker DOES receive, i.e. the one with the middle digits in it.
All I'm looking for is to copy the element of the order confirmation email that deals with customer comments, and add it to the EXTRA CC INFO email. Looks like a logical idea to me!

I think you've done it backwards.

It would be more logical that the one email that the order taker DOES receive would be the order-confirmation email, which includes the products ordered, and the customers' comments.

And, your accounting person would receive the middle-digits so they can log in and process payment for the order.

The order taker/filler and the accounts department are....errr....the same person. This isn't Thorntons you know, it's a little shop! That person receives the EXTRA CC email (because that's the only place the middle digits are available). As per this thread, he doesn't get the order confirmation mail with the remaining digits, but the casualty of this is that the customer comments have now got a bit lost.