Duplicate Orders/Order Confirmation

[Beer_man]

Hi All,

This problem is intermittent, and I have no firm idea why it happens...sometimes (perhaps 5% of the time) I get two order conformation emails (but payment is taken from the customers card only once).

This can give me –ve stock levels and also screws up my sales report for the month

Any ideas what may be causing this? I can see no real 'link' between 'single' and 'duplicated' orders. (N.B. All my card transactions are done on-line)

Running v1.3.7

Cheers!

Beer_man.

[helpme]

I am having the same problem...I have had it happen when they used paypal as a payment and when using the CC module on zen cart.
Does anyone have a fix?
Thanks!

[absoluteblock]

I, too, had this happen today for the very first time.

A duplicate order was created 14 seconds after the original order.

The duplicate went to the "Pending" category whereas the original went to "Processing".

The duplicate shows cc as the payment module, but the original shows linkpoint_api (as it should). For the record, I've never used the cc module.

[helpme]

Okay, something is going on, now I am getting 3 copies of each order! Does anyone have any idea what could be the problem?

I am using 1.3.7, lots of add on modules!, cc module, paypal express....note that the last 3 orders where with the cc module (I am not sure if the orders double or triple in PP)

Now I need to figure out how to fix this without deleting orders, no red flags needed here!

[youniquephotos]

This just happened to us today as well, it produced three order numbers and confirmations(for the same order), but only registered one payment.

Any ideas?

[TamyA]

I have this happened to me on the 2 websites i am managing, i got 3 order numbers and one email confirmation from each (happened once on each site).

in one site it happened when a customer used Google checkout and the other when local checkout with CC was used.

Both carts are 1.3.7

Any Idea?

[evenangelsdie]

Yes I've already read your post about this, but am still hoping for a solution that hasn't been found. My email solution fixed the multiples of orders, but it still looks like I'm stuck with the duplicates from the PayPal user issue. There has to be a way to fix this on the zen cart end...? Such as not registering a second order with the same PayPal transaction id or something?

[kdoronzio]

I'm not sure this is the same issue everyone here is having, but I believe I found the solution to this problem for us.

The distinction seems to be CSS buttons versus image buttons. We use CSS buttons. Apparently, CSS submit buttons don't get a name or id like their image counterparts do. As a result, the submitonce() code doesn't work, since it references an element with the id "btn_submit", which doesn't exist.

Apparently there is a bug that resulted in leaving this capability out. We've confirmed this bug existed in 1.38a and 1.51. We're using 1.51. I don't know the root of this bug, and why it was never enabled. As a result, I don't know if my fix will cause problems that I haven't seen yet. It seems innocuous enough.
reference: http://www.zen-cart.com/showthread.p...n_image_submit

Our fix was to change the function for zen_image_submit() so that CSS buttons inherit the parameters variable just like the image counterparts do.

In /includes/functions/html_output.php
Line near 268 reads:
if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class /*, $parameters = ''*/ );

Remove the comments and the = '' so it reads:
if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class , $parameters );

That's it.

Again, I don't know repercussions, but a quick run through our site seems OK. And this issue seems to be fixed, for us at least.

[karinvd]

I'm not sure this is the same issue everyone here is having, but I believe I found the solution to this problem for us.

The distinction seems to be CSS buttons versus image buttons. We use CSS buttons. Apparently, CSS submit buttons don't get a name or id like their image counterparts do. As a result, the submitonce() code doesn't work, since it references an element with the id "btn_submit", which doesn't exist.

Apparently there is a bug that resulted in leaving this capability out. We've confirmed this bug existed in 1.38a and 1.51. We're using 1.51. I don't know the root of this bug, and why it was never enabled. As a result, I don't know if my fix will cause problems that I haven't seen yet. It seems innocuous enough.
reference: http://www.zen-cart.com/showthread.p...n_image_submit

Our fix was to change the function for zen_image_submit() so that CSS buttons inherit the parameters variable just like the image counterparts do.

In /includes/functions/html_output.php
Line near 268 reads:
if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class /*, $parameters = ''*/ );

Remove the comments and the = '' so it reads:
if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class , $parameters );

That's it.

Again, I don't know repercussions, but a quick run through our site seems OK. And this issue seems to be fixed, for us at least.

Does anyone use this solution? I'm having the same issue and i'm using CSS buttons, i would like to try this but i'm scared something wil backfire :-) No orders is worse then double orders ;-)

[lat9]

If you use the CSS3 Buttons (http://www.zen-cart.com/downloads.php?do=file&id=1386) plugin, the current version (1.0.4) contains the submit-button fix you identified.

P.S. The plugin's functionality (and thus the correction) will be included in Zen Cart v1.5.3.