Occasional orders not going into the database

[Jstuff]

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.

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

[DrByte]

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 ?

[Jstuff]

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

[DrByte]

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

[stevensmedia]

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!!!

[DrByte]

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

[Jstuff]

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

[droptest]

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?

[Jstuff]

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.

--Jason

[vmmeup]

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?