Error 10536, duplicate orders

[jeking]

Zen Cart 1.5.5d
PHP 5.4.36
PayPal Express and Payments Pro installed.

Our store is recording two orders one second apart. The PP transaction ID is the same and only one payment is being made. Customer is getting an error saying something about (sorry, don't have exact language) a duplicate invoice.

We've enable logging and I do have the logs for both orders. Time stamps are one second different. Heading in each file is:
[0] => Content-Type: text/namevalue
[1] => X-VPS-Timeout: 90
[2] => X-VPS-VIT-Client-Type: PHP/cURL
[3] => X-VPS-VIT-Integration-Product: PHP::Zen Cart(R) - PayPal/NVP
[4] => X-VPS-VIT-Integration-Version: 1.5.5


Response for #1:
[TOKEN] => EC-83E50027K27786748
[SUCCESSPAGEREDIRECTREQUESTED] => false
[TIMESTAMP] => 2017-02-03T13:53:54Z
[CORRELATIONID] => 2148ef06eec15
[ACK] => Success
[VERSION] => 124.0
[BUILD] => 28806785

Response for #2:
[TOKEN] => EC-83E50027K27786748
[SUCCESSPAGEREDIRECTREQUESTED] => false
[TIMESTAMP] => 2017-02-03T13:53:55Z
[CORRELATIONID] => 436d14df414
[ACK] => SuccessWithWarning
[VERSION] => 124.0
[BUILD] => 28806785
[L_ERRORCODE0] => 11607
[L_SHORTMESSAGE0] => Duplicate Request
[L_LONGMESSAGE0] => A successful transaction has already been completed for this token.
[L_SEVERITYCODE0] => Warning

At first, we thought customers might be clicking the payment button twice so a few days ago disable the button on submit so they can't do that.

How can this be happening and what can we do about it?

[jeking]

Any thoughts or suggestions?

[DrByte]

There's nothing in original Zen Cart code that would make a double identical API call.

It'll re-submit with alterations if some certain failures occur and error messages accordingly, but that wouldn't cause the duplicates you're mentioning.

My guess is you've got some extra ajax processing or something added to your site that's doing an extra submission of the page.
Or the code has been changed in a way that creates a loop.

[carlwhat]

i would also be curious if this is a new site and if it ever was working properly.

[jeking]

i would also be curious if this is a new site and if it ever was working properly.

The site was built years ago. It seems the problem has been around longer than I've been working on the site. It's only a percentage of orders and I've been unable to determine what the cause is. I'll look into DrByte's guess and see if I can determine anything.

[redpeach]

I'm encountering this same issue only after having just upgraded to 1.5.5e...

[SPython]

We are using Zen Cart v1.5.5e with the Authorize.net Aim module. There are random duplicate orders that have occurred since 07/28/17. I read somewhere that the timeout the disabling of the Submit button after click could be adjusted but now I cannot find that reference. How does one do that and is it advisable or would it cause other problems. Would be grateful for any advice.

[SPython]

Additional info: There is only one entry in the AIM_Debug log per each order. There is not an additional entry for the duplicate error which is listed in the database only 5 seconds after the original order. There is normally only one duplicate in an order when this occurs. However, looking back in the records I see three duplicate orders from the same client - the initial occurring at 13:27:51; the second at 13:52:05 ; the third at 13:52:26. This irregular spacing - particularly the length of time between the first and second orders - suggests user error rather than a bug. Zen Cart has a feature whereby the previous order is saved for convenience in the users account. I think this is where the problem may lie. The user returns to their account page and assumes that the order has not been placed and clicks on it again. Perhaps the solution is to disable this feature. But again - it is curious that while I see a separate AIM_debug log for the initial entry in this example, I see only one AIM-debug log for the order that occurred in the same minute.

[SPython]

As a humble suggestions to the programmers - it may be better to list the previous order on the Users account page as text only - rather than have the previous order added to the current shopping cart. I believe this causes confusion, despite the highlighted alert, and may be the cause of duplicate orders. Is there a way to turn off this feature? I do not see it on the admin section.

[DrByte]

As a humble suggestions to the programmers - it may be better to list the previous order on the Users account page as text only - rather than have the previous order added to the current shopping cart. I believe this causes confusion, despite the highlighted alert, and may be the cause of duplicate orders. Is there a way to turn off this feature? I do not see it on the admin section.

1. If you don't want the Orders History sidebox enabled, you can turn it off in Admin->Tools->Layout Boxes Controller.
But don't assume the user is re-placing the order via this method, without actually contacting them and confirming that that's what they're doing. Always verify with your users first.

2. If you're using the AIM module for payments, then the customer's order will ALWAYS be added to their order history if payment is correctly received. ("Correctly" means: no PHP errors due to bugs added by customizations or plugins or template/javascript alterations, no 'user error' by re-submitting payment forms multiple times)
My point here is: the AIM module doesn't do any temporary saving, and doesn't require relying on 3rd party steps to store the order separately.
The only exception would be if your site (template, javascript, customizations, plugins) is allowing users to actually re-click to re-submit payment before the previous click actually finishes. The default template already prevents duplicate-submission.