Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.

8% failure rate


Recommended Posts

I have been operating an MS2 cart for 3 months now and have been selling tons of SKU's. But about 8% of the time the customer complains one of the following:


1. cant log in

2. shopping cart empty

3. cant complete purchase.


#3 is explainable - it has to do with CC declines where the customer for some strange reason doesnt get it that they entered their billing address incorrectly and they just try again and again and again until they run out of patience but never correct the error.


#'s 1 and 2 are inexplicable. Because the cart works so well the rest of the time it cannot be a major flub in configuration. I suspect there's a browser incompatability issue or something like that. Customers claim that yes, they have cookies turned on, etc. One user was using windows 2000. I am wondering if some windows systems have a built-in firewall that by default blocks SSL? Will that produce an empty cart or no login only for that one computer?


Does anyone else see these sorts of problems?

Link to comment
Share on other sites

To help solve #3 you should modify the error message that gets posted to get the customer to actually check for the problem you're referring to. Jeremy


This is under the control of the payment module, which redirects upon an error. That seems to be a design feature. I dont know if all payment module implementations do that. I'd like to see control return to osc, and have osc decide what to do with an error, where to jump, etc. But that might require osc to know about dozens of different payment module implementations.


I believe this API to the payment modules is a weak point in the osc design.


I could modify the payment module code at my own risk of course. Ouch!

Link to comment
Share on other sites

On problems 1&2

Actually the "cant log in cant add to cart if I am IE5.5 on windows 2000" is more frustrating than the error return problem

because they may be caused by tuning settings such as using IP address checking for more secure sessions, etc. I dont know how to set all those settings so they work with 99% of the browsers.


How about this: what if osc checked for IE6 and Netscape 7 and/or whatever browsers you decide to support, and just says to the user to upgrade to a new browser to use the site? That would turn off some customers, but I am starting to see "you must have a 128 bit capable browser to use our site" all over the web now - its getting quite common.


On problem #3: one can build whole pages of info on the credit card topics - things like cvv and avs, billing addresses, etc etc etc, to educate the customer on whats going on. BUT, this would be stuck in the middle of the flow of control and design of osc. Do we want payment vendores to control that control flow or do we want the designers of osc to stipulate that? It makes a difference - 100 payment module vendors could create 100 different flavors of osc behavior - some which may be quite cranky or quite different thann others. I'd rather see hpdl design the best solution and retain control over basic features like that. It may take specifying more interfaces for payment modules to return reasonable messages or more hooks so payment module vendors can add "informative html pages".

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...