Duplicate Orders Authorize.net AIM

Is there still a bug with duplicate orders in Authorize.net AIM payment module?
Lately I've seen duplicate and triplicate orders with the same order number. In one case the same customer submitted 3 times, resulting in 3 charges. For this case my guess would be that they have javascript disabled and therefore the submit_once function can't stop multiple clicks.

But just a couple of days ago one customer had 2 submissions and charges with the same order id. Then another customer recieved the same order id and was charged as well. The first 2 submissions show up in authorize but in ZC the order has been overwritten by the 3rd submission.

We are using ver. 1.3.7. I did remove and reinstall the authorize AIM module. I also patched the paypal IPN module.

I also noticed authorize transactions are not being saved to the database even though it is enabled. It was until I upgraded. How do you set up file logging? I enabled it but I must need to create a file for it to work?

I've not seen any duplicate-order issues with the v1.3.7 version of the Authorize.Net payment module.
There have been reports in the past with prior versions, but I haven't seen any in a long time.

Also, you can set your Authorize.net account settings (in your merchant profile section of the authnet website) to prevent repeat transactions during a certain timeframe. Perhaps you need to enable that option or increase the timeframe?
How far apart were these charges?

It also begs "why" are the duplicates occurring? You mentioned javascript issues -- those could be problems in your upgraded template.

It could also be related to slow communication between your server and the authorize.net server. Perhaps your host server was running a little slow at that particular time. The speed of communication wouldn't explain why this started happening only after your upgrade though.

Authnet debug logging puts files in the /cache folder if it's writable. (chmod 777)

I am having this same problem. Duplicate/triplicate payments from differenty people (all under the same order number 878) but only one customer's order in the admin area. I read the forums for many hours and I see this has happened to a lot of people. The only solutions I could find were EONG (external Order Number Generator) which appears to have been replaced with Super Orders 2.0.:frusty: Will that work?

David

Hate to add a "me too" to this, but "me too!". Client's authorize.net report shows order id# 504 as having been approved 3 times, twice for one customer (same order for cust #206) and once for different customer (cust #207). The orders table shows that order #504 was assigned to cust #207 (the second customer), the customer_basket table shows that the first customer (#206) still has her order in her basket (i.e. did not successfully check out), and the authorize table only shows the second customer's order as approved and no records at all for the first customer.

This is the second time we have found this type of error, and results were almost identical - first customer charged twice according to authorize.net (but cart's authorize table shows transaction was declined and order still in basket) while second customer charged once and all cart records show successful transaction.

We have Super Orders module installed, if that could have any effect on this. Any ideas how/why this is happening and, of course, best way to fix it? The client wants to blame this on Zen Cart ("That's what you get for "free"!), but I've convinced him (so far at least) that it's an integration or communication glitch between Zen Cart and Authorize.net, and we just need to find it and correct it.

He's going to add me to his authorize.net account today so I can access his account details and talk to their support people. Any guidance on what to look for and what to ask?

Thanks!

If the issue is with high traffic levels and concurrent order-placing, then you'll likely have to use the external order number generator approach or something like it.
http://www.zen-cart.com/forum/showthread.php?t=70686
Something akin to this will be built-in during the Checkout-Rewrite stage in a future version of Zen Cart.

If you are getting duplicates during low-traffic times then it would suggest something else awry with your site configuration causing the database to be unable to determine an order number for submission in the transaction.

Thanks, Doc, I think that mod might be just the ticket (although I tend to be an optimist!). I'll let you know if problems continue or if I can now get on with a couple day's R&R working on my old boat.

Thanks again for the quick and productive response.

The External Order ID Generator mod installed without a hitch, and all looks good so far. But now I need to decipher the orders in "customers_basket" to determine which were indeed charged by Authorize.net. I think I have it all figured out except for one question:

I need to actually read the text in the "products_value_options_text" field of the "customers_basket_attributes" table. This is a BLOB field - can I change it to a TEXT field and can I do this while users are online, or do I need to go into Maintenance mode?

Thanks!

you can change it at will

Great! Thanks and have a wonderful weekend.