We now have a complete, functional framework for an online store that can be used in many different situations. This core system has actually been in use since February 1998 on the http://www.ausadultvideo.com.au/ site - but be warned, they sell Adult Videos, CD-ROMs and DVDs, so don't look at it if you don't want to see that sort of thing.
The point of this document is the core functionality of the system, so consequently there are a number of areas that could use improvement:
I have had mixed comments on the navigation this system provides; drop-down lists instead of links, and heavy use of frames. Some people find it convenient and intuitive, and some people hate it.
It is easy enough to set up a shop from scratch using this system, but when you need to add and remove products, it can get confusing given that you have to keep track of product IDs and file names. This can be solved quite neatly by having all your products stored in a database on the server and having the Product Type, Category and Item pages generated on the fly.
It is possible for an opportunistic customer to download a copy of the shop to their PC, modify the prices of the items, and then submit an order in the hope that they will be given discounted and/or free products. This can be solved by having the merchant actually read the order email before shipping the goods, or by storing all the products and orders in a database on the server that only the merchant has access to.
The page on which the customer enters their payment details is not encrypted. This can easily be solved by putting the pages on a sever that supports SSL. If you do not want to have the whole shop encrypted due to the load it will put on your server, you can encrypt only the sendorder.cgi script and modify the final order form to submit to https://someserver/sendorder.cgi.
The other issue with order security is that customers' credit card details are sent via email to the merchant, which is ridiculously insecure. This can be solved by writing a script which PGP encrypts the order before sending it, or by having the orders stored in a database on the server instead of emailing them.
Currently, the only notification the customer receives about their order is a page that says "Thank You". The sendorder.cgi script could easily be modified to send a receipt to the customer as well as to the merchant.
Your comments on this document - be they good or bad - are greatly apprecicated, so please do not hesitate to email me.