Roger Clarke's Web-Site

© Xamax Consultancy Pty Ltd,  1995-2024
Photo of Roger Clarke

Roger Clarke's 'Shopping Cart' Model

The Shopping Cart Model

Roger Clarke **

Original of 20 September 2004; Significantly upgraded Version of 16 September 2009; Postscript of 15 September 2013

© Xamax Consultancy Pty Ltd, 2004, 2009, 2013

Available under an AEShareNet Free
for Education licence or a Creative Commons 'Some
Rights Reserved' licence.

This document is at

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:

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:

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 well-developed 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:

(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:
  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.:
  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:

* 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:

* 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:
  5. provision to the user of the ability to:
  6. where items are not available for prompt delivery, the offer of equivalent or similar items that are currently available

* 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.

Postscript: Patents on Shopping Cart Technology

I've added this postscript, because shopping carts provide a good example of how dysfunctional the patents system is in relation to software. The root causes of the problem are that:

The remarkable thing is that, with the metaphor and techniques well-established by about 1996, and with patents nominally having a reasonably short shelf-life, patent battles are still going on almost 20 years later. See Nullin (2013).

And patent applications are still coming, e.g. on 'Collaborative shopping across multiple shopping channels using shared virtual shopping carts', applied for in February 2012, but only published on 15 August 2013 (20130211953).


Nullin J. (2013) ''Shopping cart' patent troll tries to save itself, gets pounded by Newegg' Ars Technica, 7 September 2013, at

'Collaborative shopping across multiple shopping channels using shared virtual shopping carts', Patent Application us20130211953, at (which appears on Google's site, but can't yet be found on the USPTO's site).

Clarke R. (2004) 'The Economic and Cultural Impacts of the Free Trade Agreement Provisions relating to Copyright and Patent Law' Xamax Consultancy Pty Ltd, May 2004, at

Hall P. (2013) 'Patent Law Broken, Abused to Stifle Innovation' Wired, 26 July 2013, at

Ingraham N. (2013) 'EFF wants software patents to include working code' The Verge, 15 February 2013, at

Bessen J. (2013) 'The patent troll crisis is really a software patent crisis' The Washington Post, 3 September 2013, at

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.

xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 20 September 2004 - Last Amended: 15 September 2013 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2022   -    Privacy Policy