The bank exchanges the credit card information you provide for cash account

A third piece of data flow is the shopping cart and the order it creates. You could simply store the shopping cart in memory and move it from page to page as the user shops. This technique depends on keeping every user separate and ensuring there aren’t any glitches on your system. Because you’ll eventually need to generate an order within a database at some point, it’s usually better to store the shopping cart on the server in a database during the entire process. Of course, you need some way to handle abandoned shopping carts when you use this technique. It’s a choice of the complex database solution over the less reliable memory solution.

These three databases: user, product, and orders are essential for any shopping cart application. You don’t actually have to create three databases—you could store all three kinds of data in a single database using well-defined tables. The point is that the user data will likely include more than one table, as will the order information.

It’s also a good idea to determine how to track the user data. Many shopping cart applications rely on cookies, which is a great technique to use until you want to interact with a user who has cookies turned off. Some shopping carts retain user information in a database on the server and use an iden-tifier such as the Session ID to track the user. The advantage of this method is that the user doesn’t require any special browser support to use it. Unfortunately, using this approach means that the header contains identifying information (such as the Session ID) that the server won’t remember from session to session. A few shopping cart applications rely on a mix of both client- and server-side track-ing, which makes the code very complex, but also benefits from the advantages of both environments.

Getting the Payment