Occasional orders not going into the database

I'm having an issue after transferring servers. (Linux to Windows, if that makes any difference)

When orders are completed, the order confirmation is sent successfully, but the secondary email with the missing credit card numbers is not. Worse, the order is not entered into the database. The order numbers seemed to reset as well.

Any ideas?

Zen: 1.3.7

I've also got an issue with the per item module appearing when it shouldn't, but I'll post that in the appropriate forum.

There are a number off differences in Linux vs. Win servers.

**1) **For email, you need to make sure that the "old method" you used on the Linux server (probably "sendmail" -- the default with Zen) is indeed installed on that win server and you can access it.

More than likely, the email issue could be the fact that you need to alter the program that you are using (from within the Admin) "Configuration > Email Options" and set that to the proper info yoru new Win server requires.

It may require you to set the Email Transport Method to something different than your previous server.

It may also require you to enter settings for the fields near the bottom of that same section which look like this:
SMTP Email Account Mailbox YourEmailAccountNameHere Info
SMTP Email Account Password YourPasswordHere Info
SMTP Email Mail Host mail.EnterYourDomain.com Info
SMTP Email Mail Server Port 25

2) Make sure all your directory permissions are correctly set on your new server. Setting directory permissions under Windows is different than Linux.

3) For the database issues, I am not sure if you had to move that as well. If so, make sure you moved everything from your old DB to the new one. Also, what payment gateway are you using? Is it one that requires you to set the Return URL (PayPal) and if so, did you set it properly (assuming you had not originally pointed to the "domain name" -- rather than IP etc..).

Just some thoughts to go over while you are checking it all out.

Good luck!

I'm having a similar issue... SOME orders don't make it into the database. Most do, but not all. All orders are successfully processed by Authorize.net. ZC version 1.3.7. Any ideas?

A few more details... I have ot_total enabled. If I search for an order number, I will find it, but the order is a NEW order from a different customer. For example, order #256 from customer Joe Brown comes to me via email, but doesn't show up in ZC admin. I can search for and find order #256, but the order number is simply being re-assigned to a different order--nowhere can I find Joe Brown's order in ZC admin.

The last two times this happened, the missing orders were sent to Authorize.net multiple times, like Joe had perhaps clicked the Confirm Order button multiple times. All the orders show up in Authorize, none of them show up in ZC. I'm trying to determine if this is a characteristic of ALL missing orders or just these last two.

One of the possible causes of this problem that's occurred to me is a brief blip with PHP on the server. Occasionally with this web host, PHP goes down for about 1 second. Apparently, it's a bug in the Ensim control panel software. I haven't seen this happen on this particular website, but the problem is completely sporadic and so short that it's hard to nail it down. If PHP goes down for that 1 second right when Joe submits an order... I guess that would prevent it from being saved to the database... but then wouldn't the order NOT be passed to Authorize.net?

What addons/contributions have you installed?
Have you installed and later removed any?
What customizations have you made to your site?

Well it turns out I'm an idiot. :oops:

There was an old file that wasn't overwritten and had instructions for the wrong
database on the server. Bah.

Thanks for confirming the nature of the problem.

Those old files can really bite nasty sometimes !!

DrByte:

What addons/contributions have you installed?

This site is pretty simple, just the Authorize.net payment module and the MySQL backup plugin.

Have you installed and later removed any?

About a week ago I upgraded the Authorize.net module, but this problem with occasional missing orders pre-dates that upgrade.

What customizations have you made to your site?

A custom template, but most changes are in the CSS file and images. The fact that this seems to be an intermittent problem suggests to me that the theme is probably not an issue.

I'm having a similar problem. A client of mine has had 2 orders (one on 4/30 an one on 6/20) that have processed through Authorize.net (AIM) but don't show up in the Zen Cart admin. The customer accounts show up. This client has Authorize.net set to "authorize only". There are several authorizenet_aim orders in the database before, after and in between the missing orders. There aren't any missing order numbers in the order list. The orders don't show up when I look at the orders table in phpMyAdmin.

One other key factor to note is that the authorizenet table in the database does not contain a line for these missing orders. This makes me believe that the order died while waiting for a response from Authorize.net.

I'm waiting to find out what the customer experienced on this most recent missing order. The first one, the customer said that he lost connection and just called about the order rather than hitting refresh.

Thanks for your comments, Rick! It's good to know I'm not the only one experiencing this.

I just had another order go missing: it shows up in Authorize.net, but not in ZenCart.

I'm waiting to find out what the customer experienced on this most recent missing order. The first one, the customer said that he lost connection and just called about the order rather than hitting refresh.

I find this particularly interesting because it seems that with every missing order, the user submits the order more than once--like perhaps they experienced a connection problem the first time around, so they re-submit the order.

It sure sounds like the handshake between Authorize.net and ZenCart fails. Any ideas for how to get around this issue?

I just experienced the same problem (apparently) for the first time. A customer's visa order was placed three times with Authorize.net, but the orders were not recorded by Zen Cart, but were recorded and authorized/captured by Authorize.net. I just made a test order on my own visa and had no problems.

The customer freaked out and called her credit card company and "placed a fraud alert." So I'm guessing we've not made a terribly good impression. :oops:

The store has been running for around a year (never having this problem), but I recently upgraded from 1.3.0.2 to 1.3.7.1, and I uninstalled/reinstalled the Authorize.net (AIM) module.

Any ideas? As mentioned above, it would seem that the response from Authorize.net did not make it back to Zen Cart, but will Authorize.net authorize the transaction if that happens?

Thanks,
Jason

In your authorize.net aim module settings, do you have it set to "Enable database storage"? or even debug log to file enabled? If so, then there is a chance that we may be able to determine what happened during those transaction attempts. If not, there's nothing that can be done about it.

How does your site differ from a fresh v1.3.7.1 install ?

Dr. Byte,

I believe I have identified the problem (or at least part of it). We've had the problem already repeat a couple of times, and one of the customers sent us the error message she received, which happens to be a MySQL error caused by an apostrophe in a product name.

I've temporarily fixed this in /includes/modules/payment/authorizenet_aim.php, line 463. This is just a temporary fix, and I don't recommend it for anyone!

      $db->Execute("insert into " . TABLE_AUTHORIZENET . "  (id, customer_id,order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values ('', '" . $_SESSION['customer_id'] . "', '" . $new_order_id . "', '" . $db_response_code . "', '" . $db_response_text . "', '" . $db_authorization_type . "', '" . $db_transaction_id . "', '" . print_r($reportable_submit_data, true) . "', '" . $response_list . "', '" . $order_time . "', '" . $db_session_id . "')");

the apostrophe in the product name gets put in the print_r($reportable_submit_data, true), so I just added an addslashes:

      $db->Execute("insert into " . TABLE_AUTHORIZENET . "  (id, customer_id,order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values ('', '" . $_SESSION['customer_id'] . "', '" . $new_order_id . "', '" . $db_response_code . "', '" . $db_response_text . "', '" . $db_authorization_type . "', '" . $db_transaction_id . "', '" . addslashes(print_r($reportable_submit_data, true)) . "', '" . $response_list . "', '" . $order_time . "', '" . $db_session_id . "')");

We were previously (until last week) using Zen Cart 1.3.0.2, and the $data variable was inserted into the database, which had been passed through the urlencode function, so the apostrophe was taken care of. In 1.3.7.1, the $reportable_submit_data array doesn't appear to go through any cleaning before being inserted. I see this variable being used elsewhere in the module, but I did not try to come up with a real fix, as I don't understand the code well enough.

We have a number of popular products with apostrophes, so I'm guessing that's why others have only been hit by this intermittently.

I had not made any previous mods to this file. I am using Sales Order, News & Article Management, About Us Page, Column Layout, Better Categories, and Easy Populate mods, nothing that does anything with orders. I do have the database storage on.

Thanks,
Jason

That fix should be fine.
A more comprehensive fix will be included in the updated AIM module coming in the v1.3.8 release.

Jstuff, you're my hero! What awesome timing too, because we had another occurrence of a missing order just this morning.

I do have database storage enabled.

I have one product with an apostrophe in the name, and several with a pound symbol.

I have implemented the fix, and will keep an eye on this but I'm hopeful this is a case closed.

Thanks again!!!

FYI -- here's another thread discussing similar issue:
http://www.zen-cart.com/forum/showthread.php?t=70801

I can't believe I missed that one :blush: --thanks Dr. Byte!

Jstuff

When I replace my code with your fix posted above, when checking out in the cart, at step 2 i believe, that takes you to the paymet page, i get a parse error on line 463... any ideas?

There are so many possibilities... if your file has been modified previously, your "line 463" might be in a different location than my line 463. Or maybe just some mismatched quotes... anyways, I'm no php expert... maybe the discussion that Dr. Byte mentions above may provide a better solution in your case.
:unsure:
--Jason

Does anyone know if there is a resolution for this problem. I have a customer who is having this problem and at first I though it was due to the apostophe problem, but after looking at all the orders that have this problem that wouldn't fit because they don't all have apostophes.

The orders show up in Authorize.net, but not in zencart. The orders get reused in zencart and then we end up with duplicate order numbers in Authorize.net. So we now have two customers with different orders with the same order number, but only one is in zencart.

We had previously been doing offline credit cards and haven't had this issues. We recently switched to authorize.net live orders and we had order coming in with no problem for the first day or two, then this was discovered. I did patch the site for the apostophe problem, but we are still seeing this randomly happen with orders.

Does anyone know of a fix for this problem?