![[DigLib]](http://www-db.stanford.edu/~testbed/interbib/gifs/dllogo-smaller-xparent.gif)
| |
InterPay:
|
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:
The second goal resulted in the specification of a shopping model, which is divided into three parts, for handling
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/
![[Stanford]](http://www-diglib.stanford.edu/diglib/gifs/stanford.seal56.gif)
![[DigLib]](http://www-diglib.stanford.edu/diglib/pub/logo.diglib.gif){kind=logo}