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.
Characteristics of electronic payment system are looked from various points of view as technology, user, market and more. [40] [41]
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
Figure 2. 5 Cash base Payment Model
Figure 2. 6 Cheque/Credit card based Payment Model
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.
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.
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,
Figure 2. 7 CEPS Architecture/Model..??
Merchant acquirer, Merchant (POS Device). Card Holder (CEP Card) participating in the CEPS.
The scheme provider is the authority who establish the scheme for electronic purse and is responsible for
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.
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.
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.
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.
The merchant has responsibility for the use of a POS device to accept CEP cards for payment of goods and services.
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,
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:
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:
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 provider discretion. 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.
Figure 2. 8 CEPS Architecture/Model..??
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.
Figure 2. 9 CEPS Architecture/Model..??
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, 
Figure 2. 10 Purchase Transaction
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.
In case of incremental purchase; another debit command along with S2 MAC computed by PSAM, is sent to the card in response to this gets S3 and S6 MAC, reversal purchase; POS device send reversal commands along with S2 MAC and log the transaction details and in case of cancel last purchase additional processing is needed [Section 4.5.4 of 44]
After completion of valid mutual authentication by PSAM the amount of a purchase is added to the total amount for the batch (MTOTBATCH ), and the count of transactions in the batch is incremented by one(NTBATCH ) in batch summary record. The PSAM in the POS device generates a merchant acquirer S5 MAC to complete the transaction and logs the transaction [Table 65, of 45]. PSAM protect count and amount of the transactions in the batch by S4 MAC. This transaction batch is kept in data store of the POS device for transferring to the merchant acquirer [Table 2.2].
Table 2. 2 Batch Summary Record
Field |
Value |
Length (bytes) |
RIDPSAM |
Identifier of the RID owner that assigned the PSAM creator Identifier |
5 |
IDPSAMCREATOR |
Identifier of the PSAM creator |
4 |
IDPSAM |
PSAM Identifier assigned by the merchant acquirer |
4 |
IDBATCH |
Batch Number |
2 |
MTOTBATCH |
Net amount of all transactions (purchases less cancel last purchases) in batch - this includes both aggregated and non aggregated transactions |
4 |
NTBATCH |
Total number of transactions in the batch. This includes a count of all detail transactions plus the NTAGG from each aggregation record. |
2 |
S4 |
MAC - created using the PSAM MAC key - the minimum contents of the S4 are the data listed in this table (excluding the S4 MAC) |
8 |
Table 2. 3 Transaction data Log in POS data store
Field |
Contents |
Length (bytes) |
IDSCHEME |
Usually the AID from the CEP card but may be a reference number |
var |
IDISS,CEP |
Issuer Identifier |
4 |
IDCEP |
Card serial number |
6 |
TIPDA |
Transaction Indicator - set by POS device |
1 |
DTHRPDA |
Date & Time stamp from transaction initiation |
5 |
CNTRYPDA |
Country of the POS device |
2 |
DOMPDA |
Domain of the POS device |
1 |
CURRPDA |
Currency |
3 |
AMCEP |
Authentication method supported by the CEP card |
1 |
NTCEP |
Card transaction number |
2 |
RIDPSAM |
Owner of the RID that assigned the PSAM creator id |
5 |
IDPSAMCREATOR |
Identification of the PSAM creator |
4 |
IDPSAM PSAM |
Identifier assigned by the merchant acquirer |
4 |
IDACQ |
Acquirer ID; usually the actual IDACQ but may be a reference number |
4 |
NTPSAM |
PSAM transaction Number |
4 |
MTOTPDA |
Net value of transaction |
4 |
MPDA |
Value of last increment (either debit or recredit, depending on TI) |
4 |
S6 |
MAC over Issuer-defined data |
8 |
BALCEP |
New Card Balance |
4 |
DDCEP |
Issuer discretionary data |
0-16 |
DEXPCEP |
Expiration date for transaction |
3 |
IDBATCH |
Batch Number |
2 |
VKPCA,ISS,CEP |
Version of the CA Public Key the PSAM must use for card authentication |
1 |
IDREG,ISS |
Identifier of the issuer region - zeros if no region |
4 |
VKPREG,ISS |
Version number of the region public key used to create the issuer certificate |
1 |
CSNISS,CEP |
Identifier of the Issuer’s certificate contained in the card |
3 |
CCPDA |
Transaction status |
2 |
S5 |
MAC – created by PSAM MAC key |
8 |
Periodically, Merchant Acquirer collects the transactions from the POS device’s data store and complete verification of S5, S4 MAC created by the PSAM and consolidation of transactions from multiple POS devices. CEPS does not provide the detail information or procedure for collecting the transaction batch from merchant to merchant acquirer in terms of protocol and the medium for transmission [Section 9.1 of 45] but insist on the minimum data to be transferred, Table 2.2 and Table 2.3.
Possibilities of the different type flows between POS device and Issuer are given in CEPS [Section 4.3.2, 43]. Theses possibilities are depend on the nature, structure and setup of the business by the scheme provider, which may includes intermediate processor between POS device and Issuer. Processing rules and the flows are decided by the scheme provider to deploy smooth operation of the scheme with achieved system security and data integety.
Figure 2. 11 Batch Transfer Transaction
Merchant acquirer sends the transaction to issuer for settlement and managing the fund
Figure 2. 12 Batch Transfer Transaction
pool. Card issuer validates the batch, validate each transaction done by CEP card by verifying S6 MAC and logs the batch. After validation issuer send acknowledgment back to the merchant acquirer. CEPS does not specify any detail in this path also but gives minimum data requirement same as stated in [section xx.xx]
MIT report
Smars IIT Bombay
More transaction of lower value,??
Success of electronic payment system is based on the design principals and its correctness.
Rules, formats, and procedures that have been agreed upon between participating parties are collectively called a protocol. The protocol, then, can contain agreements on the methods used for:
A protocol specification consists of five distinct parts. To be complete, each specification should include explicitly:
1. The service to be provided by the protocol
2. The assumptions about the environment in which the protocol is executed
3. The vocabulary of messages used to implement the protocol
4. The encoding (format) of each message in the vocabulary
5. The procedure rules guarding the consistency of message exchanges
A well-structured protocol can be built from a small number of well-designed and well-understood pieces. Each piece performs one function and performs it well. To understand the working of the protocol it should suffice to understand the working of the pieces from which it is constructed and the way in which they interact. Protocols that are designed in this way are easier to understand and easier to implement efficiently, and they are more likely to be verifiable and maintainable. A light-weight protocol is simple, robust, and efficient. The case for light-weight protocols directly supports the argument that efficiency and verifiability are not orthogonal, but complementary concerns.
A protocol that performs a complex function can be built from smaller pieces that interact in a well-defined and simple way. Each smaller piece is a light-weight protocol that can be separately developed, verified, implemented, and maintained. Orthogonal functions are not mixed; they are designed as independent entities. The individual modules make no assumptions about each other’s working, or even presence. Error control and flow control, for instance, are orthogonal functions. They are best solved by separate light-weight modules that are completely unaware of each other’s existence. They make no assumptions about the data stream other than what is strictly necessary to perform their function. An error-correction scheme should make no assumptions about the operating system, physical addresses, data encoding methods, line speeds, or time of day. Those concerns, should they exist, are placed in other modules, specifically optimized for that purpose. The resulting protocol structure is open, extendible, and rearrangeable without affecting the proper working of the individual components.
A well-formed protocol is not over-specified, that is, it does not contain any nreachable or unexecutable code. A well-formed protocol is also not under-specified or incomplete. An incompletely specified protocol, for instance, may cause unspecified receptions during its execution. An unspecified reception occurs if a message arrives when the receiver does not expect it or cannot respond to it. A well-formed protocol is bounded: it cannot overflow known system limits, such as the limited capacity of message queues. A well-formed protocol is self-stabilizing. If a transient error arbitrarily changes the protocol state, a self-stabilizing protocol always returns to a desirable state within a finite number of transitions, and resumes normal operation. Similarly, if such a protocol is started in an arbitrary system state, it always reaches one of the intended states within finite time. A well-formed protocol, finally, is self-adapting. It can adapt, for instance, the rate at which data are sent to the rate at which the data links can transfer them, and to the rate at which the receiver can consume them. A rate control method, for instance, can be used to change either the speed of a data transmission or its volume.
It is not difficult to design protocols that work under normal circumstances. It is the unexpected that challenges them. It means that the protocol must be prepared to deal appropriately with every feasible action and with every possible sequence of actions under all possible conditions. The protocol should make only minimal assumptions about its environment to avoid dependencies on particular features that could change. Many link-level protocols that were designed in the 1970s, for instance, no longer work properly if they are used on very high speed data lines (in the Gigabits/sec range). A robust design automatically scales up with new technology, without requiring fundamental changes. The best form of robustness, then, is not over-design by adding functionality for anticipated new conditions, but minimal design by removing non-essential assumptions that could prevent adaption to unanticipated conditions.
There are some standard and dreaded ways in which protocols can fail. We list three of the more important ones. Deadlocks — states in which no further protocol execution is possible, for instance because all protocol processes are waiting for conditions that can never be fulfilled.
The principles discussed above lead to ten basic rules of protocol design.
The most frequently violated rule, clearly, is Rule 10.
Design and validation of computer protocol by Gerard J. Holzmann Bell Laboratories Murray Hill, New Jersey 07974
Verification using spin
security of the system at various levels, both for off-line and on-line transaction in CEPS, Authentication and security mechanism is clearly stated in CEPS for purchase transaction between CEP Card and POS Terminal. Authentication and security of the transaction between Merchant and merchant acquirer are kept at the implementers decision.
Transaction between merchant and merchant acquirer is off line transaction and attempt is made here to solve the problem by giving innovative design for this transaction for requirements in Indian payment system stated in section 2.5
Two-way, or mutual, authentication must be performed for off-line transactions is the general requirement in CEPS,
Source: http://www.it.iitb.ac.in/~tijo/seminar/Electronic%20Payment%20System.doc
Web site to visit: http://www.it.iitb.ac.in
Author of the text: indicated on the source document of the above text
If you are the author of the text above and you not agree to share your knowledge for teaching, research, scholarship (for fair use as indicated in the United States copyrigh low) please send us an e-mail and we will remove your text quickly. Fair use is a limitation and exception to the exclusive right granted by copyright law to the author of a creative work. In United States copyright law, fair use is a doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. Examples of fair use include commentary, search engines, criticism, news reporting, research, teaching, library archiving and scholarship. It provides for the legal, unlicensed citation or incorporation of copyrighted material in another author's work under a four-factor balancing test. (source: http://en.wikipedia.org/wiki/Fair_use)
The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.
The texts are the property of their respective authors and we thank them for giving us the opportunity to share for free to students, teachers and users of the Web their texts will used only for illustrative educational and scientific purposes only.
All the information in our site are given for nonprofit educational purposes