2.1Electronic Payment System

Electronic payment system is the alternative to the coin or paper based cash payment system to easy the user to make payment for their purchased goods or services over the network or internet and in absence of the physical (entity) presence. Initially cheque in bank payment systems are used to serve the purpose of the same but now in the era of internet and e-commerce paying securely over the internet is important task for the electronic payment system. Currently credit card are also in use for the payments over the network but still users are doubting about trustworthy and the security of their money because of the increase in the frauds [38] which ultimately causes loss of value(money) either of users, merchant or participating banks.

Present electronic payment system are to far from ideal payment system because of the higher transaction cost, more fraudulent activities, and multiple parties are involved in the payment processing simultaneously lacks users acceptance, proper application plans and incompatible standards/specifications. The good payment system should satisfy the user’s acceptance and merchants in the mass scale.

Present electronic payment system can be divided in two group electronic cash and credit/debit system [39] or token based and account based system [40]. Tokens or electronic cash are like the physical cash which represent the value and credit/debit or account based system does not carry value but a message to transfer value.

2.1.1Characteristics of Electronic Payment System

Characteristics of electronic payment system are looked from various points of view as technology, user, market and more. [40] [41]

  • Applicability: acceptance of the user where he/she can use the method to buy goods or services.
  • Easy to use: the system should not be complex particularly in Indian context a user from the remote area should be able to use the system.
  • Security: is concerned with unforgeability of the value(money). Creation, modification and over spending of the value(money) should be protected. Integrity of the value as well as authorization for value should be spent by the concerned user only.
  • Reliability: Smooth running of the system.
  • Trust: degree of the confidence that the money and the personal information is safe
  • Scalability: system should be scalable by timely changes in the underlying infrastructure
  • Convertibility: money conversion may be possible from one method to another like loyalty point convertible to the money
  • Interoperability: system should be operable in between multiple service providers.
  • Efficiency: reasonable cost of the handling micro-payment.
  • Anonymity: is basically privacy to protect the identity of the user
  • Traceability: traceability of the money in the system who and when it occurs with anonymity cause to built trust.
  • Authorization type: whether offline or online transactions can be made in same way.

2.1.2Architecture/ Structure/Model of Electronic Payment System

User a payers always spends the money and the merchant receives the money for the goods or the services he has given to users. In traditional system user spends his own physical money and merchant receives direct physical money no third party come in between transaction but in electronic payment system variety of models are specified by different organization / researchers, which are summarized here.Ahmad-Reza Sadeghi & Markus Schneider, in Electronic Payment Systems[41], presented four types of payment systems electronic cash, Cheque or credit card, Remittance and Debit orders base system.

In cash base transaction users withdraw his e-cash or an electronic token, from the bank where he has his account for this bank debit same amount from users account. User does purchase it as per his requirements and the need by using this e-cash. Merchant receives the e-cash and deposit in bank on his own account. Afterward its merchant bank, who sends the request to user’s bank for transfer of money and deposit in merchant account. Figure 2.5

In Cheque and credit card payment system user stage 1 withdrawal is not present, merchant deposit cheque or credit card slip to bank settlement between banks transfer value in respective merchant account Figure 2.6

In other two types user and merchant give payment order to their respective banks for transfer of money [42]. User bank and merchant banks are called Issuer and Acquirer respectively in [42].

2.2Payment System Standards

MasterCard and Visa international have derived the standards for the global application of smart card in payment system. Initially started with EMV specification in 1996 and subsequently updated with latest version EMV2000, This specifies the specification for Card based on the ISO 7816 compliance, and further specification needed for electronic payment/purse. It also specifies the security criteria for the and authentication methods.

2.3CEPS

The Common Electronic Purse Specifications (CEPS) developed by the Europium country in October 1999 by the CEPSCO, LLC, which define requirements for all components needed by an organization to implement a globally interoperable electronic purse program, while maintaining full accountability and auditability. CEPS states overall system security, certification and migration. CEPS have paved the way for the creation of an open, de facto, global electronic purse standard and has no associated royalty costs.

The lack of interoperability is the single greatest obstacle to the growth of smart cards in payment system. The proliferation of electronic purse programs has resulted in many non-interoperable, proprietary systems. The need for scaleable solutions, international usage and cost-effective ways of implementing programs has highlighted the importance of a globally interoperable set of electronic purse specifications.

CEPS requires compatibility with the EMV (Europay MasterCard Visa) specifications for smart cards and defines the requirements for an interoperable card application, the card-to-terminal interface, the terminal application for point-of-sale and load transactions, data elements, and recommended message formats for transaction processing. CEPS also provides functional requirements for electronic purse scheme participants and uses public key cryptography for enhanced security. CEPS builds on the EMV foundation by extending global interoperability to electronic purse schemes worldwide and is committed to its global proliferation has no associated royalty cost.

Currently, organizations from over 30 countries, representing more than 90 percent of the world's electronic purse cards have agreed to implement CEPS. India is also one of them, who decided to accept CEPS as the national specification for smart card based electronic purse [??]. In addition, over 200 organizations have signed license agreements for CEPS and have received the specifications.

CEPS come in three part Business requirement Specification, Functional requirement Specification and Technical Specification. CEPS was developed with the following goals in the mind.

  • Provide consumers and merchants worldwide with payment products that are faster, easier, less expensive and more convenient than cash, particularly in small value transactions (micro-payment).
  • Provide an interoperable environment for different technology platforms or schemes.
  • Offer merchants a means to offer electronic purse services to both domestic and internationally traveling cardholders.
  • Enable issuers and acquirers to offer international electronic purse services to cardholders and merchants.
  • Ensure that the electronic purse application may coexist with other applications on the same chip to use on Multiplication Card.

2.3.1Electronic Value Transfers in CEPS

  1. Electronic Purse – Merchant: Electronic value may be transferred from an electronic purse card to a merchant terminal/PSAM. (Purchase)
  2. Merchant - Electronic Purse: Electronic value must only be transferred from a merchant terminal/PSAM to an electronic purse card to support a cancel last purchase transaction or a purchase reversal transaction.
  3. Merchant –Merchant Acquirer- System Operators – Networks: Value may be transferred from a merchant terminal/PSAM through to a merchant acquirer, system operator(s) and network(s) as part of the clearing and settlement process. (Transaction Batch Download )
  4. Electronic Purse - Electronic Purse: Electronic value must not be transferred from one electronic purse card to another.
  5. Merchant – Merchant: Electronic value must not be transferred from one PSAM or merchant terminal to another except in environments where a controller terminal acts as a transaction consolidator for other terminals of the same merchant.
  6. Card Issuer - Electronic Purse: Value may be transferred from an electronic purse card issuer to an electronic purse to perform a load transaction.
  7. Electronic Purse - Card Issuer: Electronic value may be transferred from an electronic purse to an electronic purse card issuer to perform an unload transaction.
  8. Electronic Purse - Other Non-Financial Application On the Same Card: Electronic value may be transferred from the purse application to nonfinancial application(s) on the same chip on the card.

2.3.2Payment System (Model..?) in CEPS

A distributed entity model is used in CEPS for electronic payment system. The Figure 2.7 shows entities Scheme provider, Processor, Fund issuer, Card issuer, Load acquirer, Merchant acquirer, Merchant (POS Device). Card Holder (CEP Card) participating in the CEPS.

2.3.2.1Scheme Provider

The scheme provider is the authority who establish the scheme for electronic purse and is responsible for

  • Establishment of the scheme and its Rules & Regulation.
  • Establishing an infrastructure for the overall functionality and security of a CEP system.
  • Establishing policies and procedures to ensure that all transactions are secured
  • Procedure for completion of transaction if other scheme entity is interacting with the own scheme
  • Establishing Certification Authority (CA) for the over all scheme
  • Fraud detection and risk prevention policies and procedures for the scheme
2.3.2.2Card Issuer

It is the main entity responsible for issuing the CEPS card to the cardholder. The card issuer may issue CEP card for more than one CEP scheme.

  • The card issuer has the liability for all value loaded onto the CEP card and the management of the funds pool
  • The card issuer is responsible for monitoring transactions received to ensure that a valid CEP card issued by the card issuer made the transaction.
  • The card issuer authenticates the CEP card for all load transaction
2.3.2.3Fund Issuer

Manages the funds in the card and keeps a log of the transaction. Fund issuer coordinates with the card issuer to load/unload the amount in the card with help of loading device.

2.3.2.4Load acquirer

The load acquirer is the entity responsible for establishing a business relationship with one or more CEP scheme providers & to load the amount in the card in coordination with the card issuer.

2.3.2.5Merchant acquirer

The merchant acquirer is the entity responsible for establishing a business relationship with one or more CEP scheme providers to clear and settle Purchase transaction and also for the creation and distribution of the PSAMs. Merchant acquirer must do the following.

  • Collect and validate all transactions and provide acknowledgments of successful collection to the POS device or to the merchant.
  • Ensure that each batch of transactions is cleared and settled once and only once.
  • Ensure that CA public keys, aggregation parameters, certificate revocation lists and optional blocking lists from the scheme providers are sent to the POS devices.
  • Make payment to the merchant and participate in settlement with the recipient of all transactions forwarded for card issuer processing.
2.3.2.6Merchant

The merchant has responsibility for the use of a POS device to accept CEP cards for payment of goods and services.

2.3.2.7Processor

Normally transaction flows directly from merchant acquirer or load acquirer to card issuer but some times an additional node is added in between merchant acquirer and the card issuer. These nodes are called processors. The processor must do the following tasks,

  • Send transactions to other processors in the agreed format.
  • Participate in a financial transaction with the connecting processors at the time that the transaction is sent or received.
  • Participate in the scheme provider dispute resolution process with connecting processors to resolve any issues related to invalid transactions.
2.3.2.8Card Requirements

The Common Electronic Purse Specifications specifies the requirements of card either single or multi-application card with its business requirement strategy. Either card should be used with in the boundaries of nation or worldwide with single electronic purse or co-exist with other financial and non- Financial application. The following are the card requirements:

  • Card must be contact-based integrated circuit technology with serial number, support system-specific card numbering standards and PIN verification.
  • Card must be able to be authenticated at a load device by the Issuer and point-of-sale terminal by the PSAM.
  • Card must require a form of cardholder identification for electronic value load from accounts in both a proprietary environment and a shared network environment unless loading from cash.
  • Card must support purchase reversal transactions, cancel last purchase transaction capability.
  • Card must support unattended load device
  • Card must be able to support off-line locking and unlocking, enabled at issuer option.
  • Card must able to use multi currency slot, log the transaction. And should have the expiry date
2.3.2.9Point of Sales

Point of sales devise must be user friendly with and able to accept variety of CEPS compliance Cards.Purchase and purchase reversal, incremental purchase, and cancel last purchase transactions should able to process off-line. The following are the card requirements:

  • EMV Compatible
  • Support to have PSAM
  • POS must have Date & Time, display card balance & transaction acceptance key.
  • Place for Revocation list
  • In built communication facility to download transaction to merchant acquirer ?

2.3.3CEPS Security: Authentication Process, Keys & Signature

Security and successful authentication is a prerequisite for the processing of any CEPS card transactions, since it takes place in multi-application environment. CEPS specify the security on loading amount in CEPS card by load acquirer with the help of card issuer which is online transaction and purchase transaction done at merchant place with POS device which is offline transaction; other part security is not defined in the CEPS and kept on the scheme providerdiscretion. For purchase (offline) transaction Two-way mutual authentication between the CEP card and POS terminal is necessary. Asymmetric cryptography is used for authenticating CEP card with PSAM and exchange of secret key. RSA is the public key algorithm chosen for CEPS. Dynamic data authentication is necessary for load, unload, purchase, incremental purchase, and cancel of last purchase. Symmetric cryptography is used for on line transaction to protect the integrity of the data by generating the MAC’s.

Signatures are generated & used at various levels in CEPS transaction to validate the transactions. The card uses a unique diversified secret key, personalized into the card, to generate and authenticate transaction signatures for load, unload, currency exchange, purchase and cancel last purchase transactions. In load & unload transaction S1, S3 are generated by the CEP card for validating transaction data and sends to Card Issuer and Load acquirer respectively. S2 is generated by Card Issuer and sends it to the CEP card.

During purchase CEP card and PSAM authenticate each other and POS device generate PS2 signature and S3, S4, S5, S6 MAC’s generated during purchase transaction.


Batch of each complete POS transaction, which is attached with MAC by the PSAM, is kept in the POS device memory until collected by the merchant acquirer. This batch in POS contains the total count and amount of the transactions for ensuring the integrity by merchant acquirer. The count and amount of the transactions in the batch must be protected by the S4 MAC.

2.3.4Processing

The Fig xx.xx shows an overview of processing take place in the payment system, path 1, 2 and 3 are the transaction between CEP Card & POS, POS & Merchant Acquirer and Merchant Acquirer & Issuer.


2.3.4.1Path-1 : Purchase, Incremental Purchase, Reversal Purchase & Cancel last Purchase Transaction

After inserting CEP Card in POS Terminal, CEP card authenticate it self to PSAM and PSAM to CEP Card using a combination of public key and symmetric cryptography. Value in the CEP card is then adjusted after confirmation from the user. After completion of transaction POS terminal validate the transaction and batch of transaction to store in the POS terminal data store. Figure xx.xx shows detail steps in the purchase transaction. After reset, POS initiate the purchase transaction by selecting the EMV application on the card with specific currency slot, followed by the exchange and verification of certificates to authenticate mutually to each other. After confirmation from the card holder about the value of purchase, PSAM sign data DS using public key of CEP Card (VKPCEP) where DS contain header, amount to be debited (MPDA), session key produced by PSAM for authentication purpose along with hash result of DS Hash [section 10.1.4, of ??], encrypted by private key of PSAM and send to CEP card to debit the amount. In response to debit command CEP Card decrement the amount and return S3 MAC and card issuer S6 MAC to POS Device to validate the transaction completion or return status condition if command fails to debit the value. CEP card also Logs the transaction details.