A Project in
the Stanford
Digital Library

Public libraries have set many expectations by providing free access to high quality information. However, as budgets are slashed and prices on books and journals continue to rise, this expectation is harder and harder to support. Many libraries now charge a fee for extra services, and of course, the for-profit services and sources need to charge as well. The need for electronic currency was clear, and many rose to the challenge of providing the technical mechanisms to transfer money over the network.

However, none of the newly established vendors was able to become the dominant market player, and several competing standards co-exist, each jockeying for a position in the customer's electronic wallet. InterPay (developed in late 1994 -- early 1995) introduced three layers of abstraction which were designed to insulate the application programmer from the details of a payment mechanism. At the application layer, the only difference between a for-pay application and a for-free one was an additional parameter, the payment agent that was passed from customer to merchant. The merchant made the transition to the payment policy layer, asking an object known as a Collection Agent to collect the amount of the invoice. The collection agent dealt with the customer's payment agent, which implemented his payment policy--e.g., small amounts should be automatically approved, while larger ones required explicit user approval. The payment agent would! then select one of its payment capabilities, such as DigiCash, First Virtual, or NetCheque. At this lowest level, called the payment mechanism layer, the payment capability interacted with the collection capability to effect the transfer and notify higher levels of the outcome.

The implementation of the InterPay architecture showed payments made by the First Virtual system co-existing with payments made through DigiCash and account-based mechanisms.

Improvements to the InterPay architecture led to UPAI, a Universal Payment Application Interface. In addition to a cleaner separation of the payment process from the rest of the application, UPAI specifies an asynchronous process, so multiple payments may proceed in parallel, or an initiated but not yet completed payment may be canceled.

However payment is only one part of the shopping experience, and therefore, we inaugurated a project on "shopping models" which broadened the scope to increase its coverage. The basic architecture seeks two objectives:

  1. Interoperation of existing mechanisms for payment and delivery, and
  2. Flexible specification of customer/merchant interaction without requiring significant software development for each new interaction model (like subscription, pay-per-view, gift certificates, auctions, etc)
The first goal was addressed by using UPAI and a related protocol for delivery called U-DEL to interface with existing payment and delivery mechanisms.

The second goal resulted in the specification of a shopping model, which is divided into three parts, for handling

Proxies to the customer and merchant application are similarly divided into those three parts. An interface (in ISL, an interface specification language similar to CORBA's IDL) describes the functions that each part of the proxies must support. The shopping model acts as a "director" deciding what step to call next based on the current state of the transaction and the most recent message.

The Shopping Models project (initially called InterPay II) started in February of 1996, and is ongoing.

7/29/96: Check out the SEMPER (Secure Electronic MarketPlace for Europe) site at http://www.semper.org

3/17/96: Also see the eCo project from Commerce.Net at http://www.commerce.net/

Note: We have nothing to do with InterPay, Inc. (aside from a few phone calls from their lawyers....). If you're looking for help with automated payroll processing, see their home page.


Shopping Models: A Flexible Architecture for Information Commerce
by S. Ketchpel, H. Garcia-Molina, and A. Paepcke
To appear in DL '97
[Working Paper version]
InterPay: Managing Multiple Payment Mechanisms in Digital Libraries
by S. Cousins, S. Ketchpel, A. Paepcke, H. Garcia-Molina, S. Hassan, and M. Roscheisen
Digital Libraries 95
[postscript, 2.6 MB] added Mar. 20, 1995
UPAI: A Universal Payment Application Interface
by S. Ketchpel, H. Garcia-Molina, A. Paepcke, S. Hassan, and S. Cousins
USENIX 2nd Workshop on E-Commerce
[postscript, 210K] added July 16, 1996

Project Members

[Stanford] [DigLib]