Ecommerce marketers will have to learn new skills and attitudes to be successful.

by Bob Browning

Electronic commerce is growing rapidly and many merchants are asking themselves how they can benefit from this new technology. This paper provides a grounding in the basic concepts.
September 02, 1999

This paper discusses the technical issues to be considered in planning for electronic commerce.

In order to create a site for Internet sales, most merchants will require electronic commerce software and services to handle catalogue, shopping cart, and payment functions. There are several competing systems on the market, and this paper provides guidelines for selecting a product.

We show that the technical design of the product can affect traffic and therefore business by a factor of three or four. We also identify product features that most sites will require and the intangible issues that users should look out for.

The paper also discusses security and emphasises the need for your security measures to be demonstrated to your customers by the use of SSL.

Finally the paper outlines the procedures for credit card authorisation and payment on-line.

The first stage in developing a business plan for an e-commerce operation is to establish the business requirements. Another paper in this series (Planning for e-commerce: Business Issues) provides some guidelines and checklists for this process. Once the business requirements are documented, the search for products and services to meet these requirements can be started. This paper describes some of the issues to be addressed in the selection process.

No single solution will suit all situations. Some solutions can be immediately eliminated because they cannot cope with international requirements (i.e. the US$ symbol is fixed!). There are also technical issues such as whether the product will run on the desired platform. If you have decided to standardise on Windows NT or Unix then a number of products are eliminated immediately.

Once this type of hurdle is overcome, the issues are going to be:

• Price
• Product Quality (Features / Performance)
• Technical Design

While there will be a trade-off of price against quality, price is an imperfect indicator of the suitability of a particular product for a particular job. If your requirement is fairly standard, then there is no reason why a lower priced product will not be perfectly suitable.

Your catalogue may have many thousands of items in it. You will not want to 'hand craft' thousands of HTML pages to create that catalogue. There are a number of approaches and this section of the paper explains the two main types of software. It also explains how apparently esoteric design details can significantly affect your business.

In our investigation of this area we have found that many of the products – including the high priced ones - are designed in such a way as to limit the ability of search engines to fully index the catalogue. We have analysed the access logs of catalogue sites and found that you can lose 75% of your traffic with certain types of package.

To understand why, you need to know how catalogue systems work and how search engines work. You also need to understand the importance of search engines as a source of traffic and business.

Every book written on Internet marketing emphasises the importance of promoting your Web site to encourage visitors. This includes:

• Registering with search engines.
• Negotiating links with other sites.
• Participating in newsgroups and mailing lists.
• 'Traditional' advertising and PR.

There are numerous organisations and services, ranging from the very practical submit-it service (www.submit-it.com) to companies that will 'register with 200 search engines for $60, or 'register with 400 search engines for $30' or whatever.

Having gone through this process, it is possible to find out where new visitors actually come from by studying a log file called the referrer log.

Experience on Textor Webmasters' existing catalogue sites (which have been widely registered) demonstrates that the major source of traffic is in fact a very few search engines. We reviewed the referrer log files for two catalogue sites, both of which were rather specialised business to business sites. We found that up to 80% of the visitors to the sites come from four major search engines, and in one case 40% came from just one search engine – AltaVista.

This should not be taken to mean that we denigrate the process of registering and promoting a site. This remains an essential process – albeit understanding the law of diminishing returns that applies here.

However the important consequence of this pattern is that 75% of visitors came straight into a product specification page, not into the home page as we had expected. The reason for this was very interesting.

Somewhere on the site would be a product specification containing a sentence such as: "This type 3 widget from General Widget Corp is mainly used for inverted grommet manipulation"

When someone types into a search engine: "type 3 widget grommet" they hit that catalogue page. We have exactly what we want – someone who is interested in this rather unusual subject looking at our page. What is more, because the search was so specific, this was one of the few pages they found.

This study revealed to us how important it is that these detail pages with their multiplicity of technical terms get fully indexed by the major search engines. Had we not done so we would have lost the bulk of these visitors.

Of course this issue is only important when the product descriptions are a rich source of key words. If your product line is very simple or generic it may not apply.

How do you ensure that product descriptions are fully indexed?

The catalogue product must have an architecture that allows search engines to index them - and most do not. To understand this you have to understand how catalogue systems work.

The screens of information that you see when you browse the Web are created by your browser (Netscape / Explorer) from information coded in hypertext mark-up language (HTML). One of the functions of the catalogue system is to create the HTML from the merchant’s product file.

This can be done in one of two ways:

1. A single batch run generates the entire HTML set for the catalogue in one session.
2. A program generates each HTML page as the visitor needs it.

The first method is termed ‘static’ HTML generation, and the other is termed ‘dynamic’ HTML generation.

Most technicians will choose the dynamic HTML method for several reasons. Primarily:

• The Static HTML method only works with Netscape and Explorer versions 2.0+ and thus limits the audience.
• The dynamic HTML method is more flexible.

However the dynamic HTML method has a big disadvantage which normally more than offsets these technical benefits. Such systems rarely get fully indexed by search engines. To understand why, you need to know how search engines index Web sites.

When you type in a search in AltaVista the program refers to a huge index of every site that the system knows about on the Web.

The index is built up by a program called a robot that is constantly going from page to page, following links and building the index with the text that it finds. AltaVista’s robot is called Scooter.

Most robots will not follow links into programs that appear to generate HTML dynamically. This is because the programmers are afraid their robot will be lost in an ‘infinite space’. As each page is explored, theoretically the program generating the site can create more. This process can continue ad infinitum, and the robot is lost. We have checked with the author of Scooter, and established that it will not follow links that indicate that they link to a program with variable parameters. Technically Scooter will not follow a link that has a ‘?’ in it, unless the ‘?’ is at the end of the URL.

The result is that if a catalogue is created dynamically the bulk of the site pages, including those important technical terms, don’t get indexed. A major source of business is lost.

As can be seen there are significant benefits from the use of static HTML. We have tried to work out the technical approach of each product and have included this in the list on our Web site. The majority generate HTML dynamically, only a few generate static (or 'static looking') HTML.

There are situations where static HTML will not meet the requirement. Here are some examples:

• You wish to give each customer their own price list, reflecting agreed discount levels.
• The price structure is such that variable discounts are given. For example two for the price of three on some items.

This type of situation is difficult to cater for if the Web pages are fixed. There are a couple of options:

• Retain the fixed structure but embed variable elements into the HTML. This can be done using a technique called server side includes, or in simpler cases using JavaScript.
• Use a system that generates dynamic HTML, but create a mirror of the site with fixed HTML which is purely there for search engine indexing, and which directs the visitor directly to the 'real site'.

A number of product features may or may not be important in your particular case. This section lists the issues that come up most often in reviewing these products.

Having maximised your traffic from search engines, you might consider an associate program. This offers referring sites commissions on sales as a result of a link from their site to yours.

An associate program is not for everyone. It will involve extra administration and additional marketing. However in the right instance it can be a very effective traffic generator.

Associate programs are becoming more and more common, and if you believe that they may be an option for you, then choose a product that supports them.

For larger catalogues you will need to be able to upload the product file details and download orders to your local in-house system. Web pages and emails will work fine for small systems but once product and orders increase these become expensive.

Product pictures and diagrams are essential to sell most products. Once the volume of products gets above a certain level, then the organisation of the image files becomes an issue. Some products include a very useful media management function.

Any Electronic Commerce system should support the standard credit and debit cards, Visa, MasterCard etc. It should also (for a business site) support purchase orders from account holders.

Note that to accept certain types of UK debit card, an issue date or issue number is required. Most American Electronic Commerce systems will not provide this. UK banks may also ask for a 'valid from' date. They may also ask that the credit card number check digit be validated in the software.

Other methods are relatively unimportant, but additional proprietary standards are a bonus. The most important here are First Virtual and the Cybercash wallet.

For low volume sites a manual process for authorising credit card payments is going to be perfectly adequate. Once volumes increase there may be a need to authorise on-line. This is discussed in a later section.

You may wish to offer discounts for larger orders and the e-commerce system should support this if it is required.

Products may be sold in different models, colours, sizes etc. You should be able to select these at the time of ordering. Some variants may be at a different price (black - £2 extra).

You should be able to cater for this without requiring additional product codes.

An important technical feature is the need to calculate shipping and handling. Many UK businesses have a long list of alternatives, and the product should support these. Shipping may be calculated as a base figure, or a possible base plus a factor depending on weight, value, the number of items, or just quoted on a per product basis.

System screens should refer to VAT – not sales tax. The product files should flag items that are VATable and not VATable.

For a single catalogue the VAT rate can almost always be assumed to be constant for all products. There are very few exceptions to the 17.5% rate at the present time. There is nothing in the VAT system which guarantees that this will always be so, but it is reasonable to expect that within one catalogue the rates are not likely to vary.

Should this happen in the future virtually all of the software will have a problem because there is rarely (if ever) a facility to quote different tax rates for different products. While we see this as low risk at present it is a factor to be aware of.

If a sale is to a VAT registered business in the EU, then no VAT is payable but the merchant must request and receive the VAT number of the customer. The system should allow for this in some way.

You may need to be able to change the language presented to the customer, both in the catalogue and in the payment processing screens. Ideally you should be able to change any word or phrase that the visitor sees. If you can also insert HTML fragments during this change you have much more flexibility in customising the look and feel of the system.

Any catalogue should be able to use the currency symbol of your choice. A few systems may be able to handle full multi-currency. This means that if a customer orders in say French Francs then the amount they see on site is exactly equal to the amount debited to their credit card in that currency.

There are two levels of this feature:

• Multi-currency throughout the catalogue: every item is shown throughout the catalogue in multiple currencies.
• Multi-currency in the shopping cart: The conversion to the customer's currency takes place at the shopping cart stage.

There are difficult issues here, as the currency conversion rates change daily. You need to know every day the rate that will be used to convert to each currency by the bank at some time in the future when they finally process the payment. This requires a daily price update and some way of processing this into the catalogue.

If you have a large number of products it is essential that customers can run a search on the site to find the product they need. The search should throw up a form from which they can order.

Having taken the order, you may want to run a program that is specific to your requirements. For example:

• Having selected a set of games via a shopping cart you may want to give the visitor the facility to download them directly.
• You may want to support unusual payment options or credit card authorisation.
• You may want to customise the 'thank you for your order' screen or confirmation email.

For these options you need to be able to write a custom program and integrate it with the order handling part of the package.

You should be able to configure the shopping cart pages to adhere to your site's colour scheme and branding.

If you wish not only to accept orders, but also to track order progress and fully integrate the Electronic Commerce system with your back office then this can be done. However this will require one of the more costly Electronic Commerce products. Such a tracking system can inform the customer that the order has been processed, goods shipped and so on.

There are a large number of products on offer today, and over the next few years there will be a shakeout with a few important products surviving. This is the typical pattern in all previous computer products and there is no reason why this should be different.

So look for a package that is offered by a major vendor with a large market that can sustain it. Clearly (and sadly) American companies with a vast home market have an advantage here. We expect about half a dozen US companies to dominate and maybe one or two in each European country.

The catalogue has to do more than just list product prices and features. The site must sell. As this area develops, merchants are going to want to have more and more control over the look and the function of the catalogue. For example they are going to want to have pop-up windows with special offers – especially if the customer has been on the site for a long time. Factors like these imply close control over the catalogue site, and the product must allow this. The ‘one size fits all’ philosophy will not do.

A few packages allow you to separate the catalogue presentation from the order entry functions. We at Textor recommend a product that has this feature (Shopsite) and we are currently working on a hybrid site with the catalogue and search generated by a custom program, and order processing by the package. This has given us the flexibility to format the site as we require without being limited by the package-specified layout.

It is possible with this type of system to "commerce-enable" an existing Web site and thus re-use the design work that has gone into it. This process involves setting up a product file, then including "add to order" and "checkout" buttons to the existing Web pages. Separation of catalogue and order processing functions is generally easier to do with a package that uses static HTML as a basis.

The advice we give is always to select the e-commerce system first and then make your decision as to which host to run it on. The selection of a Web server system can constrain your choice of products.

However the issue becomes less relevant as a constraint if the product runs on the major systems such as Linux, BSD Unix, Windows NT etc. This is termed the product's 'cross platform' capability.

The product should be easy to use both for the customer and for the merchant.

• The forms used to collect the information should be well designed and clear.
• If the market is not English speaking, then the ability to change the language is essential.
• The merchant will need to maintain the product file and there should be good quality features to allow the merchant to update on-line using a Web page, or upload product file data.

Security is a key issue today. Your site must be secure to prevent fraud. You also need to be seen to be secure - your customers need reassurance that the information they key into your system is secure and private.

Most packages support the industry standard SSL (Secure Socket Layer) protocol. The SSL protocol encrypts (or scrambles) every message on the network making it extremely difficult for anyone who intercepts the message to extract your customers' information.

With un-encrypted messages it is quite realistic for a hacker to extract messages on the network and scan them for credit card numbers - they are easy to recognise. However as an encrypted message would take many hours to decrypt, even for the largest super-computers, this is no longer an option.

There are several types of encryption methods, of which the one used by SSL (outside the USA) is technically called 40-bit DES encryption. This is the weakest of the protocols in serious use, and there are certainly better ones. However even this protocol is easily good enough to protect credit card transactions - although you may not want to use it to protect a multi-million pound bank transfer!

SSL has one huge advantage over others. It is recognised by Netscape and Explorer browsers and your customer has a visual confirmation that the information is protected. On Netscape this is indicated by a blue key and a blue line, on Internet Explorer it is indicated by a padlock symbol in the status line. Both browsers may optionally throw up an alert box when SSL is in operation.

In order for SSL to work, the software requires that a component called a certificate be issued and installed in the server. The browsers (Netscape and Explorer) will only recognise certificates from a limited set of certification authorities, and in order to get a certificate you have to verify your identity to the certificate issuer. If you use SSL, visitors can query the certificate in their browser and get independent assurance of the identity of the certificate holder. This all helps reassure the visitor.

Other stronger encryption methods have been implemented, for example by banks for on-line banking and by a small number of e-commerce systems. However these are generally implemented using special plug-ins or more commonly Java applets and are not recognised as security systems by the browser.

In this area, confidence is everything. It is not enough to be secure - you must be seen to be secure. The positive confirmation provided by the browser is in our view absolutely essential to give your customers confidence. As the process of education continues, customers will insist on positive confirmation that an industry standard security scheme is in operation, and currently only SSL provides that.

The other security issue is the handling of the credit card information once it is on the server. Look for a hosting company that can provide a firewall to protect the server. Also look for an e-commerce solution that encrypts the payment information on the server for additional protection.

If credit card information is mailed to the merchant, then this should be encrypted using PGP (Pretty Good Privacy) or better.

Any merchant who wishes to collect credit card payments requires an account with a bank. This is called the acquiring bank.

The bank is taking a certain amount of risk. If a merchant gets into financial difficulties, then it is not unknown for the company to continue to receive payments while not shipping goods. In due course those dissatisfied customers will demand a refund (a charge back), which the bank will have to meet. If the merchant is bankrupt then the bank will end up having to meet this liability. Clearly an acquiring bank is going to want to check credit references.

You may already have a bank that processes credit card payments. Your bank may tell you that they will not permit payments to be received from the Internet. There are two possible reasons for telling you this:

• The bank has a firm policy and you do not conform to the parameters.
• You do conform to the requirements of the bank but your representative does not understand the issue.

The bank is in a position to lay down guidelines for the way in which payments may be accepted. These are covered by your merchant agreement.

The UK Banks that accept credit card payments over the Internet require a firewall to be in place protecting credit card information on file. A firewall is a software program or hardware device that filters network traffic to the computer that is running your on-line store. The firewall will restrict traffic to the minimum required to service Web traffic.

Merchants should contact their credit card processor to discuss current guidelines and standards.

In the future it is expected that all banks will accept Internet payments routinely once the upcoming SET (Secure Electronic Transactions) standard is established. This is a new standard agreed between Visa, MasterCard and the industry.

If you require on-line authorisation and possibly payment, then the bank should be able to provide specifications of the link to the bank. Note that this is likely to be an expensive option.

The catalogue has to run on a computer (commerce server) that is permanently attached to the Internet. While many Technology Departments will be enthusiastic about developing this for their company, this will involve a very significant cost.

• The server itself will be a fairly significant piece of equipment.
• Connection to the Internet will require an expensive leased line.
• The Internet Service Provider (ISP) will also make a significant charge to support a permanent high-speed connection.
• The acquiring bank will almost certainly lay down security guidelines, which may involve a firewall.
• Once set up the system must be run and supported on a 24-hour basis. Every line and piece of equipment should be backed up.

The direct cost of such an endeavour (forgetting the internal staff costs) for the first year is likely to be well into five figures, and may be in six. Given the margin on most goods, and the necessity to process the orders and ship the goods, such a site is unlikely to be profitable unless it turns over millions of pounds worth of business.

It is therefore natural to look to a specialist organisation to host the Web site - possibly the organisation that is hosting your marketing site now.

Because of the security requirements imposed by the banks, a merchant server type of operation is not provided by 'run of the mill' Internet Service Providers (ISP). You will probably have to find a specialist.

The most practical way of providing a merchant server environment is for the ISP to bundle the merchant server software in with the hosting as a single package. This has an important consequence. Choose the software and ISP as a package. It is not a good policy to sign up with an ISP for hosting and then start looking for a software package.

If you need on-line authorisation of payments, but do not want to bear the up-front cost of installing a link to the bank, you may want to consider going through an intermediary who can provide this function as a service for a fee.

The way this works is that your on-line store is linked to the service company. The customer is taken to the service company site when they need to make a payment. The intermediary processes the payments for you and charges a fee.

We have listed a number of these credit card processing companies on the Textor Web site.

Questions to Ask:

• Does the service only process data from pre-set forms, not a shopping cart environment?
• Does the service link to a shopping cart environment on your system and just provide the payment mechanism - if so what software is it built to interface to?
• Does the service include shopping cart software, and if so what capabilities does it have (see the section on CSPs below)?
• Can the service obtain authorisation for a credit card payment separately from debiting the card?
• What currencies are supported
• By the service?
• By the bank?
• Is the service provider taking responsibility for the merchant account or is that something between you and the bank?

A number of organisations are setting themselves up as Commerce Service Providers (CSPs).

A CSP will provide the infrastructure required for electronic commerce that may not include hosting the catalogue. The CSP will typically use an industry strength product such as Transact from Open Markets, Inc to provide:

• Shopping cart
• Secure server
• On-line authorisation
• Order progressing functions

The catalogue will be hosted on a non-secure server.

Transact will interface to leading shopping cart systems, and as Open Markets, Inc now own the Shopsite product, this will be interfaced to Transact shortly.

Textor Webmasters Ltd. is not an authorised reseller for any of the Transact-based CSPs, however through our strategic alliances, we can offer this as a service.

There are a large number of software products, and there are difficult issues in selecting the right product for a given situation.

Textor Webmasters Ltd. has selected Shopsite as a product that provides outstanding functionality for a very reasonable price for SMEs. We host this product on a commerce server operated by a company with which we have a strategic alliance.

We believe that this solution is a good one for sites of up to about 10,000 products and say up to 2,000 transactions per month. For larger sites we can arrange other solutions including a Transact based service via our strategic alliances.

The vendors of both Shopsite and Transact (Open Market) are a major corporation with 500 staff and a stock market listing. Their products have a blue-chip customer base.

This Electronic Commerce Tutorial is presented in three sections. Click one of the links below to continue reading.

1. Electronic Commerce Primer
2. Planning for Electronic Commerce: Business Issues
3. Selecting an Electronic Commerce Solution