Sudden duplicate authorize.net transactions? (Single order, double CC charges)

[Patrick Vincent]

We have a relatively busy site that has started creating duplicate transactions/invoices in Authorize.net (for a single order, obviously).

Sometimes the zen cart orders aren't even generated (but an order ID's are), the customer's card is charged, and the Order ID isn't assigned within the zen cart site -- so the next customer takes the order ID. I"m mentioning it because it was even odder than a duplicate transaction.

I've only seen that behavior once. Most of the time it is just two transactions for one order and the order is saved correctly in the system (but the customer gets double-billed).

This started right around the beginning of the month, last week. I was hoping it was an authorize.net glitch, so I waited through the weekend to see if it would stop on it's own. Unfortunately we had four more incidents, so now I have to dig deeper.

We haven't made any coding or options changes to the site. About a month ago we added new items to the catalog, but that's it.

I'm aware that Authorize.net is in the process of upgrading their transaction gateway for high availability, using Akamai SureRoute, but I haven't changed to their new transaction URLs and their deadline to make the old URLs forward won't be until 6-30-2016.

FAQ here: http://www.authorize.net/support/akamaifaqs/

At first I was thinking this was the most likely culprit until I looked up their cut-over date. Now I'm not so sure.

Has anyone else noticed this kind of behavior? (Eg, duplicate transactions with authorize.net or transactions happening without an order being saved in the db?)

Trying to gather more clues to work with. Thanks for any input.

Patrick.

[DrByte]

The "cutover date" is irrelevant: On the cutover date, their old URL will automatically point to the new one, so you won't need to make any code changes. Basically it won't matter. The only reason anyone would want to use the new URL before they switch the old one over is if their site is regularly encountering failed transactions due to very high volume specifically at times when Authorize.net is trying to do system maintenance.
That said, since you said your site is "relatively busy", I'd recommend you "try it out" by making the small change: "secure" becomes "secure2" in the URL.

But, giving any other feedback/advice is very difficult since you've not mentioned which Authorize.net module you're using.
And you haven't mentioned a list of what plugins you've installed.
Also helpful would be your PHP version and your hosting company.
I'd also suggest turning on Debug Log To File in your Authorize.net module so you can audit what's happening with each transaction by looking at the logs it generates in your /logs/ folder on your server.

[Patrick Vincent]

The cutover date is entirely relevant to point away from the Akamai SureRoute as being the potential cause (even though not entirely conclusive due to the potential of back-end work on their systems). Not sure why you had to hammer me about something I already concluded, when I thought I clearly was showing the reasoning we agree with. Crunched for time? Bad day, maybe?

As for your "requests" for more information

Authorize.net Aim module
PHP version 5.5.31
Linux VPS inmotion hosting
No additional modules
Debug mode was set to Log and Email, now changed to Log File

Thanks,
Patrick.

[DrByte]

The cutover date is entirely relevant to point away from the Akamai SureRoute as being the potential cause (even though not entirely conclusive due to the potential of back-end work on their systems). Not sure why you had to hammer me about something I already concluded, when I thought I clearly was showing the reasoning we agree with. Crunched for time? Bad day, maybe?

Eeks. Sorry, I didn't intend that to sound like hammering at all. I was just stating my opinion, which reflects the points I'd made in a few prior posts where people asked whether they needed to act on the akamai thing. Apologies if the tone was offensive. It wasn't meant to be.

Given that you've been doing some logging ... to email or to file, what are the logs showing when these duplicate occurred/occur?


Strictly speaking, a duplicate transaction suggests that the customer clicked the submit button multiple times, despite the (default Zen Cart) javascript that disables the button on first click.
Secondarily, if an AIM error was reported (even though card was charged, which would be very odd) and they submitted again, that would be another case. But of course then one would need to investigate the AIM error. Hence the logging. (files would be AIM_xxxx.log)
Similar for any PHP errors. (files would be myDebug-xxxxxx.log)

hope that helps you dig further

[Patrick Vincent]

That was superb. Thank you. I'll find out what I can.

[Patrick Vincent]

There are no mydebug files in the timeframe of the recent duplicate transactions. Most recent mydebug file is from 5-27.

One duplicate that I'm sure of (because I remember the last name) shows two AIM log files, timestamped a little over five minutes from each other. This points in the direction of the duplicate submit button pressing, as you brought up.

I remembered his name because there were two auth.net transactions, but the order ID that was generated with those transactions was never applied to an order, and a later customer took it. That customer complained that the site was 'going down' each time he tried to check out.

I'll get the list of duplicate transactions from our customer service rep today and look at the rest of the logs. Perhaps all of these users are having a similar problem and pressing submit twice because they are getting some sort of error.