Duplicate Orders

[carlwhat]

My next question @carlwhat is, Where the heck were you with this suggestion a few days ago? <g>

- working on my PCI compliance. ;)
- still mourning the loss of David Bowie.
- wondering how people at themeforest could charge for 1.5.4 responsive design templates that work like crap with bugs and outdated code from older releases.
- debugging (yet again) the crap (IMHO) that is MY_ADMIN/includes/functions/extra_functions/edit_orders_functions.php.

shall i go on?

seriously, as i stated in the link that i provided, i think it's #1 a design flaw that despite the settings one has, ZC will create the order without clearing the cart. the idea that sending an email order confirmation in the middle of that process which could derail the process is inherently bad... again IMHO. and #2 using the built-in ZC logging function would have saved us both many hours of time and frustration as it would have pointed us both in the right direction as to the cause of the problem.

glad you were able to identify the problem. indeed, identifying the problem is much more difficult and worthy of celebration that implementing a solution.

[RodG]

- still mourning the loss of David Bowie.

:-(

seriously, as i stated in the link that i provided,.

Shoot. I was so happy I found the cause that I didn't even follow the link. (Something I shall rectify shorlty)

built-in ZC logging function would have saved us both many hours of time and frustration as it would have pointed us both in the right direction as to the cause of the problem..

I don't know if it would have helped or not in this case - because one of the symptoms (or lack of) was the fact that the emails were actually being sent (and received by the recipient's server) before the 'checkout success' page was loaded.

It as though the process was going something like this

- order gets created
- emails get sent
- mail process hangs around for 90 seconds doing nothing
- cart gets cleared
- Checkout success page displayed

After I'd discovered that it was the mail process holding things up I upped the logging level up a few notches on the mail server and observed what was going on - In a word 'nothing' was going on during that 90 seconds.

The entry prior to the delay is/was "Message accepted for Delivery"
The next entry (90 seconds later) is/was the "stat=Sent (OK)" message.

glad you were able to identify the problem. indeed, identifying the problem is much more difficult and worthy of celebration that implementing a solution.

I am now celebrating having found the solution. It was a TLS certificate issue - or more specifically, the server didn't have (or had somehow lost) its sendmail.pem file (there were warnings about this in the log files when the server got started, but as mails were being sent received with no apparent issue I hadn't taken much notice of it until now).

Anyway, I recreated this file, restarted the mail server and all is good.

Cheers
RodG

[d0ugparker]

I am now celebrating having found the solution. It was
a TLS certificate issue - or more specifically, the server
didn't have (or had somehow lost) its sendmail.pem file
(there were warnings about this in the log files when the
server got started, but as emails were being sent received
with no apparent issue I hadn't taken much notice of it
until now).

Anyway, I recreated this file, restarted the mail server
and all is good.

RodG

So, you're no longer getting duplicates or triplicates? Geez,
I want that.

I read through the thread, and if I'm reading things right, by
sending a private key to my web host and having them install
or confirm the accuracy of that .pem file's contents on their
mail server, I should be able to eliminate my occasional,
random, double orders. (No, I've never seen a 3-cate)

Care to comment? :-)

...and this thread is non-sticky because, er... why? ;-) Okay,
maybe not sticky, but how about its becoming an FAQ item?

Regards,

[RodG]

So, you're no longer getting duplicates or triplicates?

Correct. Not a single duplicate order since adding the .pem

I read through the thread, and if I'm reading things right, by
sending a private key to my web host and having them install
or confirm the accuracy of that .pem file's contents on their
mail server, I should be able to eliminate my occasional,
random, double orders. (No, I've never seen a 3-cate)

Care to comment? :-)

Yes. The site I had the issue with was a VPS. so ultimately it was a problem that I needed to fix myself. Your webhost should already have a valid cert installed and a correctly functioning mail server,so my findings, problem and fix probably won't apply to you.

Important clarification: The "duplicate orders" were a result of the customer clicking multiple times to submit their payment because it appeared to them that it hadn't "taken", because of timeout delays while sending the confirmation email.

In my scenario that doesn't appear to have been the case (from memory). I realise that this is the logical reasoning, but after having replicated the issue I'm pretty confident that the duplicate orders weren't a result of multiple clicks.

...and this thread is non-sticky because, er... why? ;-) Okay,
maybe not sticky, but how about its becoming an FAQ item?

It probably not really a FAQ question -- or at the very least, the cause and solution (in my case) would be way down the list of possible causes.

In hindsight, I probably would have narrowed the cause down a lot sooner if I had tried using a different mailserver (as per DrByte's recent suggestion), but I really had no reason to suspect that it was a mail server issue until I'd actually discovered the cause.

It could be a suggestion for your to try though, if nothing else it will help eliminate whether your dupe problem being is mail related, or has some other cause.

Cheers
RodG

[DrByte]

In short - Regardless of the chackout method/options - as soon as that 'confirm' button is hit, the order is processed, but the 'checkout success' page doesn't appear for thew 1-3 minutes.

Note: This example shows ~90 seconds elapsed between the 'checkout_process' and the 'checkout_success'.

I'm confident that this isn't technically a ZenCart issue (same code both sites), and if it were a server overload issue (my initial thoughts) then I'd have expected the problem to worsen on the lower powered VPS

A delay with communication to the email server could make sense (and would be triggered in checkout, new account creation, and status change w/ notification). Can probably test in the Zen Cart admin to see if sending an email shows a similiar delay.

I've read reports of PHP mail() sometimes being slow if DNS resolution takes an extended time. And SMTP could also be delayed by QOS / rate limiting.

After I'd discovered that it was the mail process holding things up I upped the logging level up a few notches on the mail server and observed what was going on - In a word 'nothing' was going on during that 90 seconds.

The entry prior to the delay is/was "Message accepted for Delivery"
The next entry (90 seconds later) is/was the "stat=Sent (OK)" message.


I am now celebrating having found the solution. It was a TLS certificate issue - or more specifically, the server didn't have (or had somehow lost) its sendmail.pem file (there were warnings about this in the log files when the server got started, but as mails were being sent received with no apparent issue I hadn't taken much notice of it until now).

Anyway, I recreated this file, restarted the mail server and all is good.

Cheers
RodG

Thanks Rod for the detailed analysis and summary of the problem, including the fix.

Important clarification: The "duplicate orders" were a result of the customer clicking multiple times to submit their payment because it appeared to them that it hadn't "taken", because of timeout delays while sending the confirmation email.



In Rod's case it was a server misconfiguration with (expired) TLS certificates within Sendmail.

Another alternate way around it:
Change the Email Transport Method in ZC admin->Configuration->Email Options to SMTPAUTH and point it to another server to do the email delivery (ie: one could sign up for a free account at MailGun and once fully configured simply provide the SMTP credentials to your ZC store and then Mailgun will handle all the delivery, instead of relying on your hosting company to keep their servers current)

[d0ugparker]

Thanks Rod for the detailed analysis and summary of the problem, including the fix.

Important clarification: The "duplicate orders" were a result of the customer clicking multiple times to submit their payment because it appeared to them that it hadn't "taken", because of timeout delays while sending the confirmation email.

Could a smidgeon of php code or javascript change the

SUBMIT ORDER

button to a

WAIT

button, removing the href the instant the mouseup occurs?

[DrByte]

Could a smidgeon of php code or javascript change the

SUBMIT ORDER

button to a

WAIT

button, removing the href the instant the mouseup occurs?

The default code in Zen Cart's default template already changes the mouse-pointer to a spinner, and disables-and-grays-out the submit button. I believe it's done that since v1.5.0.
But some 3rd party templates change the way that works. There are a bunch of forum discussions about "disabling the submit button on checkout confirmation", where various alternate code snippets have been shared.