Check out the new USENIX Web site. next up previous
Next: U-PAI: A Universal Payment Up: Session IV: Standard Payment Previous: Session IV: Standard Payment

Generic Electronic Payment Services: Framework and Functional Specifications

Alireza Bahreman, EIT

Electronic commerce is becoming more popular. Increased demand is beginning to strain the infrastructure. The current solutions are not complete. The question is how we should build a framework for these applications to allow interoperability. One good approach is to identify the set of services necessary for electronic commerce and build these services and supporting infrastructure simultaneously. This work will focus on payment services, specifically transactions that involve peers who exchange values. This is only a subset of electronic commerce.

Alireza does not believe that SET should be the only solution. Payment models other than credit cards should be supported. Even if we only look at SET, it is likely that multiple vendors will add enhancements to it, so multiple solutions are almost unavoidable. The goal is to create a framework that will allow these solutions to interoperate. This will allow innovation, making it possible for new systems to be introduced easily. A framework would present an organized view of the confusion of payment systems to the user. And application developers would not have to rewrite their applications every time a new payment protocol was introduced. Instead, there would be a generic API for payment systems.

In GEPS, there are three layers: applications, services, and resources. Applications use services and services use resources. Any layer can change without affecting the other two layers. Applications come in two flavors: normal, which use services, and specialized, which are part of the payment infrastructure. Some examples of specialized applications are brokers for digital cash, banks, traders, and the government, which might back a payment scheme.

There are five different services: Transaction Management, Capability Management, Preference Management, Payment Method Negotiation, and Payment Interface Management. Transaction Management, used by the other services, is the most basic service. Its responsibilities include logging, maintaining transaction status, failure recovery, etc. Capability Management provides an interface between a user's services and various payment providers. It acts as a layer of abstraction between services and payment systems. Preference Management handles a user's configuration details, e.g. whether to use cash or credit, the maximum amount to spend per day, etc. It can be used to rank payment systems according to user-defined criteria. The purpose of Payment Method Negotiation is to negotiate which payment system will be used between peers. Finally, Payment Interface Management is an abstraction of GEPS for applications which do not wish to become embroiled in all GEPS' details. It presents a uniform interface consisting of configuration, a user's wallet, value transfer, and error handling.

Related work includes UPAI, IBM Zurich's Secure Electronic Market Place for Europe (SEMPER), and Java Electronic Commerce Framework (JECF).

next up previous
Next: U-PAI: A Universal Payment Up: Session IV: Standard Payment Previous: Session IV: Standard Payment
Alma Whitten