Client: Első Mobilfizetés Elszámoló Zrt.
MFF system is a general mobile payment system, being unique in the world, which contributed to the rapid spreading of the new payment solution within our country significantly. The system is able to handle a complete payment process within one application in case of tasks following such diverse business logic as parking, ticket purchase or car wash.
Tasks:
Első Mobilfizetés Elszámoló Zrt., who is the market leader mobile payment company of our country and the strategic cooperative partner of our group of companies, left its mark on the inland market with mobile payment in public premises. After the project reached serious success on the international market as well, the staff of the company decided to introduce this well-working business model to other fields of the market. Our group of companies was called upon to solve its technical implementation, and that is how MFF came into being.
Implementation:
The Multifunctional Interface (hereinafter called MFF) is a software, developed according to unique requirements. Its primary function is the implementation of payment with mobile phones in case of any of the four mobile network operators (EME Zrt., Telenor, T-Mobile and Vodafone) of Hungary.
MFF plays a central role in mobile payment transactions. Thanks to its unique solutions, it can communicate simultaneously with the IT system of EME Zrt. (hereinafter called MOPA) as well as the unified system of the Hungarian operators (Telekom, Telenor, Vodafone), operated by Cellum Zrt. (hereinafter called CMPS).
The base of the system is a server running in a VMWare ESC virtual environment. The advantage of this is that it can be moved easily and quickly to another virtual environment, possibly running on a stronger hardware, within a very short time. The system was placed behind an advanced Cisco firewall-system, making the server and the software almost invisible for the external attacks. All the necessary ports and IP addresses are set one by one, manually, by the system administrator. The adjusted parameters are unique and are only used by the given function or interface. These settings also mean restriction, since every setting refers to a given internal or external IP address. In case of moving or transposition every connection must be verified.
The applied technologies as well as the software products running on the server use open source code.
Operating system: LINUX Debian Lenny (2.6.26-2-686 GNU/LINUX)
WEB server: APACHE 2.1
Database: MySQL 5.1
Programming language: PHP 5.2.6
The system was established for the transaction of SMS based purchases. We configured the SMSC channels with the operators one by one, through which the system can send and receive SMS messages. Solutions applied here differ in case of every operator. The three different SMSC connections use three different SMSC communication languages (Telekom: EMI, Telenor: HTTP, Vodafone: CMI2). Since the creation of communication interfaces would have taken a long time, we use an external solution for the management of SMSC connections: an open source code SMS gateway software running on LINUX system, called Kannel. The Kannel is able to manage many different SMSC connections simultaneously.
When designing the system, the main aim was to have a modular structure and the main processes working separately from each other, though, working from one common database.
The following parameters were also important:
- full range logging
- operation without data loss
- project-oriented operation
- simple expandability
If an external partner would like to offer the possibility of mobile payment for purchasing his services, then this payment model is treated as a project in the system.
Projects in the system are important, since assigning telephone numbers and implementing business logic (BULO) is different in case of every project.
For the implementation of mobile payment it is necessary to debit the mobile account balance of the clients. Debiting the balance can happen in two ways. If the customer is an EME client, we debit through the MOPA system, and we debit through the CMPS system in every other case. The deposit account of the client is handled by the service supplier, the operators or EME in both cases. Charging the deposit account and invoicing is beyond the range of MFF.
It was necessary to create a communication protocol both on the MOPA and the MFF side for debiting the custumers’ deposit account. The interface is communicating with XML based, bound structural message forms. Communication is realized within the EME server room on LAN connection with TCP/IP connection through SSL encrypted channel under TLSV1. This form of SSL does not need the installation of a certificate on the client side.
In case of debiting the deposit account of a customer having a mobile account, we are sending WSDL based Soap calls to the CMPS system on encrypted HTTPS channel. WSDL is describing the public interface of the web service. This is an XML based service description about communication with the web service, namely, about protocol bonds and message formats, which are necessary for using the web service. Supported operations and messages are defined in this.
Operation:
The central role of MFF is very important in mobile payment transactions from the point of view of external partners, customers and service suppliers as well. One of the most important elements of the system is the full range transaction logging. The incoming and outgoing messages, the parameters and messages of the communication with external partners, as well as every data of the financial transactions are stored. Every data which arrive, go through or get sent on every channel is stored.
EzeketThese data can be checked through a central software. Queries can be posed in a table form, organizing data into modules. There is also a possibility for setting filter criteria.
There is a separate interface available for external partners. In case of every single project web FrontEnd is created, which is implemented according to unique requirements. Here the list of financial transactions can be checked, which is stored in the system for the partner project. In case of web interfaces the IP address of the user is also registered in the system. In this way, people who want to cause or did cause a possible damage, can be easily looked up and banned.
Functional elements:
We divided the operation into four main elements. These four elements are resident separately, constantly running in the memory. These elements form the heart of the system.
Based on these pieces of information it is obvious, that we are not talking about a common, simple system, and that is why it is important to have accurate, clear and fully evolved descriptions and requirements in case of every order.
Most of the above mentioned projects could also be implemented by applying NFC or QR codes.
MFF is prepared on code level for either NFC or QR code based payment processes as well, for which we are shortly about to introduce our own private label hardware products to the market.
Year of implementation 2011
PayTech © 2014