2008 International Conference on Computer Science and Software Engineering

A Framework for Mobile Payment Consortia System

(MPCS)
S.Britto R.Kumar
Dept of Comp.Sci. & Applications
Bishop Heber College(Autonomous),
Tiruchirappalli – 620 002, India
brittork@gmail.com
A.Arun Gnana Raj
Dept of Computer Science,
St.Joseph’s College(Autonomous),
Tiruchirappalli – 620 002, India
art_arun06@yahoo.co.in
S.Albert Rabara
Dept of Computer Science,
St.Joseph’s College(Autonomous),
Tiruchirappalli – 620 002, India
a_rabara@yahoo.com

Abstract— Researches in mobile commerce have increased
significantly with the emphasis on identifying new applications,
designing frameworks, and engineering network solutions.
Mobile payment is a natural successor to web centric payments
which has emerged as one of the sub domains of mobile
commerce applications. A study reveals that there are wide
ranges of mobile payment solutions and models which are
available with the aid of various services such as Short Message
Service (SMS), but there is no specific mobile payment system for
educational institutions to collect the fees as well as for student
community to pay the fees without huge investment. This paper
proposes a novel model called Mobile Payment Consortia System
to carry out the transactions from the bank to the academic
institutions for the payment of fees by students through mobile
phone. Mobile Payment Consortia System provides end-to-end
security using symmetric signature scheme while carrying out the
payment transactions. This system increases convenience in
payment processes and reduces transactional cost for both
students and educational institutions. Mobile Payment Consortia
System (MPCS) is a model specifically designed to make
payments and financial services in particular payment of fees by
students from the customer’s bank to the institution’s bank
where they study using mobile device anytime and anywhere.
Keywords- Software Architecture; Framework; Mobile
Consortia; Mobile payment; Secured Transactions
I. INTRODUCTION
The research in software architecture is still an emerging
one with the emphasis on development methodologies,
building theory, models of architecture, quality requirements,
architectural description languages, and verification of
architectural properties. Researchers put on efforts to elicit the
state-of-the art in software architecture research and models of
architectures. Software architecture aims to provide a
framework of a system at the high-level structure. The
framework consists of components and connectors yield the
best design results. The software system’s architecture plays an
important role in system development with various aspects
such as understanding, re-use, construction, evolution and
analyze system property which include system consistency,
dependency analysis, etc., [1]. Software processes are the
activities which are involved in concepts for creating a
framework for the design and development of several
applications such as distributed applications, network
applications, mobile applications, web-based applications.
Mobile Commerce is an emerging discipline that involves
mobile devices, applications, middleware and mobile networks.
Mobile Commerce is a natural successor to e-commerce.
Mobile phones are well suited with mobile commerce to reach
the customers through messages anywhere and at any time.
Mobile Payments are a natural evolution of e-payment schemes
that will facilitate mobile commerce.
A mobile payment or m-payment may be defined, for our
purposes, as any payment where a mobile device is used to
initiate, authorize and confirm an exchange of financial value
in return for goods and services [2]. Mobile devices may
include mobile phones, PDAs, wireless tablets and any other
device that connect to mobile telecommunication network and
make it possible for payments to be made [3].
Mobile payments can become a complement to cash,
cheques, credit cards and debit cards. It can also be used for
payment of bills with access to account-based payment
instruments such as electronic funds transfer, Internet banking
payments, direct debit and electronic bill presentment.
Several mobile payment companies and initiatives in EU
have failed and many have been discontinued [4]. However,
mobile payment services in Asia have been fairly successful
especially in South Korea, Japan and other Asian countries
(e.g., Mobile Suica, Edy, Moneta, Octopus, and GCash). NTT
DoCoMo has 20 million subscribers and 1.5 million of them
have activated credit card functionality in Japan. There are
100,000 readers installed in Japan [5]. The main difference
between successful implementations of mobile payment
services in the Asia Pacific region and failure in Europe and
North America is primarily attributed to the ‘payment culture’
of the consumers that are country-specific [6].
A study reveals that different approaches came to the
market for mobile payment system to address the existing
needs of common man, but a global solution does not exist so
far. Existing electronic payment solutions are not secure
enough, too difficult and slow to use, or available only for a
limited variety of goods or a small selected clientele. In this
paper, we proposed a Mobile Payment Consortia System
(MPCS) framework for Mobile Payment System. This
framework is designed and well suited to the academic
institutions to carry out the payments and financial services in
particular payment of fees by students from the customer’s
bank to the institution’s bank where they study using mobile
device anytime and anywhere.

978-0-7695-3336-0/08 $25.00 © 2008 IEEE 43

DOI 10.1109/CSSE.2008.1514
 The paper is organized as follows: Section 2 presents the
review of the existing models of Mobile payment systems. The
framework for Mobile Payment Consortia System is presented
briefly in section-3. Section-4 illustrates the architectural
Design, the Class diagram and the protocol of MPCS. Section
5 is conclusion.
II. REVIEW
Several studies have been conducted till recently to
implement mobile payment system more effectively in
diversified applications. Different solutions such as bank
driven, mobile network operator driven and independent
payment systems are found in the market [7]. Mobile payment
system models are also classified into theoretical model,
scenario-specific model and open or scenario-independent
model [8]. The theoretical model generally provides a layered
or module-based framework and which illustrates the payment
procedures, principles and security issues in a simplified base
but not a practical one [9,10]. Scenario-specific model could be
classified into disconnected interaction model, server-centric
model, client-centric model and Kiosk centric model [11].
These models mainly consider protocol design where all
entities have interaction with each other in a restricted way of
security challenges. These models focus on application’s
scenario specific and which limits the extensibility. The
solutions namely Mobile 3-D secure, PayBox, Mobile ticket,
Top-Ups all belong to this category. The Open or Scenario-
independent models integrate the legacy infrastructures and
tackle the security and privacy issues [8,12,13]. In order to
achieve security capabilities such as transaction security, entity
authentication, transaction privacy and transaction Integrity,
and anonymity, the protocol designers consider the following
methods: public key infrastructure, symmetric and asymmetric
cryptography and biometry. Recently, most of the protocols
are proposed based on public key infrastructure where the
public-key certificates have to be verified by a Certificate
Authority that requires additional communication steps.
However, asymmetric signature schemes require high
computational power as well as high expensive for computing
the signature and not suitable for mobile devices. Having
studied the existing solutions for mobile payment system, we
propose to design an architecture based framework namely
Mobile Payment Consortia System which integrates the bank,
the institution and the clients to make use of mobile handheld
devices for payments.
MPCS, when the client made a request to the MPCS for
payment service.
MPCS sends an encrypted message to the user for
authentication. The client is authenticated by decrypting the
message using his mPIN number and responds to MPCS in
encrypted format. The MPCS validated the mPIN by
decrypting the user response using his mPIN number. Once
the validation process is completed, mPIN of the user is
mapped to their respective bank and verified with the clients’
accounts. The mPIN of the client is also mapped with the
Institution’s Authentication Server (AS-I) for validation of
request. The MPCS now accept the request of the clients, for
example payment of fees through the mobile device.
In this case, MPCS make a request for payment (PR) to the
client’s bank. The bank authenticates the clients with their
Bank-ID and securing confirmation of the request of MPCS by
the client. Hence the requested amount is debited from the
clients’ account and credited to the bank associated with the
consortia of the institution account by interacting with the
bank. Once the transaction is completed electronically a
confirmation message is sent by the institution bank to the
institutional server.
The institution also confirms the same message to the client
and the request is carried out successfully. The MPCS is
unique for any academic institution to make the students as
their clients and the payment of fees can be done through
mobile anywhere and at any time. The architectural design of
MPCS is depicted in Fig. 1.
Today the mobile payment services are received well and
high level of security must be provided in the design. This
framework is designed with secured messaging system which
includes confidentiality, integrity, non-repudiation and
authentication. The validation and verification of the mPIN of
the MPCS is achieved using secured Symmetric Signature
Scheme. A user normally maintains his or her mPIN number
confidentially in a personal secure environment.

III. FRAMEWORK FOR MOBILE PAYMENT CONSORTIA

SYSTEM (MPCS)
The proposed Mobile Payment Consortia System (MPCS)
provides the necessary technical infrastructure such as
acquiring user information, connectivity, authentication, and
communication to facilitate m-payments and acts as an
intermediary between the banks, the institution and the clients.
This framework is specifically designed for the institution
related payments for the registered clients using mobile
devices. The client must have an account in a bank and the
bank must be registered in the institutional consortia. The client
has an institutional ID with the secured mPIN provided by the
Figure 1. The architectural design

44
 IV. ARCHITECTURAL DESIGN
The MPCS framework designed according to the software
architectural standards is presented in the following sections
and illustrated in Fig. 2.
A. MPCS Client
The mobile users (e.g. students, parents) handle a large
number of heterogeneous mobile devices, nowadays. The user
initiates the mobile payment service by sending SMS request to
MPCS using Payment Service Number (PSN).
For example,
StudId <space>BankId<space>Semester1
The ClientInterfaceManager gets the client request from
various end client devices such as PDAs, wireless mobile
phones, laptops, etc. The DisplayManager maps mobile display
resolution and application services as well as handles the
display issues. The Communication Manager establishes the
communication with MPCS server. It allows the exchange of
information between the access points and also forwards the
messages. The communication manager may have the
accountability on source and destination of communication,
information about communicators, the time at which the
communication is enabled, etc. Other communicational issues
are performance, security and privacy, litigation, etc., which
encrypts and decrypts the client request information that comes
from client mobile device to MPCS server and vice versa by
using symmetric digital signature scheme. The
ConcurrencyManager handles multiple connections at the same
time from concurrent mobile payment service clients. The
concurrency manager keeps the technique of parallelism, which
improves quick response time and reduces the latency period.
The ServiceManager accepts all the client service requests and
creates a session for each service request with the period of
time. The ServiceManager communicates with
AreaTrackingManager to identify the location of the user. This
information may be useful when the payment transaction is
done with nearby user bank. The syntax of the SMS is checked
by ServiceManager. If everything is correct, it checks if user is
registered for the service or not. The authentication of the user
is checked by sending him SMS and asking him to send answer
as well as mapping their mPIN number using
DatabaseManager. The DatabaseManager keeps the records of
all users’ profile including their mPIN number in a encrypted
format. If match is unsuccessful, transaction is aborted and
notification is sent to the user.
Mobile Client (Student & Parent)

have to be considered by communication manager. The mobile Framework

for
payment services are executed in multi-tasking environment, in Mobile Payment
which task switching refers to application switching. To Consortia
respond to the number of user’s queries, the User Interface
System

TaskSwitchingManager keeps the information about

application switching including task ID and application ID. Display Manager

The SynchronizationManager’s main responsibilities are

data synchronization between the client and MPCS server. Communication
Manager
Task Switching
Manager

Data synchronization means the coordination of sending and

receiving of information from the client device to MPCS Synchronization
Manager
Backup Manager

server, and vice versa. During the data synchronization,

SynchronizationManager encrypts the client requests and Device Information
Manager
Security
Manager

decrypts the responds to the client with the help of

Security

SecurityManager. During the device synchronization, it

validates the client device with their application services using Mobile Network Service Providers

DeviceInfoManager. The DeviceInfoManager contains the

information regarding size, display, capability etc., about all MPCS Server

wireless mobile devices and relevant application services that Connection

Manager
Request
Queue Manager

supported by mobile devices respectively. The BackupManager

supports atomic transaction in case of network disconnection. Area Tracking
Data Conversion
Manager
Institution
Server
When the network is disconnected, the failed transaction is
picked up from the restore point and resumes the data, instead Concurrency Manager
Authentication
Server for

of restart again. Institution

Authentication
Server for
Application
B. MPCS Server
Service Manager Client Bank
Manager

The ConnectionManager establishes the connection between

client mobile device and MPCS as well as with other servers Database Manager

(IS, AS-I, AS-B). When SMS arrives in application, first it is

checked for correct syntax using the ServiceManager. The
RequestQueueManager defines a queue for each user’s request
Figure 2. Framework of MPCS
as well as for server’s responses and sends it to
DataConversionManager. The DataConversionManager

45
 If match is confirmed, MPCS authorization request is created D. MPCS Protocol
and sent to Authentication-Server-for-Institution (AS-I) for The protocol illustrated the secured process of mobile
student verification and validation. If the response is positive, payment system
MPCS request InstitutionServer (IS) for student fee details. If Let
the response is negative, proper notification is sent to user. Esp = Encrypts with student PIN number;
Then, MPCS creates payment request to Authentication- Dsp = Decrypts with student PIN number;
Server-for-Bank (AS-B) and checks the user account TranId = T; SecretQn = SQn; SecretAns = Sans
information and account balance. If everything is valid, MPCS
requests AS-B to initiate the payment transaction. The payment 1. C Æ ClientReq(StudId, Transaction) Æ MPCS.
confirmation request is created by AS-B and sent to the user. If 2. TranId = create(TranId(ClientReq(StudId)));
MPCS Æ Esp(T,SQn) Æ C
the user confirms his payment, MPCS communicates with
3. C Æ Dsp (T,SQn); C Æ Esp(T,SAns) Æ MPCS
Client Bank Server (CBS) to transfer the amount to Institution
4. MPCS Æ SAns = Dsp(Esp(T, SAns))
Bank Server (IBS). Here, MPCS uses an interface ISO 8583 to
If SAns exists then {
communicate with banks. At the end, user is notified with SMS CServiceReqId = create(CServiceReqId(T))
about successful or unsuccessful fund transfer through AS-I. CServiceReqId = find(T(ClientInstituteId,
The ServiceManager communicates to the ApplicationManager ClientBankId, ClientAccountNo))
to refer the available applications (other payment services) } else
which are provided by MPCS, if necessary. { MPCS Æ send failure_msg1 ÆT}
The class diagram for this model is presented below (Fig. 3).
5. MPCS Æ validateReq(CServiceReqId, ClientInstituteId) Æ
C. Class Diagram for MPCS AS-I
AS-I Æ X = validateNotice( ) Æ MPCS
If X is valid then {
Class Diagram for MPCS Client
0..* 0..1
Data MPCS Æ FeeReq(CServiceReqId) Æ IS
DeviceInfoManager
BackupManager +DataTag
+Info IS Æ fee = FeeNotice( ) Æ MPCS
+CheckConnectionStatus():Boolean
+DeviceInfo()
+ApplicationInfo()
+TraceLastTransaction()
+Resume()
0..*
Transaction } else
+ResolnInfo() 0..1 +TransactionID
+TransactionInfo
{ MPCS Æ send_failure_msg2 Æ CServiceReqId}

SynchronizationManager 6. MPCS Æ validate(CServiceReqId(ClientAccNo)) Æ AS-B

AS-B Æ Y = AccValidateNotice( ) Æ MPCS
+IsSync:boolean
SecurityManager +SetDataSync(boolean):void TaskSwitchingManager
+Encrypt () +SetDeviceSync(boolean):void +TaskInfo(TaskID,ApplnID)
+Decrypt () +GetDeviceInfo() +TaskSwitchInfo(String)
+ConToSecurityManager()
+ConToDeviceInfoManager()
If Y is valid then {
ClientAccBalance = check
CommunicationManager ClientAccBalance(CServiceReqId)
+IsCommnAlive:Boolean
+CommnEstablished()
If ClientAccBalance > fee {
+CommnDisconnected()
+CommnUserInfo() Send_TransReq(CServiceReqId) Æ AS-B
}
DisplayManager
UserInterfaceManager
+ClientReq( ) Classes } else
+Resolution
+MapApplnWithResoln()
+EncryptMsg( )
+DecryptMsg() Association
{ MPCS Æ send_failure_msg3 Æ CServiceReqId}
+FailureNoteFromMPCS()
+LayerManager(ApplnInfo, Layer)
+PRConfirmationNote() Composition
+PaymentConfirmationMsg()
+DisplayApplnServiceList()
+AbstractApplnServiceCommand()
Aggregation 7. AS-B Æ send_PayApprReq(CServiceReqId) Æ C
Class Diagram for MPCS Server 8. C Æ send_PayApprResp(CServiceReqId) Æ AS-B
ServiceManager
9. If PaytApprResp valid then {
+SMSFormatCheck() AS-B send_PayTransReq(CServiceReqId) Æ CBS
AreaTrackingManager
+EstablishConToASI()
+EstablishConToASB()
ConcurrencyManager
} else
+Validate(CServiceReqId,
+GetSReq() ClientInstituteId)
+FeeReq(CServiceReqId)
+GetUserRequest() { CBS Æ send_failure_msg3(CServiceReqId) Æ MPCS}
+FindUserLoc(SReq) +SessionTIme(CServiceReqId)
+PConfirmationReq()
+FaliureNote()
+EstablishConWithDBM()
+EstablishConApplnManager()
10. CBS Æ Transfer Funds(CServiceReqId) Æ IBS
DataConversionManager
+IsDataAvail:Boolean 11. IBS Æ Pconfirm_msg4(CServiceReqId) Æ AS-I
12. AS-I Æ Pconfirm_msg5(CServiceReqId) Æ C
1 1..*
Application +Encrypt()
ApplicationManager
+Decrypt()
+DispApplicationInfo()
+ListApplications() +CServiceReqId(T)
+EstablishConBank() +EstablishConWithAppln() +FaliureNote()
+ExecuteUserRequest() +SyncAppln() +FindUserLocation()
+UserResponseInfo():Result
V. CONCLUSION
UserRequest 1 1..* RequestQueueManager
+DefineQueue()
ConnectionManager
+ConEstablished()
The SMS based mobile payments are going to remain the
+ClientReq(StudId, Transaction)
+TranId(ClientReq(StudId))
+PushElement():Request
+ConDisconnected() de facto standard for personal payments in the near future.
+PopElement ():Request Mobile Payment Consortia System (MPCS) is a model
Figure 3. Class Diagram for mobile client and MPCS specifically designed to make payments and financial services

46
in particular payment of fees by students from the customer’s
bank to the institution’s bank where they study using mobile
device anytime and anywhere. This system acts as convenient
in payment processes and reduces transactional cost and
overhead time for both students and educational institution.
This model can be extended to all academic institutions so as
to help the necessary payments by the students through mobile
devices.
REFERENCES
[1] David Garlan, “Software Architecture and Object Oriented Systems",
Proceedings of IPSJ, Object-Oriented Symposium, Tokyo, Japan,
August 2000.
[2] Y.A. Au & R.J. Kauffman, “The economics of mobile
payments: Understanding stakeholder issues for an emerging
financial technology application”, Electronic Commerce
Research and Applications, 2007.
[3] S. Karnouskos & F. Fokus, “Mobile Payment: a journey through
existing procedures and standardization initiatives”, IEEE
Communications Surveys and Tutorials. 6(4) 44-66, 2004.
[4] T. Dahlberg et al., “Past, present and future of mobile payments
research: A literature review”, Electronic Commerce Research and
Applications, 2007.
[5] J. Ondrus & Y. Pigneur, “An Assessment of NFC for Future Mobile
Payment Systems”. International Conference on the Management of
Mobile Business, 2007.
47
[6] Mahil Carr, “Mobile Payment Systems and Services: An introduction”,
Mobile Payment Forum, 2007.
[7] Natali Delic, Ana Vukasinovic , “Mobile Payment Solution – Symbiosis
between banks, application service providers and mobile network
operators”, Proceedings of the Third International Conference on
Information Technology: New Generations, (ITNG’06).
[8] Jun Liu, Jianxin Liao, Xiaomin Zhu, “A System Model and Protocol for
Mobile Payment”, Proceedings of the 2005 IEEE International
Conference on e-Business Engineering, (ICEBE’05).
[9] Xiaolin Zheng, Deren Chen, “Study of Mobile Payments System”,
Proceedings of the IEEE International Conference on E-Commerce,
(CEC’03).
[10] Chung-wei Lee, Wen-Chen Hu, Jyh-haw Yeh, “A System Model for
Mobile Commerce”, Proceedings of the 23rd International Conference
on Distributed Computing System Workshops, (ICDCSW’03).
[11] Jesus Tellez Isaac, Jose Sierra Camara, “An Anonymous Account-Based
Mobile Payment Protocol for a Restricted Connectivity Scenario”, 18th
International Workshop on Database and Expert Systems Applications,
(DEXA’07).
[12] A.Vilmos, S.Karnouskos, “SEMOPS: Design of a New Payment
Service”, Proceedings of the 14th International Workshop on Database
and Expert Systems Applications, (DEXA’03).
[13] A.Ramfos, S.Karnouskos, A.Vilmos, B.Csik, P.Hoepner, and
N.Venetakis, “SEMOPS: Paying with Mobile Personal Devices”, Fourth
IFIP Conference on e-Commerce, e-Business, and e-Government (I3E),
Toulouse, France, 22-27, August 2004.