The Shopping Cart Model

Roger Clarke ** Original of 20 September 2004; Significantly upgraded Version of 16 September 2009 Xamax Consultancy Pty Ltd, 2004, 2009 Available under an AEShareNet licence or a Creative Commons licence. This document is at http://www.rogerclarke.com/EC/ShoppingCart.html It provides an overview and resources relating to the pervasive 'shopping cart' model of consumer eCommerce

1. Introduction
Since 1995, a particular approach has been commonly used in web-based online ordering systems. It is referred to using the metaphorical expressions `shopping cart', `shopping basket' or `shopping trolley'. The model requires "software which allows customers shopping on a website to accept product orders for multiple products from the website. This software automatically calculates and totals orders for customers and indicates the total price including post and packing" (Wikipedia). Brief overviews and examples are readily found in text-books (e.g. Lawrence et al. `Technology of Internet Business' Wiley, 2002, pp. 54-54), and examples, demonstration-sites and software packages are readily found on the Web. This paper provides:

background on the shopping-cart metaphor an outline of the shopping-cart process a fuller description of: o the infrastructure on which it depends o the shopping-cart process a list of major feature-variants of shopping-cart processes

2. The Shopping Cart Metaphor

During the first few years of Web-based online selling (c. 1993-96), a range of different approaches were experimented with. By mid-1995, one had emerged as the mainstream. This used the metaphor of a `shopping basket' (UK) or `shopping cart' (US). What distinguishes the shopping cart model from other forms of online ordering is that shopping carts involve the item or items being grouped into a list (called a `shopping cart'), and purchased together via a single process (called `checkout'). A major advantage of the model was the familiarity of the metaphor to consumers. A March 1996 article in the trade journal Web Marketing Today demonstrates that the technique had already matured at that stage, because it refers to many advanced features. A study was undertaken by Spiller & Lohse in July 1996, and published in a leading refereed journal in the Computer Science field in July 1998. The researchers examined 137 Internet retail stores offering women's apparel for sale. They found that "only 30% used a shopping cart metaphor" (pp. 37, 46). Three things about the study are noteworthy:

the buying process was not a primary object of the study, presumably because, when the researchers designed the research in early 1996, they already saw shopping cart systems as 'the plumbing', and an essentially solved problem over 40 of this small sample of Web sites were using shopping-cart software the researchers appear to have been surprised that the proportion was not higher, because they said "only 30% used a shopping cart metaphor"

New initiatives on the Internet were generally readily accessible from anywhere in the world, and Australians were well aware of developments. Australians adopted the shopping cart model for online ordering very early, variously as developers, service-providers and users. Australia lagged in this area by only months behind the leaders overseas, who in the area of consumer eCommerce generally and shopping carts specifically were primarily (but not exclusively) in the U.S.A. The technique was widespread in Australia in 1996. The Internet Archive contains a welldeveloped proprietary shopping basket application used by the Australian PC retailer Harris Technologies, as at 22 December 1996.

3. An Outline of the Shopping Cart Process

This section provides a minimalist description of the conventional method. 1. a web form is provided, which enables a purchaser to select an item, e.g. by clicking on or checking a box displaying the item or a description of the item 2. this action causes the browser to send a request to the server 3. the server uses some kind of state maintenance technique to remember which items the purchaser has selected 4. the purchaser may browse the site and select further items

5. in most implementations, the purchaser has the ability to amend or delete previous selections 6. once the purchaser has completed browsing and selecting items, they proceed to the `checkout' 7. the server presents a page that contains details of the items that have accumulated in the `cart', and enables the purchaser to review them 8. this is generally a web-form, and enables further changes to be made 9. one or more further web-forms are presented to enable payment and shipping details to be captured (or, if already on file, confirmed or amended or over-ridden for the current transaction) 10. finally, the purchaser is generally required to click on a button to affirm that they wish to proceed with the purchase. This form constitutes an order, or, in the terms of contract law, an offer 11. the submission from the browser is processed by the server 12. some form of confirmation is usually sent by the server to the browser, which, in the terms of contract law, represents an acceptance

4. A Fuller and More Precise Description 4.1 Required Infrastructure

The elements of Web infrastructure that are used in a shopping cart process are shown diagrammatically in Exhibit 1. Further technical details are provided in a companion paper on 'The Birth of Web Commerce'.

Exhibit 1: Infrastructural Elements Underpinning a Shopping Cart Process

The user's device (typically a personal computer or PC) runs a category of software referred to as a 'web-browser'. This communicates with the merchant's device, which runs a category of software referred to as a 'web-server'. The web-browser and web-server communicate by means of a communication protocol referred to as HyperText Transfer Protocol (HTTP). The web-server performs the functions necessary to prepare and deliver displayable code to the browser. The web-server does not itself contain the specialised program code or the data that are specific to any particular use of the Web, such as online ordering. That is performed by software commonly referred to as an 'application'. The web-server and application communicate by means of a communication protocol referred to as Common Gateway Interface (CGI).

4.2 The Process

The following description of the process involved in the use of a shopping cart system firstly declares the context within which the transaction commences, and then explains the phases of user selection of one or more items for purchase, the automated processing of the selection, the further actions that the user might take, and finally the processing of the selections that have been made into an order.

(0) The Starting Point

The following are conditions precedent to the use of a shopping cart system by a consumer:

the user has access to a computing device that is connected to the Internet; the device includes a web-browser; the user must have reached the reached a relevant web-page, in particular: o by typing in a web-address (more correctly referred to as a 'URL') o by undertaking a search, and following a link made available by the search-engine o by browsing through a hierarchical menu, and following a link made available in the menu o by clicking on a link that was provided in a web-page or on-line ad

(1) The Display of Items Available for Purchase

A display is presented in the window of the user's web-browser which includes a web form, and: 1. identifies items that are available for purchase. (This is sometimes referred to as a catalogue, although that term is more usefully applied to the complete set of items that a merchant has available for sale); 2. provides enough information about each item to enable the user to select an item or items that they want to buy; and 3. enables the buyer to select an item or items.

(2) The User's Selection Action

1. The user clicks on an area of the screen associated with the item or items that they wish to order (e.g. a 'radio-button' or 'check-box'). 2. This may be supplemented by other actions, such as typing in the quantity of the item or items that they wish to purchase. 3. There may be a need to click on a further area of the screen in order to cause the browser to process the data; or alternatively that may happen automatically, merely by selecting a single item for purchase.

(3) The Processing of the Selection

1. The web-browser sends a request to the web-server, including data that represents whatever the user clicked on and/or typed in.

2. The server passes the data to the relevant application. 3. The application processes the data, perhaps validating the data provided, and noting that the user wants to order an item or items. 4. The application uses some kind of state maintenance technique to remember data about the transaction, such as which items the user has selected. 5. The application passes data back to the server, for transmission back to the user. 6. The web-server passes the data back to the web-browser. 7. The web-browser displays the data to the user.

(4) The User's Further Actions

1. The user may select further items, using the same process described above under 'The User's Selection Action'. 2. The user may be provided with the ability to amend or delete any or all previous selections. 3. The user may do nothing further. In this case, the server and application will eventually abandon the part-completed transaction. This is commonly referred to as 'timing out the session'. 4. The user may be provided with the ability to view all items that they have currently selected. This is commonly referred to as 'display shopping-cart contents'. 5. The user may signify that they are ready to finalise the order. This is commonly referred to as 'proceed to the checkout'.

(5) The Processing of the Order

1. If payment and/or shipping details are already stored by the application, then the application will cause the server and hence the browser to interact with the user in order to: o confirm that the existing details are to be used; o indicate that they are to be amended or replaced; or o indicate that they are to be left in storage but that alternative payment and/or shipping details are to be used for this particular transaction. 2. If the relevant payment and/or shipping details are not already stored by the application, then the application will cause the server and hence the browser to interact with the user in order to capture that data. 3. If validation rules are applied (e.g. to ensure that the expiry date of the credit card has been provided, or that at least one of the State or the Postcode has been filled in), then the application may cause the server and hence the browser to interact with the user in order to capture additional or replacement data. 4. Once payment and shipping details are finalised, the application may cause the server and hence the browser to interact with the user in order to acquire confirmation that the order should now be proceeded with. This commonly requires that the user click on a particular area on the screen. (However, although contract law would suggest that the agreement to buy should be explicit, not all implementations necessarily comply). 5. When that action is performed, the browser passes data to the server and hence on to the application, and the application treats the data as being a valid order.

6. The application may immediately use the credit-card details to seek payment authorisation through the credit-card system. 7. The application will commonly cause the server and hence the browser to interact with the user in order to provide some form of confirmation that the order has been placed (e.g. by display in the browser-window and/or by email).

5. Variations to the Shopping Cart Method

The purpose of this section is to convey the richness of the shopping cart notion. Features are listed that may or may not be implemented in any given shopping cart implementation. They are presented under a succession of sub-headings that reflect the sequence of the online ordering process.

* Prior Acquisition of Customer-Related Data

1. the acquisition of data about the customer, perhaps from existing files, or from the user during a previous visit or as part of a registration process, e.g.: o an identifier, such as name (perhaps with some part of address or year-of-birth), or a customer-code o contact details o profile data (such as age-group, gender, geographical area) o shopping preferences o payment details o shipping details 2. the storage of such customer-related data in the application's database, and its association with an identifier for the user, such that the data can be re-used on future occasions

* Pre-Processing of Item-Related Data

1. the generation of the display of items seen by the user from a database, rather than having it expressed in a fixed HTML file 2. the provision of multiple web-pages containing lists of items that can be purchased, possibly organised into categories 3. the provision of a search facility whereby, for example, users can seek out items that have particular item-numbers, or particular words in their item-descriptions 4. the provision of 'special offers', 'promotions' or 'competitions' 5. the provision of access to more information about individual items, including: o text and images o videos or animations o customer feedback

* Pre-Processing of Customer-Related Data

1. the acquisition of an identifier from the user, e.g. by the user keying it in, from a cookie sent from the device, or by inference from other available data such as the IP-address 2. the acquisition of a password or other shared secret from the user, in order to provide some assurance that the user is indeed that particular customer, e.g. by the user keying it in, or from a cookie sent from the device. (This application of cookies is seriously insecure, but is remarkably commonly used) 3. the use of the identifier to associate the user with previously-recorded data 4. the acquisition of customer-related data from a cookie that has been previously stored in the user's device. (This may be done with the user's knowledge and consent, but is commonly performed surreptitiously) 5. use of the customer data acquired from such sources - possibly in conjunction with data keyed in by the user, data provided by the browser (such as the user's IP-address), contextual data (such as the date and time) and/or inferences from the available data (such as the user's apparent location based on their IP-address) - in particular for: o customisation of the user interface o customisation of the lists of items offered o pre-filling of the web-form o customisation of 'special offers', 'promotions' or 'competitions' (e.g. an offer of a discount for an order-quantity larger than previous orders, or a discount on a new line of product if the user submits the same order-size as before) o display of the customer's order history, i.e. purchases on previous occasions that they have been on the site

* Processing
1. use of various user interface mechanisms, including radio-buttons, check-boxes, or 'active GIFs' (i.e. images that can be clicked on) 2. defaulting to 1 of each or any item that is selected, rather than requiring the user to type a quantity in every case 3. default to the checkout each time that an item is selected (but with provision of the ability for the user to go back and select more items) 4. validation of the data provided by the user - which may be performed within the browser, or only once the data has been passed from the browser via the server to the application including such features as: o preclusion of invalid order quantities (e.g. 3, when they come in packets of 4) o checking the surface-validity of credit-card details, such as whether the expirydate has a valid format, and is in the future o checking the existence of the street-name o checking the correspondence between suburb and postcode 5. provision to the user of the ability to: o select multiple items in one pass (which implies that a further action is needed that has the effect of 'add the selected items to your shopping cart now') o display the contents of the shopping cart o display additional charges such as any taxes, packing and shipping o amend the quantity of any item already in the shopping cart o delete individual items from the shopping cart

amend pre-captured payment and/or shipping data temporarily over-ride pre-captured payment and/or shipping data 6. where items are not available for prompt delivery, the offer of equivalent or similar items that are currently available

o o

* Suspension
1. provision to the user of an option to 'park' the shopping cart and come back later 2. automated timing-out of sessions after a period of inactivity

* Checkout
1. support for multiple languages, currencies, tax-regimes, etc. (commonly referred to as 'internationalisation') 2. acquisition of express consent to proceed with the order 3. the seeking of payment pre-authorisation through the credit-card system 4. provision of an order-confirmation to the user through another channel, e.g. email 5. consolidation into a single delivery-load of multiple orders placed soon after one another

* Conclusion
All of these features were technically feasible from late 1994. Most had been implemented in some merchants' web-sites by 1997. They were all natural things for marketers to do, because they reflected the knowledge about selling that marketers had acquired over the preceding decades.

Author Affiliations
Roger Clarke is Principal of Xamax Consultancy Pty Ltd, Canberra. He is also a Visiting Professor in the Cyberspace Law & Policy Centre at the University of N.S.W., and a Visiting Professor in the Department of Computer Science at the Australian National University.