There is a diversity of payment mechanisms, all with different properties and different protocols. This diversity is a large problem for the application developer since applications will need to support all these protocols. All protocols have a general framework in common: the customer pays, some mechanism is invoked which handles the transaction, and the merchant receives the payment.
It would be useful to have an entity, called an Account Handle, that negotiates between the customer and merchant, handling details such as which payment system to use. The Account Handle would act as a proxy between a party and its actual commerce system-specific accounts. An entity known as the Payment Control Record would be used to control the transaction. It consists of a series of records of payment from one party to another. Each record would have transaction and control information. The customer and merchant would talk to the Record and the Record would talk to their Account Handles. Finally, entities known as Monitors will oversee the transaction and notify their owner, either the customer or merchant, through a callback mechanism if the status of a transaction changes. This removes the need for polling and gives the customer and merchant an entity to query about a transaction's status.
The system, which is object/method based, uses CORBA. Each entity has a set of methods which it can perform. Account Handles can create, open, close, or delete accounts as well as performing other maintenance tasks. The Payment Control Record can set the amount, source, destination, authorizations, etc. The Monitor, the implementation of which is left to the application programmer, has several types of status messages which it sends to the application: transaction completion, failure, or still pending. Additional programmer-definable subtypes of these messages can also be used.
This system can be adapted to support the delivery of electronic goods. The methods are the same, but the role of the customer and merchant are reversed. Instead of using an electronic commerce protocol, we would use an electronic delivery protocol.
Work in progress consists of adding more functionality such as support for pay per view, subscriptions, and shareware. Also, existing commerce protocols should be integrated into the system. Finally, security, which is currently absent, will be taken care of in future versions of CORBA.
In response to a question about what UPAI has to do with a digital library, Steve stated that the library needed a method of billing its customers for electronic payment services. Doug Tygar wished to know how this system related to a credit card payment via SSL. Steve responded that this would be just another payment protocol. Another person pointed out that UPAI does not present the user with all the options available in the First Virtual protocol. Agreeing, Steve said that while support for these options could be added, it would require application support as well. In general, the goal is not to support every foible of every protocol. Another question was whether only a few protocols would be in use eventually. Steve believes that there would be more than one protocol in use, so there is value in a common interface. Also, a common interface would make it easy to try new protocols.