Only shipping charge is processed

Weird thing happened twice in the last week with one of my eCart sites. I have an add-on shipping charge rule for any state west of the Mississippi. It's been set-up properly and working for years without an issue. However, twice in the past week, orders have gone through (local checkout using Authorize.net) where only the $3 surcharge was recorded and processed. We've had to call the customers to see what they actually ordered. I'm trying to replicate the problem and see what I can figure out, but so far no luck. Do you know of any conditions under which something like this could occur?

I don't know why that would happen. How did you set up the rule? What conditions did you use?

The first step in debugging any issue is reproducing it. If you can't do that, then you couldn't test to see if any attempted fix works and you are basically shooting blind.

If you attach a copy of the ecart object file I can take a look at the charge rule to see if I can spot a hole.

I originally set it up via the eCart object under the Charge tab with the rule name WestoftheMississippi where if a session variable, toTheWest, was true, add $3. Then, on the confirmation page, I set up a series of If statements that said, for example, if the shippingState was CA, toTheWest was true. This routine starts on line 387 of confirm.php (attached).

Here's the eCart object file. I notice that when I display the eCart object in DW, the charge is no longer shown, although it's in the code (line 157). I know I had to uninstall and later re-install eCart, so maybe something happened at that point?

I haven't been able to replicate the problem yet unfortunately. Trying to get more details on the orders to see if there is a particular detail I'm missing.

Thanks for your help, Ray.

Best - Joe

You mean it processed as an empty cart and only had the shipping charge?

What is the web site url? Is it possible that they had used http://www.yoursite.com or http://yoursite.com and only one or the other works? The inclusion or omission of the www. in the url could cause that issue if when you redirect to the https:// version of the page it uses the opposite.

The solution is to force www. or remove the www. for consistency using the .htaccess file (if that is indeed the issue).

Yes, only the $3 charge processed. The URL is https://muirheadfoods.com - I do have it set up to drop the www if someone enters the URL with it. Anything else come to mind?

Maybe the session is timing out... if they spend more than 20 minutes on the page?

You could try extending the session timeout and/or adding a "redirect if cart is empty" so that they can't checkout if the cart is emptied out.

Could a timeout result in letting just the shipping charge through? If so, that sounds like a possible scenario. We've had tons of orders like this and these are the only two with this result.

Could I attach a "redirect if cart is empty" server behavior to the checkout button?

Yes I think that would explain it. Since the shipping charge is just based on the state selection and that would submit from the form and be reset even after the session expired.

I would just add teh redirect if empty to the confirm page before the checkout process. That is the page the payment button submits to and should do the trick.

Sounds good. I think I should also increase the timeout as well. How do I do that for the cart?

You can set the value of session.gc_maxlifetime in your php.ini file... the value is set in seconds.