© 1998-2005 by Peter Benjamin. All Rights Reserved.

What it takes to do Web Site E-Commerce
February 19th, 2005
By Peter Benjamin

Updated for www.LAMPSIG.org

The E-Commerce Puzzle

Electronic Commerce, the new buzz word of the Internet, that is taking us into the 21st century and reviving the economy across international boundaries like no other technology or industry, is a puzzle, it has many pieces.

But unlike a puzzle it can be "complete" at almost any stage of the development. Complete enough to be in the public eye and ringing up sales. One can conclude then there are many more pieces than needed.

So which pieces are needed?

This paper breaks each pieces into two categories, the basics and additional components, which can be required, highly desired, or optional depending on the situation. A basic component is not necessarily mandatory, but for the typical web store is required.

Listing the pieces? Just too numerous and too interrelated to provide a distinct piece list by priority or need. So here is a core dump. ("Core dump" is a programmer technical term for listing the data in a manner that has order but defining the order defies most laymen.)

There are many separate pieces that takes about two weeks to get them all installed and working. There are alternatives to rolling your own and using a turn key mall web site, or even a site that offers some of the pieces in an easily installed package. Prices are coming down as development costs are paid off and competition forces lowering of prices, sometimes as often as every two months.

A quick note that some web host firms offer turn key E-Commerce. The pieces supplied can range from just a shopping cart CGI script you must install yourself, all the way to you give them a paper catalog and a merchant account id to transfer the funds to, and they do the rest. Prices range from $20 to $1,000 a month. They now seem to be averaging $50 a month which includes a catalog administration web based back end that you enter, delete and change products and prices, as well html template pages for branding.

The first "pieces" detailed below deal with web "pages" involved in web stores or the "front end" graphic user interface (GUI) that the customer "sees." After the web page design issues the software behind the scenes that is needed is expound upon.

E-Commerce Components

To do E-Commerce on the web a basic method has evolved around existing retail methods.

The Basics:

  1. Catalog
  2. Order form
  3. Receipt

Additional web related components are:

The above items are explained in this paper.

Additional business components are:

The Catalog

The product listing or "catalog" as it has come to be called has at least one web page devoted to it for web sites offering 1 to 20 products, for those offering more products may be spread among many pages, some generated from databases, on the fly or

The primary catalog consists of these parts:

  1. a product
  2. a price
  3. ordering information

The pieces appear to be obvious. They can be, but often are not. Here are some hints to designing a catalog page listing products, prices, and the ordering form and finally the receipt reply HTML page after clicking the "submit" button to "confirm" your order.

The Product

Any product for web sales has some components and the more you have the more likely a sale will occur.

The Basics:

  1. Product Name
  2. Product text description
  3. Product image
  4. SKU number

Certainly if more than one product exists on the web site it needs to be uniquely identified. The "Product Name" is a typical method. A description is always desirable. An image is worth a thousand words.

Why is a SKU a "basic?" Large "reliable" companies have them. How do you wish to be "seen?" I consider SKU numbers required for that single reason. There are many others like ease of identifying the product including its size and color, tracking ease, and separating your product lines for ease of market and demographics analysis.

Highly Desirable:

  1. size
  2. color
  3. dimensions
  4. weight
  5. performance specifications (i.e. electronics)
  6. Installation Instructions (i.e. hard drives)
  7. Care instructions (i.e. washing instructions)
  8. guarantee information
  9. return instructions

And each one of these items can sometimes be broken down.

Size: extra tall
Color: brown and tan with yellow strips
Dimensions: 2" height x 10" depth x 14" width opening to ...
       with clearance needed on sides and rear
Weight: Shipping weight, gross weight, maximum load
Performance: 10 Watts RMS with RCA jacks 48 to 20K Hertz
Installation: SCSI Ultra Wide adapter card required
Care: Wash with like colors, tumble dry low
Guarantee: 1 year parts and labor...
Return: For RMA Number contact...

Why are they "highly" desirable?

Some people, not all, or even most, but depending on product, the product will not get a single sale if some of this information is not known.

Imagine a women buying an all cotton dress of exactly her size without knowing whether it will shrink or not. I think not. Or buying clothing without a return policy.

Now the catalog page should not crowded with this "extra" information, and there need not be a page per product, but at least one page for each type of information should be linked to. Washing instructions for all your products might be identical, or you have only three different sets of instructions for dozens of products. A single page can give the three instruction sets and group the "product name" or "sku number" to the set.

Compact, concise information that is easily navigated is what will ease the buyers' need for additional information before they buy.

The Price

The price has to be easier than the product, right?

Lets look at it's components:

The Basics:

  1. Currency (i.e. US Dollars, British pound, ...)
  2. Item Price
  3. Taxes: Country, State, County, City
  4. Shipping
  5. Handling

Other price components:

And we can go into payment methods:

  1. COD - (local home delivery)
  2. cash - rare for Internet orders (local lunch)
  3. check - personal, business, out of town
  4. money order
  5. bank draft
  6. faxed check image
  7. debit card - risky
  8. credit card
  9. electronic check
  10. electronic funds transfer
  11. PayPal
  12. many others

Then, there are payment delivery methods:

Do some of these look like they are the same? In some cases they are not.

And of course, the "exchange rate!" And out of the country shipping costs, and changes in countries' shipping and tariff rates...

Ordering Form/Information

Now this is the easy one, ..., right?

It can be as easy a mailing address or as complex as an application requesting fairly complete financial status information with deposit required. (Super computer usage, electronics parts ordering, custom manufacturing, searching databases, government, ...)

E-Commerce is being used in all sorts of areas a typically web browser never gets into.

Industry has rapidly been "webifying" its' paper forms into web pages. Simply putting product information online is not enough any more. Clients need to order and do so in "RUSH" mode. That means instant credit or a minimum deposit or credit history built up with the seller.

The Basics:

  1. Your contact information (at least 2 methods, if not 3)
  2. Shipping method(s)
  3. Customer Information
  4. Customer Funding Information

For a receipt to be "legal" in the United States it needs two pieces of information about the seller. The name they do business under and an address are required. Might as well put that on the order form page as well.

For ease of the customer contacting you providing them with a specific "question and trouble" contact point is important. A large reliable company has this plain to see. Many sharp buyers pass on the web sites where this information can not be easily found "before" entering the ordering information.

The customer support phone number should be on every page, and not hidden down at the page bottom with small text. Having the support phone number at the top and bottom of every page means the customer never has to search the web site for it. The address could be included with the phone number at the bottom of each page.

Getting the product to client is important. Their address is not always required like for electronic downloads, but for demographic analysis, especially regarding any marketing efforts you make, is important for future public relationship expenditures.

Being able to contact the customer after the purchase to confirm unusually orders (multiple boxes, split orders, heavy packages, correct the shipping address, increased shipping costs authorization, postponed shipping, out of stock, and for many other situations demands that "two" methods of contacting them be gotten.

Relying on just one contact method, that has a typo, means you do not have chance of completing the sale.

Now a days most E-Commerce is concerned at the consumer level with credit card information.

The Basics:

  1. Exact Name
  2. Credit card number
  3. Expiration Date

Other Information:

  1. billing address - sometimes used by "Value Added" validation services
  2. Name on billing address - can be different from card name
  3. card type (i.e. visa, mastercard, amex, ...)

Why is card type listed last? It is defined by the credit card number's first two digits. "41..." is always a visa card. So is "43..."

The expiration date consists usually of two values, the month and the year. Some validation services require these fields to be exactly what is on the card including any leading zeros (sometimes) and the separating slash. Others are more flexible.

The web form can provide either a single text box of length 6 to fit the up to 5 characters (some web browsers display the box length incorrectly so add room for one more than the maximum), or split the month and year in separate text boxes or even use pull down selections. For the month the values run from 1 to 12.

For the year it runs from the current year to ten years from now, which is the current limit for issuing credit cards. Be aware that a year pulldown box needs to be updated every December to include the eleventh year, which becomes on December 31 at midnight the tenth year. Thinking ahead many forms now list 20 years ahead, and past years are kept on just to avoid editing the form. This becomes inconvient for the customer who typically thinks the current year will be listed first.

Sites with low or no budgets (government, DMV, etc) will have 20 years and past years listed. Firms with full time webmasters will be more user friendly.

The Receipt

After customer enters their credit card information and mouse clicks on the "submit" button usually labeled more meaningfully like

We take your money when you click here!

or other rather to say it is good design to let the web surfer "know" which buttons "commit" and equally important which buttons do not commit them to a purchase (They come across these buttons first so they must be clearly defined as "no sale" buttons.).

The receipt components are:

The Basics:

  1. Your name or business name
  2. Your address
  3. Your contact information (email, phone, fax)
  4. Tracking/Order Number with date/time stamp
  5. Customer Name
  6. Customer Shipping information
  7. Itemized list of purchased products including quantity, color, size, etc.
  8. Subtotal (that is taxable)
  9. Shipping/Handling cost
  10. Overseas shipping additional cost
  11. Tax(es)
  12. Grand Total

Highly Desirable Additions:

  1. Payment method (not including credit card info)
  2. How to get your questions about your order answered
  3. Print this receipt for your records or save the page
  4. Note receipt is suitable for faxing or mailing
  5. Note to include receipt printout with check or money order
  6. Note shipping methods and restrictions

Address information is important to separate out into the following:

  1. Street address
  2. Suite number (line 2 in the United States)
  3. Line 3 of address (optional)
  4. City
  5. State or Province
  6. Postal or Zip code
  7. Country

The separate state and country allow the CGI software to process tax and overseas shipping costs with little error. Lists of states and countries are available as pull down lists, but there can always be a problem with "Other" when your list is not complete.

Postal code is understood every where in the world. Only the United States has a "zip code" so using the more international description of "Postal or Zip Code".

Any receipt to be "legal" in the United States needs two pieces of information about the seller, that is their name they do business under and an address. Adding specific contact information for order status inquiries is important for not only customer satisfaction, but ensuring all orders placed are actually processed and shipped by your firm. Computers are not 100% reliable and an order can slip through the cracks.

When accepting credit card payment as a seller you MUST ship the product within a reasonable time (6 to 12 weeks), otherwise the customer has recourse through their credit card agency who then tends to come down hard on YOU! They yield considerable power of debiting your existing funds in their hands or taking money that comes in without your approval. If you hard nose the credit card company back, then they cancel your merchant account, and refund you the balance. And can add to your credit history the fact they dropped you. That can make it hard to get a merchant account elsewhere.

The Order Number, or Tracking Number, as I prefer to call it, as usually a firm has other ordering methods with their own numbering system, besides web E-Commerce, and web orders, once in house, get a sequential order number that is different from what the web software could assign. So Tracking number is more meaningful to both internal procedures and the client when they call and say "My Tracking Number is ####" and customer support then knows it is a web based order and has a separate in house "order" number that must be looked up to find the status. At least that is how many existing business adding E-Commerce to their existing distribution outlets have set it up.

Why a date/time stamp? This value also goes into the transaction log and relates to the actual computer time of the web server so if the web server is a "transaction" based computer recording all processes and something goes wrong, then cross comparing date and time stamps between the customer receipt, your transaction log, your audit trail log, and the computer logs may be helpful in full recovery of all purchases.

Also, the date/time stamp helps in determining what tax rate is charged (things can change at midnight), what your actual listed prices were on that date, return periods, and other reasons.

The itemized list contains the Product Name (usually a half line), the quantity, and the subtotal for that product. It can also contain the price, sku number, color and size, though fitting all that one line can be difficult and having "broken lines" on a receipt requires more programming, that does not always work to align columns.

Shipping usually requires its own cost. Handling is sometimes left off and just added into the shipping costs. Sometimes handling is its own line item. You can decide.

Calculating shipping costs is tricky. Very carefully evaluate what your true costs for shipping and handling are. If you have a single charge for shipping and someone orders 200, then you could lose big time. Typically solutions are:

  1. base shipping cost on dollar ranges
  2. assign each item its own shipping cost
  3. base shipping cost on weight of product
  4. include the shipping cost in the cost of the item (Illegal in USA)

While #4 seems like an easy way in the United States you can not charge tax on the shipping costs. It is illegal.

In the other three cases the ordering CGI software needs more intelligence. Most web sites are using the dollar range method and having a margin of error of 50 to 100%. The other two methods require each product to have in addition to its "price" and extra value for its shipping cost or weight that the CGI software must sum.

Separating out the overseas shipping cost is not needed when it can added to the existing shipping and handling charge, but to reduce customer calls asking why shipping and handling is so high... The CGI software can test the shipping address to determine if the order is "overseas." Do not use the word "foreign" or "out of the country" as those are ambiguous at best and create backlash at the worst.

Tax need only be charged in the USA and only in the state you are based, but do check your local state laws as it is changing to in some states to whether you have a "presence" in that state or not, and even federal law is looking at that for some types of products. Tax must be charged based on the state that you are shipping to, not who is ordering, typically, again research this for your state AND the state you are shipping too as it now varies. The CGI software can test the shipping address state field for which state is listed.

Having the actually tax rate that is charged (8.75% in Los Angeles which includes federal, state, AND the city tax which differs dramatically from city to city) displayed as a percentage can "help" customers understand why the tax amount is so high. For those not use to the high LA city tax...

Now to something tricky. Using the same shopping cart order form to do all types of payment methods (fax, mail in) is possible if designed from the beginning.

The customer should be presented with a choose to print the finished itemized ordered list, which includes tax and shippings, so the customer can phone in the order, or fax or snail mail the printed order.

So, design your pages with "instructions" or links or different buttons for different ordering methods, just to make it very obvious the payment methods accepted. Offering buttons for these options allows the CGI to reply with custom instructions for completing a phone, fax or snail mail order (i.e. give 800 #, fax number, mailing address).

  1. Client adds to shopping cart (repeat as needed)
  2. Client views shopping cart
  3. Client is "done" shopping
  4. Client views actual "RECEIPT" page.

There are variations on the above scheme. I do not feel any one is "best", but in some cases the shopping cart that is supplied by the web hosting firm can not be changed.

This section concludes the web page core dump. Now, onto the behind the scenes software that tracks the end user through the catalog and accepts ordering information and is commonly called the "shopping cart.:

The Software

The shopping cart is the major piece of software needed when multiple catalog pages are used to display product and allow selection and quantities to filled in. There are other pieces needed in the typical web store. These are discussed first.

Protecting Credit Card Information With Encryption (SSL)

There are two different times when credit card information transmitted over the Internet need protection. The first is when the customer sends it to the web server. The second is when the web server sends it to the validation/debiting computer. The transmissions are handled by different software packages and use different schemas. The software is supplied by different vendors. Both software packages have similarities. Both have two pieces, a client side piece and a server side piece. Each piece is installed by someone different. Confused yet? :-) Let's visit this issue later and look at the actual usage.

One software package is to secure transactions between the customer and your web site.

The customer's web browser, which accepts private credit card information needs to be protected or encrypted before leaving the customer's computer and transmitted over the Internet to the web host computer's web server software. That is, the Internet is other peoples' computers where interception of "clear text" credit card information is what all the news sensationalism is about - over just about nothing, as intercepting a packet with credit card info among millions takes a lot of CPU power - and those that try get caught much more often than the store clerk who steals carbon copies.

This software package has two pieces, one installed in the "browser" will encrypt AND decrypt. It encrypts outgoing information like credit card information to the web server. It decrypts incoming information from the web server like HTML pages and images and any other file requested when in "secure" mode. More on "secure" below. This software installed on the customers' browser is not to be worried about by the web store owner. The second piece is to be worried about.

The second piece is installed on the web store's computer, that is the web server software. This software encrypts AND decrypts. It encrypts outgoing information like HTML pages, images, and any other file requested when the customers' "browser" is in "secure" mode. It decrypts any information coming from the customers' browser.

This second piece is supplied by a third party and requires yet another piece, that is a SSL certificate or "key value". More on those later. For Apache web server a popular SSL layer is call Stronghold. Stronghold supports many different SSL layers, but not all them. There are now many SSL certificate issuers. Verisign and Thawt are the two most popular ones, but GoDaddy.com is cheapest. More on them later.

As a web store owner you must arrange access to both

  1. Web Server Secure Add on (standard with Netscape, IIS, but not Apache).
  2. SSL certificate (you can borrow your web hosts - but... see below)

More on these in their own section. It is important you understand the scope and intent of the above section is to tell you what "pieces" the web store should have, not the precise details. The confusion arises from so many "pieces" (4) doing encryption and decryption (in both directions) for pieces of information, but for the credit card information has the follow happen to it:

  1. Customer turns on "secure" mode (https://url...)
    1. Customers can do this manually for web sites whose secure web server runs in the same web root as the unsecure server
    2. Otherwise, the web page before the credit card entry form must supply a link that has the https link.
    3. In other words it is not enough that the credit entry form have an action=https: URL.
    4. The entry form itself must already have encryption turned on by being an https: URL itself.
    5. This oversight is still found at some web order forms,
  2. Customer enters credit card info into their web browser
  3. Customer's web browser encrypts info and sends it to web server.
  4. Web server decrypts information and hands it to web store CGI
  5. Web store CGI invokes credit card validation software with credit card info
  6. Credit card validation encrypts credit card info
  7. Credit card validation sends encrypted info to validation computer
  8. validation computer decrypts credit card info
  9. validation computer authorizes card and can debit it, otherwise a nightly batch run will do the actual debit.
  10. validation computer encrypts reply (good or fail and failure reason)
  11. validation computer sends encrypted info to credit card validation software
  12. Credit card validation software decrypts reply info
  13. Credit card validation software sends reply info to Web store CGI
  14. Web store CGI replies to user either purchased okay, or failed, perhaps with reason

Steps 1 to 4 have been talked about above and which software handles these steps. That is, SSL web software that is for web servers to talk with web browsers.

Steps 5 to 13 use different software, or CGI library code, supplied by the Credit Card Validation Service Firm (i.e. Cybercash). This software can be web based or other Internet protocol based (TCP/IP), a private communication protocol for even more security. The validation firm supplies your web host firm with a software package to be installed on the secure web server (which runs the SSL web software, too). This software package is used by the Web Store CGI to have the credit card validated and optionally debited. Actions beyond that is not within the scope of this paper.

NOTE: What I have called a "Credit Card Validation Service" firm may not be the actually firm doing the validation, nor the firm doing the debiting. Yes, in most cases at least four firms can be involved! Then, there are the turn key firms that hide all these details from you and just mail you a monthly check.

  1. Credit card company holding customer's money
  2. Merchant Account company holding now your money (the purchase price)
  3. Credit card validation/debiting company (transfers money from customer's account to yours)
  4. Credit Card Validation SERVICE Company (used for web transactions)

Historical Background

The SERVICE firm is "reselling" validation services. Most credit card companies at the beginning of web E-Commerce did not understand the web and wanted no part of it. Instead they wished other companies to take on the risk nor the liability of developing the E-Commerce technology. Cybercash saw this and installed hardware with very secure computer network connections to a few credit card validation/debiting firms that allowed themselves a perceived high level of risk in even hooking their computers to a complete newcomer to the financial banking computer world. It worked and now Cybercash being the earliest entry into the new market they created has the lion's share, especially considering that the debiting firms they connected to, both before and after their success, would not even consider hooking their private computer network to yet another E-Commerce Service firm like Cybercash, thus locking out the majority of potential Cybercash competitors from even entering the business. Going further on this topic is outside the scope of this paper.)

The software package a web store owner needs to worry about are the two pieces installed on their web host server. Each piece is from a different vendor. The first piece is the SSL secure web server that activates the "https:" URL secure mode between the browser and web site server. The second piece is the credit card validation service software that transfer money and is used by the web store CGI.

Both software packages handle the credit card information. One from the customer's browser to web server, and the other from the web server to the validation service.

More information on both these can be gotten from the web sites of suppliers, like for SSL certificates, http://verisign.com, and for the credit card from http://cybercash.com, which has excellent explanations of both with diagrams.

Let's revisit the first SSL secure layer between the customer and the web site.

The customer has a choice as presented by web stores using "SSL certificates." The customer has two links to start finalize their order, that is, to go to the next step of entering their credit card info. One is "unsecure" or to a normal "http:" URL prefixed page or to a "secure" "https:" page (notice the extra letter "s"). The page or CGI is identical, however the web server and web browser now enter a "secure" mode where when ever one sends information to the other the "information" is encrypted by the one sending using a special "encoding key value", usually a 64 to 128 letter text string (like a sentence). The receiving server/browser software then decrypts with a second special "decoding key value." These "key values" must be kept secret. In fact, special install procedures ensure they are secret as the "key values" that are installed are encrypted themselves with the same schema, but different "key values" set by the software vendors by agreement between them before the browser software is shipped.

These "key values" come in pairs to increase security. More information can be found on the web sites regarding public/private key encryption schemes, and is outside the scope of this paper.

This SSL web browser to/from web site server protection is not to be confused with the other step of web stores in validating credit card information and debiting them. This step requires encryption for the same reason and works pretty much the same way.

Shopping Carts

Shopping carts from roll your own, borrow a friend's, use a freeware cart, use the web host's cart service, purchase one to install (comes with added features usually), to mall's that provide you with a password protected catalog administration back end where you enter your product info, prices, etc, and then either select the default web page catalog structure and receipt pages, select among a variety, customized any of the offered selections, or roll your own catalog schema, but using their "substitution" variable values, where they handle everything including getting you a merchant account and telling you how to transfer your money from there to your active business account. The cost can go as high as $5,000.00 for setup and 15% of the gross, not the profit, the gross!

Shopping carts have these components:

  1. add to cart
  2. view cart
  3. checkout - enter credit card info
  4. get receipt

while shopping in the catalog pages on is not allowed to leave via links on the pages as the pages do not linking outside the catalog section. The reason for this is leaving the catalog section will "empty" your shopping cart. That is upon re-entering the shopping area one gets a "new" empty cart every time. The reason for this is http or web was designed to asynchronous or non tracking of the user. Each page is a separate transaction with no knowledge of the previous page. To do a shopping area means special CGI or shopping card software is used to "add" or modify every page served to the customer a special "user id" that is used to track shopping cart additions.

Shopping cart software is complex and features vary a lot.

Catalog Back End Administration

The handling or administration of tens, hundreds or thousands of products on an equal number of web pages is not done manually by most. Instead a database is used and a query to the database produces a web page on-the-fly to send to the customer. The web page content created on the fly includes the products on that page, their current prices from the database, and the tracking "userid" used by shopping cart. Products put onto a single page this way can vary widely by the features supplied by the database and the shopping cart.

  1. just like a hard copy catalog
  2. A query for all items with a keyword in the name
  3. Store specials on the front page can be changed rapidly
  4. Sale items can be changed rapidly
  5. and many other special features

Software that does this is not cheap. Typically it comes with its own shopping cart software that must be used with it and it comes with its own database software or can use existing database software via methods called API, ODBC, JDBC, and other names.

SSL Certificates

They take weeks (6 or more - 3 in ultra rush mode) to get and install. They cost about $300.00 a year and require you to submit much paper work regarding your firm and where it is doing business.

Installation is complex on purpose for added security. Follow instructions step by step and check off on a printed list. Missing one step does not generate an error and you will find out at the end of the installation when testing. The entire process must be started over and can include reinstalling the web server software! So do it right the first time.

Getting/Installing the SSL certificate involves exchanging email over days and web site queries. The likelihood of intercepting all steps by an outside is slim to zero, thus doing it electronic works for high security.

Merchant Accounts

Accepts credit card debits from customers' credit cards. Not all firms offering merchant accounts will allow E-Commerce debiting.

Be sure the merchant account you get will work with the credit card validation service you get software from.

Do not purchase the extra software from the merchant account vendor to do debiting from your business computer. Use your web site debiting ability instead for free!!!

Some credit card validation services and value added resellers now provide all the pieces you need from a single source, that is software and merchant account with the additional benefit of fraud detection, that is attempts during the day of multiple guesses at names and rejecting it when it is finally guessed right.

© 1998-2005 by Peter Benjamin. All Rights Reserved.