Lecture 20: Web Commerce Technologies


Server-Side Programming and Web Commerce

FORM-based Web pages and Web "server-side" programming are the key enabling technologies for Web Commerce. The most common server-side programming technology has been the Common Gateway interface (CGI), commonly using the Perl programming language, but this is gradually changing.

Web sites can sell either tangible goods (merchandise) or content. Important issues include:

Marketing
getting customers to your site, and presenting and selling your product, ultimately convincing them to order something.

Ordering
typically managed by a shopping cart application, see next slide.

Order Processing
check order, verify payment, address, etc. Possibly send customer email confirmation.

Order Fulfilment
packaging, shipping, etc


Shopping Carts

A shopping cart application is a server-side dynamically generated set of Web pages which allow a user to browse items, and add them to their "cart" at the click of a button.

The user can (usually) examine and modify the contents of their "cart". When they are ready, they move to a final "commit" page, where they finalise the ordering process, with (for example) a credit card number, shipping address and an email contact address.

CGI-based shopping
 cart, www.ravenrecords.com.au

Image used with permission of Raven Records, the "THE ULTIMATE IN REISSUES".


State Maintenance -- Hidden Fields

A shopping cart application is more difficult to implement than it may seem. Because the HTTP protocol is stateless, a Web server regards every connection as entirely new, with no relationship to any previous or future connections.

However, a shopping cart application requires persistent state maintenance - each HTML page sent contains information derived from earlier pages.

A hidden field within a form is the simplest way to maintain state. A hidden field is like any other FORM entity; it is simply not displayed by the browser. It can be inspected using, for example, the "View Source" option of the browser, where it will look something like: <input type="hidden" name="sid" value="XYZZY">.


State Maintenance -- Cookies

Whilst hidden fields are a simple technique for state maintenance, they are not a general solution. A cookie is a small piece of information which a server can store "within" a Web browser. For example, the following segment of Perl CGI server-side code sends a cookie to the browser:
print "Content-type: text/html", "\n";
print "Set-cookie: MeLove=Cookie%20Monster", "\n\n"
print "<HTML">;.....rest of Web page
This stores "MeLove=Cookie Monster" with the browser. The following Perl CGI code reads a cookie:
print "Cookie:", $ENV{'HTTP_COOKIE'}, "\n";
Each cookie can have several extra attributes:

Name=Value
this attribute is compulsory, and more than one is allowed. Both "Name" and "Value" can be any ASCII string.

expires=DATE
defines the lifetime of the cookie. Default is the current browser session.

domain=DOMAIN
an Internet domain name to which this cookie may be sent.

path=PATH
defines the subset of URLs within a domain for which this cookie is valid and may be sent.


Security and Cookies

Cookies have caused a great deal of debate. The following are some of the issues:

Some sites with useful information on cookies include:


State Maintenance and Sessions

Most modern Web Commerce sites use the concept of a Web session -- a series of Web requests and responses linked together by a state variable called a session identifier. A first visit to the sites "home page" creates a new session, and the HTTP response is associated with a new session identifier, or SID. All subsequent transactions are labelled with the same SID.


Internet Payment Systems

One of the most difficult issues in Web Commerce is setting up a method of collecting monetary payment. Since the early days of the Web, this has attracted a great deal of theorietical interest (eg, this 1997 PDF report on Micropayments), but in the end the "traditional" payment modes (ie, credit card companies) have mostly dominated.

Approaches to Payment

Use a third-party payment "clearing house" service, eg WorldPay, DirectOne.

Direct merchant relationship with bank -- uses bank-supplied "back-end" software.

"New" approaches, eg PayPal.

Issues

Risk of credit-card fraud

Where is the transaction information stored?

Cost issues: may be as high as 2.5% to 5% of transaction.

La Trobe Uni Logo


Copyright 2004 by Philip Scott, La Trobe University.
Valid HTML 3.2!