Design of the Payment Service Block

Document #: 221ZR052
Authors: J. L. Abad Peiro, N. Asokan, M. Steiner, M. Waidner (ZRL)
Editor: N. Asokan (ZRL)
Reviewer: DIC, KPN
Status: Draft Version. 4, SEMPER internal
Date: June 14, 1996


The purpose of the payment service block is to provide a unified way to access various different payment systems are available to a user. The design described here is based on the concepts developed in the SEMPER activity paper, 212ZR054: Payment Manager Overview.

An active instance of the payment service block will contain the following objects:

Payment Service Block in Action

Figure 1: A Payment Service Block in Action
(Courtesy Günter Karjoth)

Class and Interface Hierarchies

The following class and interface hierarchies in the architecture are significant ("Abc" is used as the name of an example payment system):

The functionality expected from payment systems is captured in the PurseServices interface hierarchy. The root PurseServices interface contains methods corresponding to services expected from all payment systems. Additional services that are specific to various payment models is captured in sub-interfaces that extend the root interface.

Interface hierarchy: PurseServices

 - PurseServices -+--- AccountBasedPurseServices
                  +--- CashLikePurseServices
These interfaces describe the generic purse services required by the various payment models. These will be implemented by: the PaymentTransaction subclass (see below) corresponding to each payment system of the appropriate model.

Generic purses that are optional are defined separately. An example is the MicropaymentService interface. Each category of optional services will be in the form of a parallel interface hierarchy similar to the PurseServices hierarchy. It is not mandatory for the subclasses of the Transaction class to implement the optional part of the purse services interface.

Class hierarchy: Purse

 - Purse-+--- AccountBasedPurse -+---AbcPurse
         |                       |
         |                       +---....
         +--- CashLikePurse  -------+---....
         |                          |
         |                          +---....

A purse is a repository of information related an installed payment system. As with the PurseServices hierarchy, the Purse class hierarchy has a root class and model-specific subclasses of it.

Class hierarchy: PaymentTransaction

 - PaymentTransaction -+--- AbcTransaction
              +--- ....
Objects of this class hierarchy are the primary objects in the payment service block for providing payment services. A PaymentTransaction object can be thought of as an abstraction of a "transaction." The root class simply provides the functionality of a generic "transaction" (e.g.: methods to abort and to status check). Each payment system is required to have a subclass of the PaymentTransaction class that implement the PurseServices interfaces (both regular and grouped) for its payment model.

Note that we could have abstract subclasses AccountBasedTransaction and CashLikeTransaction and then make AbcTransaction a subclass of one of these classes. We have not done this at this time because there doesn't seem to be a need for it (if defined, such classes would be empty at least as of now). If it becomes necessary, they can always be defined.

Currently, the model-specific functionality provided by the transaction objects is expressed by the corresponding sub-interface in the PurseServices interface hierarchy. Functionality expected from a generic transaction is expressed by the PaymentTransaction class. The adapter of a payment system will subclass the PaymentTransaction class to inherit specifications of the generic transaction functionality and implement the model-specific PurseServices sub interface to inherit specifications of the model-specific functionality. Hence there is no need for the aforementioned intermediate subclasses of PaymentTransaction.

Finally, note that subclass designers should ensure that only methods corresponding to a single transaction are executed on an PaymentTransaction object. (e.g. if someone creates an PaymentTransaction object, invokes pay() on it and then attempts to make another invocation of a purse service on the same object, the second attempt must be disallowed; however multiple invocations of doMicroPayment() or capture() on the same PaymentTransaction object is legal).

Class (hierarchy): PaymentTransactionRecord

Each PaymentTransaction object keeps any data with long-term relevance in a corresponding PaymentTransactionRecord object. Recall that the latter object is the one that is archived after the transaction is complete. Typically, the designer of the adapter for a payment system will subclass the PaymentTransactionRecord class.

Class: PaymentManager

The payment manager object: The PaymentManager class is an implementation of the above.

Incorporating a Payment System into SEMPER

To incorporate a payment system into the payment service block, the following are necessary:

Together, these can be considered to constitute the "adapter" for that payment system. In addition, the following are required:
  • any special business applications: there will be a standard special business application for the payment service block. It would provide generic services to enable user-interaction with the payment service block. For example, it will provide a default way to create a new purse (i.e. by invoking CreatePurse method of the PaymentManager) or to "install" a new payment module into the payment service block. The class PurseManagement provides a set of methods to facilitate the creation and configuration of purses using interaction via Tinguin. Each adapter will have to provide certain standard methods that are used by the PaymentManager and PurseManagement classes. Currently, these are all expected from the subclass of the Purse class. They are:
  • A constructor method,
  • A method init() to initialise the purse during startup, and
  • A method setup() to perform configuration of a purse via user interaction. Default implementations are available in the root Purse class. Also, if a payment system provides more functionality than the what is assumed by the SEMPER payment service block model, special business applications will be necessary to configure, and use such functionality.

    If a payment system does not provide a particular service required by the corresponding interface, the adapter still has to implement a cover method that returns a "not implemented" error/exception.

    Purse Transactions

    For each transaction, there will be a corresponding PaymentTransaction object. The caller would do something like:
    	abcTr1 = (AbcTransaction) abcPurse1.startTransaction(<parameters>);<parameters>);
    Here are some examples of usage:


    Initially at least, only a simple negotiation protocol will be implemented. Messages in the negotiation protocol will be in the form of a list of lists. Each secondary list is used to negotiate the value of a single parameter (e.g. "payment service name"). The head of this list will be an object of the MessageListHead class. It contains the following attributes: The PaymentManager provides various methods such as choosePS and requestPSChoice to negotiate the selection of payment systems. Further, there are methods for local selection as well (for example, based on preferences, or interaction with the user). Different purse selection policies can be implemented by combining these methods in different ways. A pair of methods selectPayingPurse and selectReceivingPurse implementing a particular policy are also provided in the PaymentManager class. Currently, we plan for synchronous negotiations between two payment managers. Later, we may extend this to asynchronous negotiations, and negotiations between two PaymentTransaction objects.

    Interaction with the User

    [to be done]


    Interactions with Other Blocks