Wrong Attributes on Order

[sdelaney]

I am using v1.3.8 from a new installation.

We are getting an intermittent problem. From time to time, a person will select a product and complete some attribution information for that product and add it to their cart. When they go to the cart to checkout, they find someone else's attributes on the item in the cart. The only way they can proceed is to delete the item from the cart and start again.

This might be something that happens when we are having higher volumes (like 20 orders an hour or something), but that's not a hard fact.

Sometimes we end up with people not noticing and proceeding with paying for their order. This gets us into refunds, etc.

The whole thing makes our order site look pretty shaky and kills confidence in our customers who have encountered this.

Has anyone got any idea what is going on with this?

[sdelaney]

I am at 1.3.8a. (This is our busy season and upgrade is planned for upcoming down time.)

We are a club which holds running races open to the public. Our "products" are races for which people are purchasing registration. There are a number of attributes associated with a registration, such as gender, name, address, shirt size, etc. (We don't use the customer fields because one person in a family tends to register others.)

This is what is happening. Person A selects the race product, fills out the attributes, adds to cart, confirms, pops over to PayPal and pays, comes back and completes the order. No problem.

At some point a little later (or sometimes they are on the site at the same time) Person B also selects this race, fills out their attributes, and adds to cart. But when they go to the confirm screen, the attribute information shown is for Person A. A number of people don't even look at this and go right through the payment process and pay for a registration of the wrong attributes for them. This gets us into the hassle of refunds, getting in touch with them to redo registration, etc.

This all makes our payment collections site look a little hokey and we are getting people expressing fears about the security of their data and purchase information.

This seems to happen more when the site is a little busy. We had 85 registrations yesterday and I had to refund 8 of them and advise the person to go again. I also fielded a number of calls from people who spotted the problem and had to explain what to do. And then there were probably a few people who figured out how to fix it themselves.

Can someone explain what is happening and how to fix it?

Thanks!

[dbltoe]

Check to make sure that you have not inadvertently added zenid to some of the coded links and make sure your config files are correct as to matching the need, or non-need, for www.

[sdelaney]

Thaks for getting back to me!

I'm not sure I follow what you are suggesting. I'm not sure where coded links come into this as I don't believe there is any linking going on here. Same goes for the www and config files.

I want to note that now that the initial rush to register for our next race is over, there has not been a single instance of this situation where another person's attributes (or basket) is attached to the ordering client. I am highly suspicious that it has something to do with multiple users making a similar purchase at the same time, or nearly the same time.

[dbltoe]

Sometimes a zenid is coded into a link. It should not be. When this happens, clicking on the link can change the session so that any cart items available for the link's ID become available to the new customer.

On rare occasions, setting the config to http://www.yourdomain versus http://yourdomain can create session problems as well.

Most reputable hosts will not have the www problem, but it's something to check.

Lastly, check to see that the Sesssions settings in the Admin >> Configuration menu are correct. Google "site:www.zen-cart.com sessions" without the quotes to see some items that might be helpful.

[sdelaney]

Okay, sounds like stuff I should check out. How will I recognize a "zenid" in a link?

[dbltoe]

You should have some suspect area of the cart. You can look at the links in the problem area. Just hovering over them should show a link at the bottom of the browser.

You can also use the Developer's Tool Kit to search. You should have zenid in four files (if you're using 1.3.9e). Any other spots are suspect.

[sdelaney]

Okay, finally got a chance to check this stuff out.

There are no extra zenids around - nix that. Mu Config-Sessions seems to line up with all the standard settings that I could find - nix that.

No issues with www - nix that.

I can report the following. After the initial rush of registrations, the rate of ordering slowed significantly. The problem went away. Friday night a message went out that the race was half full, generating another rush of orders, and the problem reappeared for at least one customer.

I am more convinced then ever that this is related to volume of usage. I can't explain why volume could be causing this, but it certainly seems related.

[xcooling]

maybe your server/hosting is too slow and returns 500 errors during the checkout. Causing the customer to resubmit the order.

Can also happen when the php script does not have enough time to execute.

[sdelaney]

I was thinking that it might be something to do with the speed of the processing, affected by volume.

How are we supposed to see 500 errors when they occur. Does zen cart trap such errors?

Not sure what to do about the speed of our web hosting, if that is the issue?