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

[lruskauff]

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

[mc12345678]

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:d4a4d0f34fed1a27a2fa01 f39c04c0db

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...

[RodG]

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]

[

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?

[mc12345678]

[

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.

[fabienne]

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).

[lat9]

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 ...

[RodG]

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

[fabienne]

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.