duplicate orders in authorize AIM

Today i found that I have a dupliecate order from the same client in authorize.net 4 times ( two with id and other 2 with other xxxx514 and xxx515 ) but no order in zen, the orders are separated +- 20 minutes between them, and another order with the same id but from another customer appear in authorize.net and zen . finally when i enter the client account the product is still in his basket, any idea?

Thanks

You could try installing the attached module update which prevents duplicate order numbers from being sent to Authorize.net.

You'll need to write down all your current AIM module settings, then Remove the module. Then upload the new files. Then re-Install in the Admin, and re-enter your module settings including transaction key.

There's a new field for MD5 Hash. If you want to use it, you'll need to set an MD5 hash 'phrase' in your Authorize.net merchant account settings. Then enter that same phrase in your Zen Cart AIM module settings. It's just an extra layer of security. If you don't use it, just leave it blank on both ends.

The following code is built-in to v1.3.8, along with additional improvements.

thanks for the reply, i'll give it a try

Dr. Byte,

Is this updated Authorize.net AIM module compatible with 1.2.x?

afx114:

Dr. Byte,

Is this updated Authorize.net AIM module compatible with 1.2.x?

No. There are dependencies in it which require v1.3.x in order to work.

in case someone comes across this thread. i had the problem and just changed to use the Authorize.net AIM module instead of SIM and it works fine in v1.3.8

Hi,

I'm using 1.38 with authorize AIM. and i'm getting duplicate orders with unique ID's, but same checkout time.

Does the Sept AIM update apply to the 1.38 module as well?

Thanks in advance.

pensive612:

Hi,

I'm using 1.38 with authorize AIM. and i'm getting duplicate orders with unique ID's, but same checkout time.

Does the Sept AIM update apply to the 1.38 module as well?

Thanks in advance.

The posted AIM patch is already built-in to v1.3.8.

Is your site an upgrade from a prior version?
Are you sure that the authorizenet_aim.php payment module file got updated to the 1.3.8 version?

Thanks for you response Dr. Byte.

I had a feeling it was already updated. It is a fresh 1.38 install.

I followed anothers advice and switched the session cache to file. So far so good!

I will post if that turns out to not work...

Thanks again for your time.

Okay. So I'm extra baffled.

I switched the cache method to file in my configure.php file.

I ran fix_cache_key.php to double check my settings. (files are being written there)

Works great on Firefox. But on IE. The 'confirm purchase' link takes them to an empty shopping cart!

i've tested it a 100 times. and switching back to db sessions is the only thing that affects it.

Dr. Byte, any ideas?

Thanks again, so much.

I think I found the answer.

In Configuration>Sessions

I needed to have Recreate Session to false.

Apparently for me, IE7 is getting errors with it set to true.

Seems to work so far.

Hope that helps someone in the future.

pensive612:

I switched the cache method to file in my configure.php file.

I ran fix_cache_key.php to double check my settings. (files are being written there)

Works great on Firefox. But on IE. The 'confirm purchase' link takes them to an empty shopping cart!

i've tested it a 100 times. and switching back to db sessions is the only thing that affects it.

pensive612:

I think I found the answer.

In Configuration>Sessions

I needed to have Recreate Session to false.

Apparently for me, IE7 is getting errors with it set to true.Those will be issues specific to your server.
Indeed, disabling Recreate Session is dangerous, in that it allows visitors to your site to potentially hijack other customers' shopping sessions. However, some hosting companies configure their servers in such a way that turning off Recreate Session is the only way to make things operate at all. IMO they're foolish to do so, but as long as people keep paying them money to host there, the problems will perpetuate.

But, now we are digressing from the topic at hand.

Hi Dr. Byte.

You are definitely right about not Recreating Sessions, and thanks for the advice. I've since switched back to db with Recreate Sessions enabled.

This was thanks to a great post from paulm about a 'submit once' fix he made. and so far, it seems to have fixed the problem.

Have you by any chance seen his fix? I wonder if it might be incorporated into the code later on?

Thanks again for your time.

Howdy, all.

I'll just jump right into my question. Non-techy type here, but I've been doing my due-dilligence trying to read before posting.

Here's the scoop on why I'm jumping in.

I'm running version 1.3.7, and using authorize.net. I'm getting this infamous 1064 error, it seems when an apostrophe is used in the product title and/or when an apostrophe is in customers name or address.

I was unable to find my 'exact' error on the boards and since I'm a little trepid to just start attacking the issue without at least asking, thought I'd share the error and get some input/advice.

I created a test customer and forced the error by adding an apostrophe in the customer's name.

Here's what that yielded;

1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's Cunningham [x_address] => 1234 Grandstand's Blvd. [x_city] => Nashvill' at line 1
in:
[insert into authorizenet (id, customer_id,order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values

The error went on longer, but I wasn't certain if that info was secure info for public showing.

Any guidance is greatly appreciated. Thanks a ton!

Upgrading to v1.3.9 will solve that problem.

DrByte:

Upgrading to v1.3.9 will solve that problem.

Thanks for your response, DrByte! I really appreciate it. While this is the the best solution, with fall/Christmas being our biggest time of the year, I'm at a major crunch for time until early 2011. I did look into what it takes to upgrade and I fear that it may be a larger job than I have time (I have a few addons and have had a nice cron job built for the site. Don't want to mess those up during the holiday season).

In the meantime, is there a simpler solution to mend the apostrophe / 1064 issue (the one specific to my post above)? Then early 2011 I can begin the upgrade process.

Again, thanks for your time. I appreciate it.

Cris

Did you try the patch posted above?

I haven't looked at 1.3.7 in so long I forget what it looks like :blush:

DrByte:

Did you try the patch posted above?

I haven't looked at 1.3.7 in so long I forget what it looks like :blush:

Ha! Sorry, I'm outdated here. I really do need to upgrade and have been aware for some time.

I was a bit confused if the patch above was suitable to my issue so I didn't attempt it yet. It seems like it might be appropriate, but since there was some variation in the error messages compared to mine, I was reluctant to apply this patch.

Do you think, by looking at my above posting of the error that this is the patch for me?

I'd start with the patch, after making a backup of the file you've got currently.