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

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

[DrByte]

This change in v155 causes the email errors to be logged instead of dumped to the screen:
https://github.com/zencart/zencart/c...f65f681370b9a0

Might be useful for keeping tabs on frequency of such issues.

[Patrick Vincent]

I will definitely do that. Thank you.

Also, to append more info, I got word from another of the tech support reps at IMH who dug a bit deeper than the others. He said he found in the logs that a foreign mail server had rejected our SSL encryption level when trying to send a copy of the order to the customer. (Due to PCI compliance we disabled some of the lower encryption levels recently).

He also explained that after the initial ssl transmission failed, the server then creates a new unencrypted connection to send mail (both issues visible in the log snippet he sent).

That makes sense with the behavior in the contact form. The SMTP error was displayed, but an email was still sent. It doesn't explain 100% of the situation, but if the script were failing due the line highlighted below, it at least explains part of it.

Log snippet from their support staff:
(my domains/my IP/my server/customer email address modified as a precaution)

2016-06-14 08:54:19 [20909] 1bCnqv-0005RF-Oe H=myserver.inmotionhosting.com (zencarthostedsite.com) [MY.SER.VER.IP]:53339 I=[MY.SER.VER.IP]:25 Warning: "SpamAssassin as cpaneleximscanner detected OUTGOING smtp message as NOT spam (-1.0)"
2016-06-14 08:54:19 [20909] 1bCnqv-0005RF-Oe <= [email protected] H=myserver.inmotionhosting.com (zencarthostedsite.com) [MY.SER.VER.IP]:53339 I=[MY.SER.VER.IP]:25 P=esmtpa A=dovecot_login:mycpanelusername S=31793 M8S=0 [email protected] T="Order Confirmation No: 6153" from <[email protected]> for [email protected]
2016-06-14 08:54:19 [20919] cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1bCnqv-0005RF-Oe
2016-06-14 08:54:19 [20919] 1bCnqv-0005RF-Oe SMTP connection outbound 1465908859 1bCnqv-0005RF-Oe privatedomain.com [email protected]
2016-06-14 08:54:19 [20922] 1bCnqv-0005RF-Oe H=smtpin.ptd.net [207.44.97.35] TLS error on connection (SSL_connect): error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
2016-06-14 08:54:19 [20922] 1bCnqv-0005RF-Oe TLS session failure: delivering unencrypted to smtpin.ptd.net [207.44.97.35] (not in hosts_require_tls)
2016-06-14 08:54:20 [20919] 1bCnqv-0005RF-Oe => [email protected] F=<[email protected]> P=<[email protected]> R=dkim_lookuphost T=dkim_remote_smtp S=32871 H=smtpin.ptd.net [207.44.97.35]:25 I=[MY.SER.VER.IP]:53182 C="250 2.0.0 Ok: queued as ED5CA6A3B0E" QT=23s DT=1s
2016-06-14 08:54:20 [20919] 1bCnqv-0005RF-Oe Completed QT=23s

[DrByte]

Ya, definitely useful to know about.

You could consider outsourcing your email delivery to be handled by another service, and let them decide how they want to handle ensuring your emails to such destinations are completed successfully.