Home arrow Ecommerce FAQs
Ecommerce Questions

Ecommerce FAQs

The 99 Vital Questions
Here are some important factors to consider when choosing an ecommerce solution. You need to understand these issues before you can competently choose a good foundation for future growth.  One way to select an application (or a provider) is to create a list of your requirements, then prioritise them. In the end, though, it's probably best to take advice.
It helps if the people you ask are independent, have no ties to any particular solution, have no preference for commercial or open-source and can advise on the best for the job, have wide experience with different applications, offer free advice, know online business well, and above all appreciate the factors that make an online store succeed or fail. That would be us.
These questions concern the nature of the application and how it will be set up:

* Do you need a small shopping cart-style application, or a larger ecommerce solution?

* Will you buy outright, and organise everything yourself - or will you lease a hosted ecommerce solution?

* Purchase or leasing costs; upgrade costs. All applications will require occasional upgrades, so there must be a clear upgrade path.

* Development costs: implementation, customisation, and simple templating (which isn’t simple sometimes).

* Hosting type; hosting cost.

* Number of payment gateways offered, and whether they will integrate with your bank.

* Whether DCC can be arranged, if you sell in different countries. Direct Currency Conversion shows the purchase price in the customer’s local currency, and is a function of payment gateway / bank integration.

* Does the application support SEF URLs (search engine friendly page addresses) - and to what extent exactly? A ‘yes’ answer here can have many different interpretations (and, realistically, sometimes mean 'no'); the following question is perhaps more specific.

* Are the URLs short and relevant?

* Can you add pure content pages to the front end, since you will need to do this for good search results? This refers to ordinary text pages with no products on them; ecommerce software authors call these 'brochure pages' or 'web pages'.

* Is the admin backend slick, basic, or poor?

* Is there a category page option, with separate templates?

* Is there a sub-category page option?

* Do the product pages suit your class of goods or services?

* Are the product pages fully templated, allowing easy customisation? How easy (or difficult) would it be to import your own design?

* Are there 3rd-party developers who can help you customise it?

* Will you get a large choice of attributes to vary, on the product pages? You might need size, colour, price, and weight options.

* What tax variants can you get?

* Are there region-specific versions that will work well in your area? Localisation or internationalisation is going to be a critical issue for many.

* Is localisation fully accounted for with your chosen application? This means local language, currency, tax variants, and shipping options. In general, all applications come set up by default with English, US Dollar currency, US tax and US shipping options. But is this what you need?

* What about shipping options? You'll need to be able to specify different shipping methods and costs.

* Can you cross-sell, up-sell, multi-sell, affiliate-sell and auto-apply discounts with it?

* What reputation does your chosen app have for security?

* Is the look and feel of the store more important to you than other factors?

* All shopping carts have built-in SEO negatives; does your proposed solution have less than others; and is it therefore better?

* Does the application specifically mention positive SEO benefits over other programs - and are these genuine? Application developers who realise that search optimising is the first priority and not the last are still rare; if you find one, then support them - it will be worth it.

* Just how far does your chosen application go in supporting and complying with web standards - for example, are page layouts based on cells and tables, even though these were obsolete around 2002? Or are the pages based on layers and CSS as they should be? Accessibility and web standards compliance issues like this will be of much greater importance soon - don't get stuck with an obsolete application.

* Does the page code validate 100% out of the box?

* What is the maximum number of products the application supports? Some users will need to know this figure, since there are numerous product types that can approach the 5,000 or 10,000 max figure often quoted for the smaller applications. Such programs can be extremely capable, but due to internal configuration they are not designed for large product numbers. Trying to sell 50,000 products with one of these will not be a happy experience. If you have 500 or 1,000 products you can choose any application; if you have 30,000 then your choice must be very carefully considered.

* What database (or databases) does the app use? The most common is MySQL, which almost all hosts provide on their servers (including of course Windows hosts). Always choose this if possible. Next comes PostgreSQL, which is even more capable but harder to support.

* Apps that use a 'flat file database' do not use a database as such - it is a text file equivalent, not a discrete application. This imposes size and speed limitations that effectively mean the upper limit for the number of products is about 1,000. 

* Is the application a server-side or client-side program? Some shopping carts are client-side apps that run on a local database, i.e. one on the owner's own PC. The pages generated are then uploaded to the site. There are product number limitations with this method, of the order of perhaps 5,000. One example is Actinic, which runs on a local PC, and can use Microsoft SQL Server (other versions use Access, which is acceptable here since it is running on the local PC, not the server); this app now though has some very good SEO points, and is well suited to stores without a large number of products.

* Does the application as standard come with links on the page (maybe at the foot) to the supplier? You don't want this - certainly on the front page - they will have to be removed. Links can go on the page specifically for that, or from out of content if you are really doing them a favour. Otherwise, they can pay you £500 a year for a link.

* Do the pages have hidden links in the code? You need to check by viewing the page code source. There must be absolutely no <a href="http://www.a3webtech.com"> or similar in there (substitute the supplier's name here). Unless specifically mentioned in the sale contract, they should not be there; and in any case must be removed. Search engines are not happy with anything hidden in the source that cannot be seen by visitors.

…and a hundred other things you need to know first!


Don't go with a host that only gives one database per site - that is just plain ridiculous. Normal hosts offer 5 or even 10 DBs on their accounts. Three databases (DBs) is the minimum number that a fully set up modern website can need. Anything you might want to add on or plug in to your web application will probably require a database: the main CMS and/or ecommerce app, website analytics, blog, wiki, or forum. There is no cost to the host as they won't have to support subsidiary DBs; and their data size is included in your webspace total, so it's not as if you're getting something for nothing.

In order of robustness (i.e. stability, security, ability to handle large amounts of data), the order of database quality in descending order is considered to be:

  • Oracle
  • PostgreSQL
  • MySQL
  • MS SQL Server
  • a well-known PC database occasionally but wrongly used on servers

There are numerous others such as InnoDB, but those mentioned are the most common and therefore a better choice since there will inevitably be better support. Don't try to run an unusual system combination that few others might be using, because there are no pluses whatsoever to that. Unless you are a corporate enterprise with a large Internet budget, stick with combinations of the common applications that are proven to work and that can be widely supported. Even Amazon uses MySQL databases (though a lot of them), so the technology itself is capable enough. Support is the main issue.

If you use a well-known app along with a MySQL database, then you should be OK for support anywhere. If you have people who know what they are doing, then go with PostgreSQL for instance. If you have more than 100,000 products and heavy traffic, then you'll be able to afford Oracle together with the support costs.

Web Business Managers