Customer Not Being Charged For One Item On Their Order-Random Problem

fabienne:

I noticed that one order from a customer came in and the amount they were charged for an item was $0.00. The item was not free, though. I went behind the scenes and looked at the product and the attributes and it all looked fine. I tried to duplicate the problem and it did duplicate (the first item in the cart came up as $0.00). I deleted that cart and tried to make it happen again, it would not. Everything worked well from then on.

When you said you were able to replicate the problem, what do u mean? Did u put the order in as a new order? Did you log in as that customer? Did u replicate it exactly?

I'm trying to replicate it but no luck yet. I thought MC meant he had replicated the error .

lrusk

Haven't specifically identified the file(s) involved, have to go back through the program flow basically as I don't recall it right off the bat.

Basically what happens in order to store all of the selected product information is that the various attributes are encoded in a way that should be consistent through the cart so that at any time it is desired to figure out what the code means it can be descrambled and interpreted. As part of the process, when an item is in the cart, it is typically designed to allow clicking on the product to return to the product description with everything filled out like it was when adding the product to the cart.

In an unmodified store, the link to return to a cart product contains this "code" (prid) as the value for products_id. That said though, simple seo may be stripping that parameter from the link (not ideal), so that was why I went to try to "retrieve" the product using a standard ZC uri with the products_id that appeared in the page source of the shopping cart. Ideally, simple seo would not then affect loading the page with all of the expected parameters preserved. But something in that process also stripped part of the products_id. The correct item was retrieved, but not with the attributes selected/assigned. Ths could be template related or simple seo related.

I can't recall if it is the includes/modules/pages/product_info/header_php.php or one of the variables files that "decode" the products_id, but somewhere between loadng the product_info header and display of the full page the attribute portion of the products_id (assuming that it was generated correctly) is stripped.

1. To repeat the test I was talking about, I suggest first trying on an unmodified, basic products included cart.

2. Goto: index.php?main_page=product_info&cPath=1_9&products_id=26

This is the Microsoft IntelliMouse Explorer that has one attribute (Option Name). The option value that appears first is: USB +$6.00

3. Select: PS/2 (second option in list)

4. Add product to the cart.

5. From within the cart, select the link adjacent to the image that is the product's name. This should return you to the product with the attribute selected that was in the cart.

6. Note what attribute is selected in the attribute list (should be PS/2), also note what the uri has in it. Likely to be: products_id=26:d4a4d0f34fed1a27a2fa01f39c04c0db

7. Go back to the cart, view page source, look for product_id[] and should see a value that looks very similar to the above/equal to the products_id= portion of the clickable link. Note the uri of the clickable link, it contains the above or similar (php versions can cause differences). Now, try going directly to the uri from above but substituting the value of the product_id[] or otherwise as necessary for the cart as generated in the page source for the product but is something like:
   index.php?main_page=product_info&cPath=1_9&products_id=26:d4a4d0f34fed1a27a2fa01f39c04c0db

Which yes is the same uri as clicking on the products name in the cart, but it works.

8. Now goto the cart in question, follow the same process using any product that has attributes and choose an attribute other than the first (smallest). Will see that the uris are modified in the cart to exclude the &products_id= portion (more than likely a result of Simple SEO, as that isn't "simple" anymore.) But will also notice that if the full uri is entered similar to above that includes the products_id found in the shopping cart source data, then will see the product selected from above but with the default attribute selected rather than the attribute that was selected to add the product to the cart. This lack of display of the selected attribute on the product info page could be a result of the uri rewriter if say the rewriter always removes such additional parameters and that perhaps there is a redirect before displaying the product info or a revised action in the process flow before displaying the product info, etc...

Perhaps when the issue can specifically be reproduced then further "testing" can be advised. At the moment based on the identified plugins I'm thinking either the URI rewriter or the template override, with concern about the process to provide the "standard" upgrade. The uri rewriter identified does not appear to be compatible with ZC 1.5.4 which implies that some sort of additional work was necessary to merge it. That the store has reduced functionality also indicates some sort of work was performed and the results considered satisfactory... As stated earlier neither of these is specifically the cause. They can be tested/verified to not specifically be a factor through disablement of each/both and trying the above tests.

lruskauff, no I hadn't yet specifically reproduced the OPs problem, only that I could reproduce the above problem with items that were and were not within the only a single category. Other than that, when picking two items there are 16 different attribute combinations to potentially test assuming that grows for any second product tested all assuming that the individual wasn't logged in when the issue is possible to be duplicated/observed in a linear checkout process... Each new variable to possibly try after this point simply multiplies the number of variations needed to try to replicate a problem that has previously been observed if no further assistive information is provided... I might get lucky, but I doubt it myself at "finding" the way to reproduce the OP problem through complete random testing as at the moment this would involve me making a complete purchase at the store through PayPal purchasing at least 2 items per purchase to eventually see in a purchase that I only got charged for one of them...

mc12345678:

so that at any time it is desired to figure out what the code means it can be descrambled and interpreted.

No offence intended - but much like reading some of your messages. The information is all there, but the way it is organised means that we need to descramble and interpret it. Some of us have more success at this than others. <grin>.

Again, no offence intended. I'm sure I've only written what many/of us think/feel. It's all good information that you provide, but gee it's hard to follow at times. LOL.

Cheers
RodG

ps. I'm sure many people often feel the same about many of my posts/rants.

[> lruskauff, no I hadn't yet specifically reproduced the OPs problem, only that I could reproduce the above problem with items that were and were not within the only a single category. Other than that, when picking two items there are 16 different attribute combinations to potentially test assuming that grows for any second product tested all assuming that the individual wasn't logged in when the issue is possible to be duplicated/observed in a linear checkout process... Each new variable to possibly try after this point simply multiplies the number of variations needed to try to replicate a problem that has previously been observed if no further assistive information is provided... I might get lucky, but I doubt it myself at "finding" the way to reproduce the OP problem through complete random testing as at the moment this would involve me making a complete purchase at the store through PayPal purchasing at least 2 items per purchase to eventually see in a purchase that I only got charged for one of them...

Ok, I guess I'm not following the Paypal part so I'll go reread. Are you saying tho that it only will show after we send it to Paypal? I was hoping it wasn't that, makes it hard to check. But then again, didn't the OP replicate it, then clear the cart but couldn't replicate it again. So if he had to clear the cart, he had not gone to a payment module, so why would we?

Where did he go by the way?

lruskauff:

[

Ok, I guess I'm not following the Paypal part so I'll go reread. Are you saying tho that it only will show after we send it to Paypal? I was hoping it wasn't that, makes it hard to check. But then again, didn't the OP replicate it, then clear the cart but couldn't replicate it again. So if he had to clear the cart, he had not gone to a payment module, so why would we?

Where did he go by the way?

Well the only publicly "confirmed" method of duplicating the issue was through the purchase process which seems to have been the original means to identify the issue. So, no I don't have any plans to purchase that many product to possibly recreate the original issue especially since no further information has been provided about where the problem in the routine purchase was observed. The only other possible information appears to have been deduced, though even that hasn't been confirmed.

The other alternative is like said before that without further information every second product would need to be attempted to some extent until some other abnormal condition is observed. While it would seem that one has/had already begun a similar "search", there hasn't been anything of value provided back about the investigation.

As for where the OP went, I have my thoughts, but it would be nice to have a few more of the questions answered to maybe help fix the problem. Though unfortunately, I no longer expect any.

HI. I had quite a few things to do and now I am back. I was looking through my inbox and trash and didn't see any notices that there was more activity. Perhaps you have to specify that you want a notice each time you respond to a thread. I don't know but I did put a request for notice on now on this response.

First, the question asked by RodG (and I had not observed this BUT it is very important): **The two times the customer was not charged for product both had no size specified for the product. So, the name of the product was stated but not the size.

**Second, I do not have a module called Stock by Attribute installed under the "Modules" setting in my admin panel. Third, IruskI was able to replicate the problem. However, I thought I would try it again and went back tried again and failed. I have not been able to replicate it since and it has not reappeared since the last time it happened which was on 7/21/2015. I signed in as myself (I have a "regular customer" account to try out solutions to problems, etc.).
But the obvious point of no size showing up in the two orders which were $0.00 is perplexing and real. Both should have turned up as some size (probably 6ml).

Have you done anything with your site "recently" regarding attributes, like removing an attribute value from one of your problematic products? I'm wondering if perhaps the following scenario applies:

1. Customer places product#1, size XXXL into their cart (so it's saved in their database's customers_basket table) and leaves the site.
2. Site decides to stop carrying size XXXL, so the Size: XXXL attribute is removed from product #1.
3. Customer signs back into the shop ... product has an unknown attribute, bad things happen.
   I've not verified that the above scenario fails, just wondering ...

fabienne:

First, the question asked by RodG (and I had not observed this BUT it is very important): **The two times the customer was not charged for product both had no size specified for the product. So, the name of the product was stated but not the size. **

That's good to know. It pretty much confirms my suspicion that the issue is related to the attribute selection either not being set, or if it was set, it is getting 'lost' somewhere along the line.

To narrow this down even further, we now need to know the answer to this:

------------------------------------------------------------------------------------------------------------------
*"At what point in the process does the first item show as $0.00?"

Just to expand on this a little, and based on the fact that you have seen the problem 'in action' (as opposed to just seeing the results in the orders placed), AND the fact that you've stated that it is always the first item ordered, this implies that for the 'problem' to occur there must be at least two items in the cart.

If this correct, does the 1st item show a valid price until the second item is added, or does it show the zero price when it is added (in which case, the second and/or subsequent items are insignificant to the cause).

Another reason why this is such an important question is because of the possibilty that the in-cart products have a correct/valid price at all times, and the price of the 1st item is somehow getting set to zero while the data is being sent/processed by the PayPal/order related code.

The fact that you've (apparently) seen the zero cost item in the cart itself means that we can eliminate the 'after cart' processing as being the source of the problem. In addition to this, and assuming that you haven't been logged into the site using a NY address when you've been able to replicate the problem would mean that we can positively rule this (and several other things) out as being a possible cause.

The answer to *"At what point in the process does the first item show as $0.00?" may not give us an answer/solution to the problem, but it can/will narrow down the search (and possible causes) tremendously.

****
Cheers
RodG

****

**

Well, that is a very good question that I can't really answer unless I can get the cart to do this again. I did say I got it to happen once. At that time I was not aware that I had to keep an eye on when it happened (at which point in the process) so I didn't notice, I only noticed that it was $0.00 later in the checkout process. I think I would really have to be able to make that same outcome happen again before I could give you a good answer on that. I could guess about it but I would only have a 50% chance of being right.

This is very disappointing. From the last of the two incidents on there have been no more cases of customers being charged 0. The first two happened within two weeks of each other. I have had pretty good sales since the last one and so far, no more occurrences. I have tried on numerous occasions to reproduce this and with only one success. I wish I had let that one conclude and been able to watch it as I checked out, but I didn't know enough then.

I have very much appreciated your help on this. If it goes away by itself, that would be the optimal solution. I would suggest this: I will (of course) keep my eye on whether it comes back again. If it does then I will try to reproduce it, and since I am able to know that when it happens is very important I can go more slowly and notice when the charge goes to $0 and note that. I will take the transaction all the way through. Then I would come back here and tell you what I found. Unless someone can come up with a better idea, I rather feel like we are at am impasse. What RodG said sounds like where the answer will be found, and if I can't tell you that I might as well keep hunting this elusive thing. Again thanks.

Well it happened one more time. I have not been able to reproduce it in testing and it looks random. The only difference this time is that the total was correct even though the customer's charge for the first item was $0.

Then I came up with a second problem where one of my clients had 196 items in her cart but her cart stopped responding. When she tried to get into her cart (by clicking on the CART button at the top of the page) she got an error message. I tried it, got the same thing. I went into the database and could not see anything which looked like trouble (I am sure it was there but not in the usual places I search). I got out and suggested that she just create another account and apologized for the trouble. There is no upper limit on the cart that I have heard of (that would be pretty counter productive for a capitalist system like Zen Cart). So that is odd incidence #2.

I was talking to a friend (who is very wise in the ways of e-commerce) about this and he suggested that maybe my problem was interference from my webhost's server. He suggested that my getting a dedicated server might stop that problem. What do you think? I am using 1&1 right now and they have been very good indeed. But my business is growing and I wonder if I am getting more traffic than my set up can handle. I have a big sale right now with its increased traffic. Do you think a dedicated server would solve my problems or do you think that is just trying to use a quick jazzy fix which won't really fix anything? I am just as prone to the latter as to the former when frustrated, that is why I am asking your opinion. Thanks.

"an error message" is just a little vague; do you remember the actual error message? Were there debug-logs created?

Well, the error message was pretty vague:
WARNING: An Error occurred, please refresh the page and try again.WARNING: An Error occurred, please refresh the page and try again.

As for the debug logs, would you mean "notice and/or warning log data" from the Review or Export Logs Admin Activity Logs section of the Zen Cart? I am rather new at this so please bear with me. Thanks.

You need to look in your store's /logs folder using either your webhost's cPanel or an FTP (File Transfer Protocol) program like FileZilla. There will be a number of files matching the pattern myDEBUG*.log that will indicate an error with the query_factory class.

You can post the contents of one (make sure that if you're posting one with a filename that includes -adm- **not **to include your admin folder's name). Use the CODE tag (the # in the edit-strip when you're making your reply) to surround the contents you post.

fabienne:

Well, the error message was pretty vague:
WARNING: An Error occurred, please refresh the page and try again.WARNING: An Error occurred, please refresh the page and try again.

As for the debug logs, would you mean "notice and/or warning log data" from the Review or Export Logs Admin Activity Logs section of the Zen Cart? I am rather new at this so please bear with me. Thanks.

FAQ on this specific response: https://www.zen-cart.com/content.php?311-warning-an-error-occurred-please-refresh-the-page-and-try-again

OK. this is good information. I will be finding the debug logs and posting (minus the admin name). And, mc12345678, would that also include something interfering with a shared server, or it that not usually the cause?

OK, here is the content of the debug folder at the time when my customer contacted me yesterday:

[08-Aug-2015 14:54:21 America/New_York] PHP Fatal error:  2008:MySQL client ran out of memory :: select products_id, products_price, products_tax_class_id, products_weight,
                          products_priced_by_attribute, product_is_always_free_shipping, products_discount_type, products_discount_type_from,
                          products_virtual, products_model
                          from products
                          where products_id = '462' ==> (as called by) /homepages/38/d164002731/htdocs/includes/classes/shopping_cart.php on line 660 <== in /homepages/38/d164002731/htdocs/includes/classes/db/mysql/query_factory.php on line 155
[08-Aug-2015 14:54:21 America/New_York] PHP Fatal error:  2013:Lost connection to MySQL server during query :: select count(*) as total
            from sessions
            where sesskey = 'fd162fbfd9bd9c5b18e0f88131acda49' ==> (as called by) /homepages/38/d164002731/htdocs/includes/functions/sessions.php on line 66 <== in /homepages/38/d164002731/htdocs/includes/classes/db/mysql/query_factory.php on line 155

OK, a couple more questions (I've never seen that specific error on any of the 1&1-based sites that I support): your PHP version and your mySQL version. Both can be grabbed from the screen displayed by your admin's Tools->Server/Version Info.

lat9:

OK, a couple more questions (I've never seen that specific error on any of the 1&1-based sites that I support): your PHP version and your mySQL version. Both can be grabbed from the screen displayed by your admin's Tools->Server/Version Info.

While there would also suggest grabbing the memory allocated...

OK, I got these stats (if they are not right please let me know, they were being pretty specific in ways I am not familiar with):
PhP version 5.4.42 (Zend: 2.4.0)
My SQL-Client API Version 5.1.73
PhP memory Limit: 120m

fabienne:

I was talking to a friend (who is very wise in the ways of e-commerce) about this and he suggested that maybe my problem was interference from my webhost's server.

Although 'interference' is quite unusual terminology to describe a server related problem I have to admit that I've actually been thinking along these lines myself - In fact it was this possibility that prompted to ask/query about whether it was somehow related to products with attributes.

Products with attributes are a lot more demanding on a server than products without attributes - And I have seen server/sites with a similar problem to yours whereby occasionally an attributed product couldn't be added to a cart because it was apparently out of stock - but only intermittently. In each of these somewhat rare occasions they have been accompanied by MySQL server errors that had been logged.

I realise that hindsight is 20/20, but your recent log entry with the SQL server running out of memory has pretty much confirmed my suspicions that this is almost certainly the reason for your problem(s).

fabienne:

He suggested that my getting a dedicated server might stop that problem. What do you think?

I'm always somewhat dubious about this common suggestion, because it doesn't really address the issue. A lot of people simply take the advice and get the cheapest dedicated server they can find, which generally speaking will have less CPU power and a lot less memory than the shared server that they are currently using - In other words many find themselves with either the same issues, and in many cases even bigger issues, and to resolve them they are 'sold' a bigger and bigger priced hosting plan until eventually the problems do go away.

In other words a 'dedicated server' is, in itself, not a solution to the problems.

HOWEVER, having said that, if the current shared server is grossly overloaded (as many are), then even a low budget 'dedicated server' may invoke a solution to the problem - But so will another shared server that isn't as overloaded.

fabienne:

I am using 1&1 right now and they have been very good indeed. But my business is growing and I wonder if I am getting more traffic than my set up can handle.

It isn't generally isn't the traffic that is the issue - You could have very little traffic, but if another site on the same shared server is hogging all the resources available then you'll still get this kind of problem.

fabienne:

I have a big sale right now with its increased traffic. Do you think a dedicated server would solve my problems or do you think that is just trying to use a quick jazzy fix which won't really fix anything? I am just as prone to the latter as to the former when frustrated, that is why I am asking your opinion.

A high power dedicated server with lots of RAM can 'hide' (aka 'fix') all manner of problems and issues, so I can only say Yes, this will be one way to solve the problem - And if you have a really busy site it may even be the only solution.

However, there are a wide range of other options that will also invoke a cure/fix rather than jumping from one extreme (overloaded shared server) to the other extreme (high powered dedicated server).

Of the 60 or so eCommerce stores that we host or maintain, we only have one that we've had to give a dedicated server to, and this store is averaging between 50,000-60,000 sessions per day (100,000-150,000 page requests) - According to ZenCart's counters.

The other sites rarely reach 3000 sessions ( <10000 page requests) per day and hosting on a 'good' shared server isn't a problem.

How does your counters compare to these?

Anyway, as I was saying, I'm pretty confident that your problems are server related (not code related), so the solution does mean a change of servers (unfortunately).

What I would suggest though is probably going to be a little different than most, and that is to request your host move your site to a different server under the same hosting plan. Although the 'new' server will almost certainly have the same specs and resources as your current one, it will be hosting different customers and different sites and these customer/sites could easily be making less of demand on the hardware. which will in turn leave more resources available for your site.

If that doesn't solve the problem (or your host isn't willing to migrate your site) you'll need to look into other hosts, or a 'better' plan with your current host.

You should also keep in mind that shared servers aren't 'static'. The fact that they ARE shared means that they'll often start out 'good', but as the host adds more and more customers they get slow and slower until they eventually get overloaded (as yours seems to be) and bigger issues arise. Also, because they are shared, it only takes one customer running 'faulty' software to cause problems for all customers on the server - Generally speaking, the host will quickly identify these customers and have them removed.

Upgrading to a 'dedicated server' is only a viable solution if the server itself has enough resources to handle the demands of your site. As a general rule It is better to be on a shared server with 8-16gig of RAM (or more) than a 'dedicated server' with less than 1Gig.

A dedicated server is, in my view, a last resort to fixing server overload/out of memory issues rather than the 1st resort.
On rare occasions - IOW, a REALLY BUSY site, a high power dedicated server is going to be the only solution. Unless you are pulling in over $200k in annual sales you probably don't need something like this. A non-overloaded shared server is almost always the better option.

Cheers
RodG