transactions (see Figure 2.1): Payment, Value Subtraction, and Value Claim. These primitive transactions define how the engaging parties communicate to one another regarding fund transfer. The details of each primitive transaction are given as follows:
Payment is the interaction between the client and the merchant regarding payment ordering. Payment is considered as a bidirectional action in that the action that client sends a request to make a payment to the merchant is called Payment Request, whereas the action that the merchant sends a message as a payment receipt to confirm the goods delivery to the client is called Payment Response.
Value Subtraction is the interaction between the client and the payment gateway (on behalf of the issuer). As well as Payment, Value Subtraction is a bidirectional action in that, the action that the client requests the payment gateway to deduct the money from her account is called Value-Subtraction Request, whereas the action that the payment gateway sends an acknowledgement of the client’s request that notifies the client whether or not her request has been approved is called Value- Subtraction Response.
Value Claim is the interaction between the merchant and the payment gateway (on behalf of the acquirer). Value Claim is considered as a bidirectional action in that the action that the merchant requests the payment gateway to deposit the requested amount to her account is called Value-Claim Request, whereas the acknowledgement sent from the payment gateway to the merchant regarding the merchant’s request is called Value-Claim Response.

Figure 2.1: Primitive transactions

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

Figure 2.1 depicts the primitive transactions. Note that each arrow represents the direction to which the money is transferred. It can be seen that at the end of each transaction, the money is transferred from the client’s account to the merchant’s one. However, the actual money transfer is performed between the issuer and the acquirer over a banking private network. The tasks of both client and merchant are sending the requests/responses to engaging parties including each other. For example, the client does not transfer the requested amount to the merchant’s account by herself, but actually sends the issuer the request to deduct the requested amount from her account and to transfer it to the acquirer. The acquirer then transfers the requested amount to the merchant’s account.
At this stage, we have provided the necessary background of payment transactions. In the next section, we will present existing electronic payment systems and their classification. Moreover, we will discuss their security and performance issues in details.

Electronic Payment Systems

Existing payment systems can be categorized by considering how money transfer is organized into two categories: account-based and token-based electronic payment systems. The details of these systems are presented in sections 2.3.1 and 2.3.2, respectively.

Account-Based Electronic Payment Systems

In an account-based payment system, money is represented by account (or credit) balance in bank accounts and it is transferred among engaging par- ties’ accounts established with their banks. Generally, account-based payment systems can be divided into two categories depending on payment clearing periods: credit-based and debit-based payment systems.
In a credit-based payment system, a client has credits authorized by her issuer to spend with merchants without being charged any cent from her ac- count during purchases. The credits can be more than the current balance of the client’s account depending on the account standing. To make a pay- ment to a merchant, the client is required to have payment authorization from the issuer, and she is billed periodically e.g. monthly. The examples of this kind of payment systems are a credit-card payment scheme over SSL protocol 19, the payment systems based on SET (Secure Electronic Transaction) protocol 20 and iKP (Internet Key Protocol) , VISA’s 3D Se- cure , Shamir’s web-based payment system using disposable credit-card numbers 20, Mu et al.’s system 21, Huming et al.’s payment system based on bank accounts GCW01, and various kinds of electronic check payment systems 22.
According to a debit-based payment system, a client is allowed to spend the money up to her current balance. The examples of debit-based payment systems are Visa Electron and EFTPOS
It can be noted that the client in both credit and debit-based payment systems is required to have payment authorization from her issuer in every transaction. This may incur high administrative cost, which is not suitable for low-valued transactions.
It can also be noted that the difference between credit-based and debit- based payment systems is only billing periods. Thus, an account-based payment system can operate both kinds of payment transactions by specifying the period when the money is deducted from the client’s account. In particular, one account-based payment system can operate in two modes. That is to work as a credit-based payment system, the client is billed after specified period and she has to pay for the transactions by the due date, whereas to work as a debit-based payment system, the money in the client’s account is deducted immediately after the payment authorization for each transaction has been approved.
In any payment system, the payment protocol plays the most important role. In this thesis, we focus our consideration on the payment protocols and their applicability to wireless environments. In this section, we present SET Mas97 and iKP BGH+00 protocols as examples of account-based payment protocols.

SET and iKP Protocols

SET protocol and its ancestor, iKP protocol, are the most well-known credit- card payment protocols. Three main parties are involved in both protocols: client, merchant, and payment gateway. They interact with one another over the Internet side. The client presents her credit card while purchasing goods or services from the merchant. The merchant is a party authorized by the payment gateway to be a merchant in the payment system. In SET and iKP protocols, the payment gateway can be a credit-card company or the client’s issuer who offers its own credit-card service. Based on the payment model presented in section 2.2, the actual fund transfer is perfor