Solution Components

Let's look at the solutions to meeting each of the requirements listed previously.

Building an Online Catalog

We already have a database for the Book-O-Rama catalog. However, it will probably need some alterations and additions for this application. One of these will be to add categories of books, as stated in the requirements.

We'll also need to add some information to our existing database about shipping addresses, payment details, and so on.

We already know how to build an interface to a MySQL database using PHP, so this part of the solution should be pretty easy.

Tracking a User's Purchases While She Shops

There are two basic ways we can track a user's purchases while she shops. One is to put her selections into our database, and the other is to use a session variable.

Using a session variable to track selections from page to page will be easier to write as it will not require us to constantly query the database for this information. It will also avoid the situation where we end up with a lot of junk data in the database from users who are just browsing and change their minds.

We need, therefore, to design a session variable or set of variables to store a user's selections. When a user finishes shopping and pays for her purchases, we will put this information in our database as a record of the transaction.

We can also use this data to give a summary of the current state of the cart in one corner of the page, so a user knows at any given time how much she is planning to spend.

Payment

In this project, we will add up the user's order and take the delivery details. We will not actually process payments. Many, many payment systems are available, and the implementation for each one is different. We will write a dummy function that can be replaced with an interface to your chosen system.

Payment systems are generally sold in more specific geographic areas than this book. The way the different real-time processing interfaces works is generally similar. You will need to organize a merchant account with a bank for the cards you want to accept. Your payment system provider will specify what parameters you will need to pass to their system.

The payment system will transmit your data to a bank, and return a success code of one of many different types of error codes. In exchange for passing on your data, the payment gateway will charge you a setup or annual fee, and a fee based on the number or value of your transactions. Some providers even charge for declined transactions.

Your chosen payment system will need information from the customer (such as a credit card number), identifying information from you (to specify which merchant account is to be credited), and the total amount of the transaction.

We can work out the total of an order from a user's shopping cart session variable. We will record the final order details in the database, and get rid of the session variable at that time.

Administration Interface

In addition to all this, we will build an administrator interface that will let us add, delete, and edit books and categories from the database.

One common edit that we might make is to alter the price of an item (for example, for a special offer or sale). This means that when we store a customer's order, we should also store the price she paid for an item. It would make for an accounting nightmare if the only records we had were what items each customer ordered, and what the current price of each is. This also means that if the customer has to return or exchange the item, we will give her the right amount of credit.

We are not going to build a fulfillment and order tracking interface for this example. You can add one onto this base system to suit your needs.