Secure Mobile Payment Architecture

Secure Mobile Payment Architecture

Models of electronic payment systems

There are several different electronic payment systems. All of them have the same basic purpose of facilitating the transfer of value among different parties.

Players. Electronic payments involve a payer and a payee. The intent of the payment is to transfer monetary value from the payer to the payee. Transfer is accomplished by an electronic payment protocol.

Payment models. We classify payment systems according to the flows of information between the players. Figure 2 lists, without claiming completeness, the four most common payment models and their information flows.

Design of the generic payment service

Scope and terminology. The main functionality of any payment system is to provide value transfer services consisting of the following:

Moving electronic value from a payer to a payee. The players may specify certain security attributes for this value transfer.

Moving electronic value back from payee to payer in a payment reversal.

Converting "real money" into electronic value ("loading") or vice versa ("deposit"); the former is relevant only in the cash-like model. (Pfitzmann, Waidner, 2006) In addition to purses and transactions, we use a separate entity called the payment manager to manage the overall operation of the generic payment service. Each player will have one active payment manager managing its purses and transactions. Information services permit the retrieval of information on the state of the payment manager or a specific purse, for example, a list of previous transactions or statistics on all payments received and made in a certain period of time.

Each transaction is associated with a longer-lived transaction record where all relevant information about the transaction is maintained. Some of the services are distributed over more than one entity (e.g., information services are provided jointly by the payment manager, purses, and transaction records). (Pfitzmann, Waidner, 2006)

Design overview. To define each of the above services more concretely, we adopted the following approach. For a given class of services (e.g., value transfer services):

Identify the primitives for this service that are common to most payment systems. Describe these in the form of a base service interface. For example, the ValueTransferServices(n24) interface contains primitives such as pay. (Pfitzmann, Waidner, 2006)

Then for each payment model, identify any additional primitives not already covered in the base interface but common to all payment systems of that model. Describe these in the form of a subinterface. (Pfitzmann, Waidner, 2006)

To introduce a new model, a new (possibly empty) subinterface will have to be defined for each service interface. In the next subsection, we describe the services interfaces in detail. (Pfitzmann, Waidner, 2006) The Value Transfer Services interface has model-specific extensions. The adapter for a given payment system should implement the branch of the ValueTransferServices interface corresponding to the model of that payment system. (Asokan, Steiner, Waidner, 2007)

Services. The primitives of the value transfer services interface are described briefly in Table 1. Primitives for other services are similar. We do not show them here for lack of ...