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

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

[Patrick Vincent]

I did ask for anything, yes, good input, and thank you I'll add it to the list of things to look out for. All troubleshooting ideas should be welcome with people (just be careful doing it in stackoverflow -- generally speaking, the community is far too officious and competitive for things like good ideas).

[Patrick Vincent]

Update: the problems started again and I found I was able to get errors in the contact form by repeatedly submitting it (thanks for the pointer on email being a potential culprit).

From poking around I found that the setting for Email Friendly-Errors was set to false. I set it to true and no longer saw errors in the contact form after a nauseating number of re-submissions. (Note: when the contact form was still showing the error, emails were still being sent/delivered).

Error displaying on-submit of contact form:

Email Error: SMTP Error: Data not accepted.
SMTP server error:

I'm not sure if this was 100% of the problem, but based on the good change in behavior of the contact form after I set the option to true (no more errors), I'm hoping it clears up most of the ordering issues. Why it didn't cause more of a problem with that setting set to false for so long baffles me.

I'm concluding that something must have changed on the hosting/vps side even though the host support staff were less-than-willing to investigate that part. Perhaps a cpanel/whm/exim(email) update that altered the response code? Maybe? I can't be certain, especially considering how the problem seems to start/stop/start again.

Thanks again for the attention. If the mystery unravels further, I'll update the thread so others can benefit.