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

[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.

[Patrick Vincent]

It stopped as mysteriously as it began. Four days without an incident.

I did gather the associated transaction printouts and was getting ready to matrix those things together with processing times and digging into whatever logging and info I could get on my host's time-corresponded issues -- but the problem just stopped.

I'm going to guess it was network or server congestion, causing the returned zen cart page to timeout or error.

The only proactive action I can think of that might make an impact in the future is to increase the script timeout settings... maybe.

I might also instill with our cust service rep to gather more information about the customers if it starts again (browser, displayed error, etc..). Perhaps I'll make out a small template for her to email customers. A short questionnaire.

Is there anything else you can think of?

(Oh, and PS, I think I can relate your position on the Authorize/Akamai stuff. I've been trying to explain to people since the late 90's that cookies aren't viruses, but are pretty useful when you don't have a login over a stateless protocol. To this day people still ask about them and I get a little tense - I suspect from repeating myself for nearly two decades.)

Be well. And thanks so much for the attention. If I ever do find a definitive cause, I'll be sure to come back and fill in what blanks I can.

[carlwhat]

wild guess... your hosting company (or you) changed the email setting.

i use authorize.net, however i have modified the timing of the transaction submission due to clients needs. so i would not get into this situation. however, when the sending of an order email fails, it screws up the whole order process. see:

https://www.zen-cart.com/showthread....41#post1311441

frankly, i'm not convinced that this is the problem, but you were asking for anything else...

it does seem like a network problem. especially when you say the order ID gets assigned to the next customer's orders. i have had experiences similar when there are problems with queuing on other systems...

these are always the trickiest to figure out.

good luck!