Lost Credit Card Numbers! (1.3.5 - 1.3.6)

I've just upgraded from 1.3.5 (fresh install) to 1.3.6. Everything seemed to work fine until order begain to come it. The middle 8 digits of the credits cards are no longer being emailed to me!

First of all I can rule out any server issues as I own private servers (and have tested them and the email server is working fine).

Now, I'm going to try uninstalling the payment module and then reinstalling it (I've read that this might help - somewhere else).

Failing that, is there anyone else with the same problem as me? Or does anyone else know of a solution?

Thanks.

Reinstalling the payment module (as I mentioned in my previous post) did not resolve my issue.

Anyone have any ideas?

Further investigation has revealed that any email sent from my Zen Cart admin section is not even being passed to my mail server. :|

This includes, order update/confirmation emails, extra cc info emails (containing the middle 8 digits of credit card numbers) and any email sent from Tools | Send Email.

I have made no changes to my mail server and everything was running fine before the 1.3.5 - 1.3.6 update.

Does anyone know of a fix for this problem?

Thanks.

Ok, I've fixed it.

The solution was to change the Email Transport Method to 'PHP' as mentioned in the follower thread.

http://www.zen-cart.com/forum/showthread.php?t=52501&highlight=emails

Just follow DrByte's instructions in post 3.

http://www.zen-cart.com/forum/showpost.php?p=299344&postcount=3

I'm having a similar but sporadic problem with version 1.3.6's credit card payment module. Every now and then (perhaps every hundred orders or so), I won't receive the e-mail notificiation of the order at all. It will show up in the Administrative side of Zen Cart, but the two e-mails (one notifying, the other with the middle 8 cc# digits) will never arrive. It happened again last Friday and then again this Monday morning, within ten to fifteen orders of each other. Is this a bug or does anyone have any enlightenment they can offer? It's embarrassing to have to call the customer up for the middle 8-digit cc# info, and they are suspicious of giving it out again. Help!

Redradar:

Is this a bug or does anyone have any enlightenment they can offer? It's embarrassing to have to call the customer up for the middle 8-digit cc# info, and they are suspicious of giving it out again. Help!

It's not a bug. The email is always generated and sent to the mailserver for delivery. Since the email is small and short, some mailservers flag it as spam and either drop it into a black hole or send it on with warnings. Sometimes the receiving server may re-filter it as spam or drop it into trash without ever delivering it.
You might try making the subject line of those emails longer and ensuring there are no repeated capital letters in it. You might also alter the text content of the message to contain a longer body so that it's less likely to be flagged.

DrByte:

It's not a bug. The email is always generated and sent to the mailserver for delivery. Since the email is small and short, some mailservers flag it as spam and either drop it into a black hole or send it on with warnings. Sometimes the receiving server may re-filter it as spam or drop it into trash without ever delivering it.
You might try making the subject line of those emails longer and ensuring there are no repeated capital letters in it. You might also alter the text content of the message to contain a longer body so that it's less likely to be flagged.
It's not just the short e-mails with the 8-digit cc#. It's the large e-mails with the orders on them, too; the most recent drop was a large order with several items on it. Neither of the two e-mails arrived. The only way the order showed up was in the administrative area of Zen Cart. At the same time, we get other shorter orders with less items in them with no problem. Sometimes we receive the shorter 8-digit e-mail but not the longer order e-mail -- this I can live with because the rest of the information can be found in the administrative area. But when neither of the e-mails turn up or when the 8-digit cc# e-mail is missing it's a real problem. I will speak with our ISP's customer service to be sure they're not flagging these e-mails, but I am concerned that, due to the large size of some of the e-mails that are not showing up, the problem could be due to something other than spam flagging/filtering. It's now happened 5 times out of 489 orders total.

DrByte:

It's not a bug. The email is always generated and sent to the mailserver for delivery. Since the email is small and short, some mailservers flag it as spam and either drop it into a black hole or send it on with warnings. Sometimes the receiving server may re-filter it as spam or drop it into trash without ever delivering it.
You might try making the subject line of those emails longer and ensuring there are no repeated capital letters in it. You might also alter the text content of the message to contain a longer body so that it's less likely to be flagged.
I was able to get our server to retrieve some of the missing e-mails. But in one case that happened just a couple of days ago, we didn't receive any of the e-mails regarding an order. The only way we knew we had that order was that it showed up in Admin. The e-mails were unretrievable. I was wondering aloud to support staff if perhaps the client's server, Earthlink, had deleted both e-mails as SPAM before they got to our server. Our ISP's Customer Service had this to say about that theory, FYI:

"It's unlikely that the emails would have been deleted as spam. However, it's possible that the emails Zen Cart is sending out do not use the customer's address as the envelope sender but something else, e.g. the user the webserver runs as. (I did check the webserver user's mailbox but it does not include any bounce messages that correspond to your site.)"

These missing e-mails continue to be a HUGE problem for us. We are missing the order e-mails about 20 percent of the time. Last week we had four orders in a row that came up missing all the e-mails. Our ISP could not retrieve any of them at all. Yesterday we had another two; today we had another one. When you consider that we generally get about ten orders a day this has turned into a huge headache. If the orders are from old customers, sometimes we can find the information we need from previous invoices, but in the case of new customers we can do nothing more than contact them to ask them for their credit card information again. Half of the time they are so suspicious of the request that they refuse to follow up and we lose the order.

Please, please, please can this problem be somehow remedied on a future version of Zen Cart or can this function be set up to send ALL the infomation into the administrative area, instead of half of it? Dividing up this information is not helping us security-wise, since in a substantial number of cases we never receive any e-mails regarding an order at all.

Question- If you are running that many orders a day, why are you processing them manually instead of using a gateway that would eliminate the headache?

Kim:

Question- If you are running that many orders a day, why are you processing them manually instead of using a gateway that would eliminate the headache?
Because we sell over 1,200 products and charge the client's credit card only when we're ready to ship. Some items are drop-shipped and we often find out only after an order is in that something is out of stock, discontinued, due in a week, etc. Also, we ship a considerable number of international orders to which the shipping charges have to be computed separately and added to the total after the order is assembled. The gateway requires that all orders be resolved within a 24-hour time period (or within some time-limited period -- even 3 days is too short for some of the obstacles we encounter in filling certain orders); that is unrealistic for our business' purposes. If the order is not filled within the gateway's resolution window, it would lapse and the client would have to re-enter their order -- good luck on getting them to do that. We would lose a lot of business using a gateway so unfortunately it's not right for us. We need the flexibility to charge the client's card when we have the order ready to ship.

You can set up a gateway so that it only authorizes the card and doesn't process it until you tell it to. :) Just depends on the company you are dealing with.

are the middle eight digits stored anywhere within the db as to avoid calling the customer for them?
thanks :)

Not as far as I know.

The whole point is that the entire card number is not stored in the database (for security reasons).

However, I maybe wrong. If so, someone please correct me! :P