Roger Clarke's '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 
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:
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 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.
- 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
- this action causes the browser to send a request to the server
- the server uses some kind of state maintenance technique to remember which
items the purchaser has selected
- the purchaser may browse the site and select further items
- in most implementations, the purchaser has the ability to amend or delete
previous selections
- once the purchaser has completed browsing and selecting items, they
proceed to the `checkout'
- the server presents a page that contains details of the items that have
accumulated in the `cart', and enables the purchaser to review them
- this is generally a web-form, and enables further changes to be made
- 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)
- 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
- the submission from the browser is processed by the server
- 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'.
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.
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:
- by typing in a web-address (more correctly referred to as a 'URL')
- by undertaking a search, and following a link made available by the
search-engine
- by browsing through a hierarchical menu, and following a link made
available in the menu
- by clicking on a link that was provided in a web-page or on-line ad
A display is presented in the window of the user's web-browser which
includes a web form, and:
- 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);
- provides enough information about each item to enable the user to select
an item or items that they want to buy; and
- enables the buyer to select an item or items.
- 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').
- This may be supplemented by other actions, such as typing in the quantity
of the item or items that they wish to purchase.
- 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.
- The web-browser sends a request to the web-server, including data that
represents whatever the user clicked on and/or typed in.
- The server passes the data to the relevant application.
- The application processes the data, perhaps validating the data provided,
and noting that the user wants to order an item or items.
- The application uses some kind of state maintenance technique to remember
data about the transaction, such as which items the user has selected.
- The application passes data back to the server, for transmission back to
the user.
- The web-server passes the data back to the web-browser.
- The web-browser displays the data to the user.
- The user may select further items, using the same process described above
under 'The User's Selection Action'.
- The user may be provided with the ability to amend or delete any or all
previous selections.
- 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'.
- 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'.
- The user may signify that they are ready to finalise the order. This is
commonly referred to as 'proceed to the checkout'.
- 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:
- confirm that the existing details are to be used;
- indicate that they are to be amended or replaced; or
- 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.
- 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.
- 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.
- 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).
- 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.
- The application may immediately use the credit-card details to seek
payment authorisation through the credit-card system.
- 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.
- 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.:
- an identifier, such as name (perhaps with some part of address or
year-of-birth), or a customer-code
- contact details
- profile data (such as age-group, gender, geographical area)
- shopping preferences
- payment details
- shipping details
- 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
- the generation of the display of items seen by the user from a database,
rather than having it expressed in a fixed HTML file
- the provision of multiple web-pages containing lists of items that can be
purchased, possibly organised into categories
- 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
- the provision of 'special offers', 'promotions' or 'competitions'
- the provision of access to more information about individual items,
including:
- text and images
- videos or animations
- customer feedback
- 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
- 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)
- the use of the identifier to associate the user with previously-recorded
data
- 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)
- 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:
- customisation of the user interface
- customisation of the lists of items offered
- pre-filling of the web-form
- 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)
- display of the customer's order history, i.e. purchases on previous
occasions that they have been on the site
- use of various user interface mechanisms, including radio-buttons,
check-boxes, or 'active GIFs' (i.e. images that can be clicked on)
- defaulting to 1 of each or any item that is selected, rather than
requiring the user to type a quantity in every case
- 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)
- 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:
- preclusion of invalid order quantities (e.g. 3, when they come in packets
of 4)
- checking the surface-validity of credit-card details, such as whether the
expiry-date has a valid format, and is in the future
- checking the existence of the street-name
- checking the correspondence between suburb and postcode
- provision to the user of the ability to:
- 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')
- display the contents of the shopping cart
- display additional charges such as any taxes, packing and shipping
- amend the quantity of any item already in the shopping cart
- 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
- where items are not available for prompt delivery, the offer of equivalent
or similar items that are currently available
- provision to the user of an option to 'park' the shopping cart and come
back later
- automated timing-out of sessions after a period of inactivity
- support for multiple languages, currencies, tax-regimes, etc. (commonly
referred to as 'internationalisation')
- acquisition of express consent to proceed with the order
- the seeking of payment pre-authorisation through the credit-card system
- provision of an order-confirmation to the user through another channel,
e.g. email
- consolidation into a single delivery-load of multiple orders placed soon
after one another
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 US Patents Office adopts an extremely liberal approach to the award of
patents
- the costs of defending lawsuits brought by patent-owners is very high
- the conduct of cases in the courts can be extremely confused and
confusing, and the decisions and ratio decidendi in some cases are not
merely abstruse but also completely baffling. (That comment is based on
experience as an expert witness in 7 patent cases)
- a significant proportion of patents that have no merit are upheld by the
courts
- this has encouraged the emergence of specialist operations that collect
patents, threaten other companies with litigation, and negotiate 'licensing
fees' that are less than the costs the company would face if they sought to
invalidate the patent in court. The term used a century ago was 'patent
sharks', but the more common term now is 'patent trolls'. An excessively
polite term is 'Patent Assertion Entities' (PAEs)
- efforts to reform the US system have failed, because of the market power
of corporations that exploit patents. For recent coverage, see
Ingraham
(2013),
Hall
(2013) and
Bessen
(2013)
- the US has successfully imposed its anti-innovations philosophy in
relation to copyright and patents on the rest of the world, through a variety
of bilateral and multilateral mechanisms
- the Australian government of the day sold out Australia to US interests
when it acquiesced to the US-dictated terms of the Australia-US 'Free' Trade
Agreement
(Clarke
2004)
- Europe is suffering the same innovation-stifling behaviour. See, for
example,
http://eupat.ffii.org/
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
http://arstechnica.com/tech-policy/2013/09/shopping-cart-patent-troll-tries-to-save-itself-gets-pounded-by-newegg/
'Collaborative shopping across multiple shopping channels using shared virtual
shopping carts', Patent Application us20130211953, at
http://www.google.com/patents/us20130211953
(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
http://www.rogerclarke.com/II/FTA17.html
Hall P. (2013) 'Patent Law Broken, Abused to Stifle Innovation' Wired, 26
July 2013, at
http://www.wired.com/insights/2013/07/patent-law-broken-abused-to-stifle-innovation/
Ingraham N. (2013) 'EFF wants software patents to include working code'
The Verge, 15 February 2013, at
http://www.theverge.com/2013/2/15/3992486/eff-wants-software-patents-to-include-working-code
Bessen J. (2013) 'The patent troll crisis is really a software patent crisis'
The Washington Post, 3 September 2013, at
http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/03/the-patent-troll-crisis-is-really-a-software-patent-crisis/
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.
Created: 20 September 2004 -
Last Amended: 15 September 2013
by Roger Clarke
- Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/ShoppingCart.html
Mail to Webmaster -
© Xamax Consultancy Pty Ltd, 1995-2024 -
Privacy Policy
