Duplicate orders in 1.5.3

I promised I would ask because I don't see how this is possible. A recently upgraded cart (from 1.3.9) is experiencing duplicate orders. Payment method is paypalpro.

I did find one line in tpl_checkout_payment_default.php that is not supposed to be there and have removed it but I don't see how that could create the situation where the buyer found it necessary to hit the submit button again:

if ($_SESSION['cart']->show_total() == 0) {
     zen_redirect(zen_href_link(FILENAME_CHECKOUT_CONFIRMATION, '', 'SSL'));
 }

I just don't see anything else. Any ideas?

Are you using the stock checkout system or something else?

The broadest question to ask might be in what ways is the code on the server different than the code of a fresh install of the same version of ZC (whether it is 1.5.4 or 1.5.3). I'm leaning towards the possibility that one of the includes/modules/pages folders has extra files in it ending with .php.

So this "duplicate" orders situation, what is the "effect"? Charged twice? Two unique new order numbers? Same order number but email sent out twice? Etc... The detailed observed action would help identify where it could be as well as where it is not (likely) to be in the processing of the order(s)? Does it happen on every order? Every order using just that payment processor? Default template? Etc...

stock by attributes - yes.

New up to three separate orders. Customer noticed nothing out of the ordinary. Don't know whether it sent more than one email. Orders happen from 8 seconds to 1 minute apart.

Just seen this happen on a recently upgraded zc 1.5.4.
3 orders, different order numbers, same paypal ID.
There was only one item to sell. The quantity on hand became -2.

bruce429:

Just seen this happen on a recently upgraded zc 1.5.4.
3 orders, different order numbers, same paypal ID.
There was only one item to sell. The quantity on hand became -2.

To try to help identify issue, is SBA installed on that system as well?

Additional payment module and transaction information would also be useful. Where did the module come from (builtin or provide link)? The configuration for the payment module used? Was the module removed and reinstalled / configured after the upgrade? Was a "callback" such as IPN involved (can check the server access logs around the time of the order)? Did the customer actually press the button twice (can check the server access logs around the time of the order)? Any modifications to the default checkout process?

Maybe another can chime in (I've not worked directly with the PayPal Pro code), but I remember reading somewhere while PayPal Pro does not require IPN, it will accept IPN calls from PayPal to update the order (such as cost adjustments, refunds, etc)...

PayPal Pro is the actual merchant credit card processor that requires paypal express checkout as its base and therefore does use curl and not the IPN. It is part of the default files.

mc12345678:

to try to help identify issue, is sba installed on that system as well?

no sba.

bruce429:

no sba.

Good to know, thank you. What about the questions that lhungil had asked? Please answer as many of those as possible.

I removed the SBA from the cart on Friday and waiting to see if we get any more duplicates - none over the weekend.

SAme problem here . Button pressed only once, no SBA. Intermittant duplicate orders. Some are charged twice, some not. Some just 2 or 3 duplicate orders with only 1 charge. Using payflow pro 1.3.9 on zen cart 1.5.4

Any ideas welcomed?

wootoot1234:

SAme problem here . Button pressed only once, no SBA. Intermittant duplicate orders. Some are charged twice, some not. Some just 2 or 3 duplicate orders with only 1 charge. Using payflow pro 1.3.9 on zen cart 1.5.4

Any ideas welcomed?

Having the exact problem. Again, any ideas?

I think it's also worth noting that it might not be specifically a Zen Cart issue, as I am seeing duplicate form submissions on PERL based form handlers as well.

check this thread:

https://www.zen-cart.com/showthread.php?207877-Duplicate-Orders/page2

are you having email issues? the lag in sending an email can screw up the order process and cause the customer to resubmit...

good luck!

I think this might be more of a buyer-side mobile device error. I upgraded from 1.3.9h the end of March and started utilizing a responsive template for the first time. I have had two duplicate orders with single payments since then. The first order was on Verizon, where I could see the IP address changed during checkout. The second buyer was using a satellite IP service - the IP started as "172.243.75.61", then switched to "172.243.75.61 - 172.243.75.61".
My site is low volume, so maybe someone with multiple occurrences can prove my theory?

VDecalS:

I think this might be more of a buyer-side mobile device error. I upgraded from 1.3.9h the end of March and started utilizing a responsive template for the first time. I have had two duplicate orders with single payments since then. The first order was on Verizon, where I could see the IP address changed during checkout. The second buyer was using a satellite IP service - the IP started as "172.243.75.61", then switched to "172.243.75.61 - 172.243.75.61".
My site is low volume, so maybe someone with multiple occurrences can prove my theory?
Nice piece of detective work, @VDecalS! I'm sure that the information you supplied will be an aid in determining the solution to this issue.

carlwhat:

check this thread:

are you having email issues? the lag in sending an email can screw up the order process and cause the customer to resubmit...

good luck!

carlwhat,

We're not having email issues that I've noticed, but I do have a question for you. We're not using SMTP fields under Configuration >> Email Options. Iffn' I fill in those fields, do you think this may help the order process grease through with a little less lag?

Much Obliged!

digipete,
are you saying you have a lag in the order process in addition to having intermittent duplicate orders? if so, my experience tells me its probably the email. see this other thread:

https://www.zen-cart.com/showthread.php?219285-sending-order-emails&p=1302349#post1302349

the easiest way to see if sending emails is what is causing the lag (and i think it would either be that or the payment selection), is to turn emails off, and place a test order and compare that to a test order with emails turned on. i have a feeling that you will decrease the lag greatly. and if you have a great lag, then my opinion remains that the email is failing, the customer gets a weird message, the customer reloads the page, and then you have your intermittent duplicate orders. you see ZC creates the order, sends the email, and THEN clears the cart. so if the sending of email fails, you already have 1 order, but the customer's cart has not been cleared. if they resubmit the form, you will get a second order.

as far as the email configuration settings, you have to play and see which ones work best for you. the SMTP fields are only necessary if you select SMTPAUTH as your method of sending.

good luck!

VDecalS:

I think this might be more of a buyer-side mobile device error. I upgraded from 1.3.9h the end of March and started utilizing a responsive template for the first time. I have had two duplicate orders with single payments since then. The first order was on Verizon, where I could see the IP address changed during checkout. The second buyer was using a satellite IP service - the IP started as "172.243.75.61", then switched to "172.243.75.61 - 172.243.75.61".
My site is low volume, so maybe someone with multiple occurrences can prove my theory?

lat9:

Nice piece of detective work, @VDecalS! I'm sure that the information you supplied will be an aid in determining the solution to this issue.

I've had another instance of this (I'm using 1.5.5 responsive template) from a repeat buyer. Can anyone else see IP changes on duplicate orders?

Duplicate Request [L_LONGMESSAGE0] => A successful transaction has already been completed for this token.
ViaSat, Inc. connection changed during processing. IP address began 172.243.75.61 ended as 172.243.75.61 - 172.243.75.61
Only ONE payment processed.