Same customer making multiple orders but issued same order no. & order not recorded

Hello,

We have dropship customers who make multiple orders daily. The customers who make the most orders pay day are encountering the same problem.

All pay by Paypal and after paying, Paypal returns them to our site and they get the confirmation page. This is all fine, but on their 2nd+ order they get returned to our site and it shows the same order number as their first order of the day.

They get no order confirmation number and our website doesn't record the order. The order is not showing in their website order history. However, the paypal payment has been received.

We have told them to sign out and in again for each new order but the same problem is occurring.

Orders are sometimes placed within minutes or several hours with the same problem.

Can anyone give suggestions?

I'd start by answering all the posting questions you encountered when writing your post, and in particular pay extra attention to listing and mods you have made or installed.

Looking for solutions please.

Using Paypal Express.

picandnix:

pay extra attention to listing any mods you have made or installed.

Any installed mods?

We have many mods installed but this problem never occurs when the customer places the first order.

When it does happen, it only happens when a customer places more than 1 order within the day and then not always.

One customer complained 5 orders didn't show in his order history (or our admin - but all payments were processed in Paypal) but she had 3 other successful orders that day that did show in our admin and her order history.

The orders that fail, our site is giving customers the same order number as their previous order.

response from our hosting company. I have no idea what it means or if they are correct. Can someone please help.

Checking the access logs for "dropship" there are 302 "file not found" errors (full log can be downloaded from cPanel -> Logs -> Raw Access Log)

86.151.8.123 - - [02/Jul/2013:17:21:20 +0100] "GET /index.php?main_page=checkout%5fprocess&referer=paypal HTTP/1.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0"
86.151.8.123 - - [02/Jul/2013:17:21:21 +0100] "POST /index.php?main_page=checkout%5fprocess&referer=paypal HTTP/1.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0"

The error appears to be "checkout%5fprocess" which looks like an encoding error - can you please check with your developer on this. We're not blocking the URL at our end, but if the encoding / URL structure is incorrect, then this would lead to PayPal not be being able to access the page. 302 basically means "not found". The normal URL structure would be an underscore as in "checkout_process".

As for the IPN responses, the log shows all correct entries with 200 responses which show PayPal can access the page without any issues:

66.211.170.66 - - [02/Jul/2013:16:32:28 +0100] "POST /ipn_main_handler.php HTTP/1.0" 200 - "-" "-"
173.0.81.1 - - [02/Jul/2013:21:49:59 +0100] "POST /ipn_main_handler.php HTTP/1.0" 200 - "-" "-"

The fact that the order does not clear properly does look like a coding error on your site, with the session variables not being cleared upon order confirmation. As this is handled by checkout_process, the error above (302) may provide a clue as to what's going wrong, but you will need to look into this with your developer as we cannot provide coding support.

riolas:

... All pay by Paypal and after paying, Paypal returns them to our site and they get the confirmation page. This is all fine, but on their 2nd+ order they get returned to our site and it shows the same order number as their first order of the day.

They get no order confirmation number and our website doesn't record the order. The order is not showing in their website order history. However, the paypal payment has been received.
...
What happens when you attempt to duplicate this behavior yourself? Do you encounter the same issue? What do you see in "FireBug" (especially the net tab) or a similiar tool when checking out?

riolas:

... response from our hosting company. ...
302 basically means "not found". ...
Actually HTTP 302 means "I found something matching your request, but it has been temporarily moved, go here instead." and the response to the browser usually includes a "HTML header" with the new location. Sorry to nit pick, but it bothers me when information is not fully accurate.

riolas:

86.151.8.123 - - [02/Jul/2013:17:21:21 +0100] "POST /index.php?main_page=checkout%5fprocess&referer=paypal HTTP/1.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0"

The error appears to be "checkout%5fprocess" which looks like an encoding error
...
As this is handled by checkout_process, the error above (302) may provide a clue as to what's going wrong, but you will need to look into this with your developer as we cannot provide coding support.
The provider "could" be right - when a "POST" request is redirected via a 301/302 the "POST" data is lost. So when you see "POST /index.php?main_page=checkout..." and a HTTP 302... However keep in mind this is normal if the customer's session has timed out (they will be redirected to the timeout page).

Do you have any modules installed which modify the URLs? If you do are they up to date?
Does your store have any modifications made to the PayPal module?
Does your store have any modifications made to the checkout process?

Those who are more knowledgeable than I am about the PayPal module(s) will want to know every possible way your store is different from a stock Zen Cart installation in order to better help you.

lhungil:

Those who are more knowledgeable than I am about the PayPal module(s) will want to know every possible way your store is different from a stock Zen Cart installation in order to better help you.

Exactly. A detailed list of ALL differences from original code is the very basic starting point. Plugins, code changes, PHP versions, rewritten URLs, server configuration info, and so on. Kinda like the Posting Tips that show up above the Reply box after clicking the Reply button.

http://www.zen-cart.com/wiki/index.php/Troubleshoot_-_Diagnosing_Obscure_Issues

picandnix:

I'd start by answering all the posting questions you encountered when writing your post, and in particular pay extra attention to listing and mods you have made or installed.

Now do you see my point riolas?

Servers run PHP 5.3.

Here is a list of installed mods:

return authorization
easy populate
seo urls
auto responder+
recover cart sales
fast and easy checkout
testimonials manager
products with attributes
sales report with graph
quantity/time report
image handler
database backup MySQL
export email addresses
sitemap xml

The paypal express module has not been changed.

We are using the 1 page checkout and the express button is on the shopping basket page as well as the final checkout page.

The problem only occurs (and not always) when the customer places more than 1 order in the day.

The most recent incident was when the second order was placed 3 hours after the first. Payment went ok, then Paypal returns the customer to our website to the checkout success page BUT, it is the same order number as her previous order earlier in the day.

The website doesn't record the order in our admin, the customer's history, nor email her confirmation from our website (but Paypal does email her).

what happens to the process if you disable FEC?

Tried purchasing to replicate the problem by purchasing at random times throughout the day with the same account. No error's encountered...

This has happened with two customers now and it is frustrating we can't even replicate the problem they are getting...