Development of an Internet Payment Processing System

  • Written By: Ph.D
  • Published: June 17 2002


Early in 1999, the author was asked by E-Bank (, one of his clients, to develop the first Yugoslav Internet payment processing system. This client is a Yugoslav payment processing company that uses BankWorks software by RS2 Software Group ( to process transactions made at ATMs (Automatic Teller Machines) and POS (Point Of Sale) terminals.

Developing an internet payment processing system in Yugoslavia under bizarre circumstances, during bombing raids, and power-cuts, was definitely an unforgettable experience. The system was deployed in September 1999 and has worked ever since without any problems. It has sustained numerous attacks by hackers and would-be intruders.

The system architecture is very similar to the Three Dioxin (3D) model that started to emerge later. 3D model will probably become a de facto standard for transactions on the Internet, when its specification is finalized. The developed software received the Diskobolos 2000 ( award in the finance category - an annual award granted by the Yugoslav Informatic Alliance. This article describes a success story that is worthwhile sharing with a wider audience.

E-Commerce Applications

Before we proceed any further, we have to distinguish two types of transactions on the Internet:

Transactions of the first type are not performed in real-time. When a card holder submits payment and gets a response, payment is only posted for further processing. Actual authorization of the transaction is performed (manually) at a later time and consequently at a higher operating cost. This is acceptable when delivery of goods and services is slow, e.g., via regular mail. As an example, when the author purchased a book from in August 2000, the order was approved after an hour or so.

The other type of transaction is performed in real-time. When a card holder submits payment and gets a response, payment is completed. Money on the card holder's bank account is earmarked and transfer of money to the merchant's bank account is guaranteed. This type of transaction is required when delivery of goods and services is imminent (e.g., download of software or MP3 files). Despite this requirement, some e-commerce sites use the first type, and deliver goods and services based on an assumed success of authorization in the future. This approach risks losses due unauthorized transactions.

The system described in this article can configurably work in either mode. When it works in the second, fully automated mode, the system interfaces with the BankWorks system in order to authorize transactions. This interface is simple and should be easy to adapt to other systems for authorization.

Business Model

In order to offer the best options (e-commerce application cost vs. sophistication tradeoff) to merchants and card holders, based on the above discussion, a business model of transaction processing has been developed. It divides merchants on the Internet in three groups, depending on their e-commerce application:

  1. Those interested in collecting payments

  2. Those requiring pre-processing and authorization

  3. Those requiring preprocessing, authorization, and post-processing

Merchants in the first group are only interested in collecting (often periodic) payments on their goods and services. The best examples are utility companies and subscription services. Such payments are identical to payments made at some ATMs. A card holder logs on an ATM, selects a merchant (e.g. a phone company), and enters the amount and the payment reference ID (e.g., his/her phone number). Similarly, on the Internet, a card holder can log on the portal of the Internet payment processing company and pay bills. In order to further facilitate the payment process, merchants can, for a fee, keep account balances of their customers in the Internet payment processing system. In such a way, card holders may review their account balances, get a pre-filled payment form, and simply confirm payment.

Note that, merchants do not even need their own web site. Mobtel (, a post-paid mobile phone company, operated in such a way for a brief period of time, when it was redesigned to a more sophisticated e-commerce application (also developed by the author) that includes calculation of promotional discounts and payment pre-processing.

The next group of e-commerce applications has a more complex business logic executed at the merchant's web site. However, these applications do not have/need any automated processing after payment is completed. Delivery of goods and services is based on payment reports available on-line from the processing company. Examples of such applications are Simpaid (, a pre-paid mobile phone company, and Eunet (http://eunet.yu), an Internet service provider. The payment process is shown in Figure 1. The final bill is presented to the card holder on the merchant's site. The information about payment (merchant's name, payment reference ID, and amount) are passed to the payment form on the payment processing site. Here, card holder fills card information and completes payment. Note that confidential card information is protected by SSL (Secure Socket Layer) protocol at the payment processing site, and the merchant does not need SSL on his/her site.

Figure 1.

The last group of e-commerce applications includes all three phases of payment processing: pre-processing, authorization, and post-processing. Pre-processing is performed at the merchant's site and may include collecting information about the card holder, calculation of cost, taxes, discounts, shipping and handling, etc. Authorization is executed at the payment processing site in a form of a remote procedure call made at the merchant's site. Based on success/failure at this step, post-processing is executed at the merchant's site. The purchase order is completed, and goods and services are delivered (e.g., MP3 file is downloaded).

Implementation of such e-commerce applications is not an easy task. A transaction consists of multiple applications executed at multiple computers across the Internet. The chain of events may be broken at any step, at any time, and for any reason (e.g., power failure or communication cable cut). For example, failure after authorization and before post-processing is completed, could leave the card holder's account charged without delivering goods and services. The e-commerce application must have recovery procedures developed so it can either backtrack (e.g., credit card holder's account and cancel purchase order) or finalize order (e.g., deliver goods and services). An example of such application is Atlantik (, an on-line betting company.

System Users

There are three types of users in the system described in this article:

Besides purchasing goods and services on the Internet, card holders may view information about their card accounts using the portal of the Internet payment processing company. This information includes account balance, previous payments, and history of accesses to the account information (for security purposes).

Merchants may view information about their accounts using the portal of the Internet payment processing company. This information includes previous payments made to the merchant, and history of accesses to their account information (for security purposes). Merchants can also change password for access to the account information.

The system administrator of the processing company manages the system using the portal and back-office applications. The administrator may configure in the system database numerous merchant's operational parameters such as type of e-commerce applications, types of cards accepted by individual merchants, appearance of payment receipts, etc. The administrator can use detailed security and access logs to track and locate would-be intruders.

System Architecture

System architecture of the Internet payment processing system is shown in Figure 2. All system components are connected via the Internet. The system has a multi-tier architecture that is typical for applications on the Internet.

Figure 2.

Card holders access e-commerce applications via the Internet. Depending of the type of e-commerce application, card holders may pay through the portal of the Internet payment processing company (first type), partly through the merchant's site and partly through the portal (second type), and entirely through the merchant's site (third type). In the last case, the merchant's site contacts a transaction server to authorize payment. In order to balance the load in the system, there may be multiple transaction servers.

The operating system of the web server (portal) and transaction server(s) is Linux. The web server is Apache with the Jserv module for execution of Java Servlet Internet applications, and the SSL module. We selected this configuration for various reasons. Due to the requirement that the system must work 24 hours a day, 7 days a week, we selected a reliable UNIX-based operating system. Furthermore, 57% of all web servers in the world are Apache, while an additional 3% are Apache derivatives. Also existing third party software for transaction authorization (BankWorks by RS2 Software Group) runs on a Windows NT platform.

All software components developed in this project are based on Java technology, a de facto standard for Internet applications. The latest developments in this technology were closely watched. Software had been often developed using early-access releases so it is ready when the underlying Java technology is officially released. Furthermore, Java is the underlying technology of the Visa Open Platform (VOP) that defines standards for the development of Smart Card applications. Due to portability of Java code, it runs on any contemporary operating system. The software has been tested on Linux, Windows NT, and Windows 95.

The web portal is implemented using standard Java Servlet technology. The application is highly configurable with respect to look and feel. All language related elements such as character-set, text strings, and error messages are also configurable.

The transaction server is implemented as a standalone Java application. Both the portal and the transaction server generate various security and access logs that allow detection and tracking of attackers on the system.

Merchants who use the first type of e-commerce applications are initiated by simply entering information about them in the system database. Since these businesses do not need necessarily a web site, no further development is required.

To facilitate the development of the second type of e-commerce applications, developers are given a template HTML form that contains HTTP payment parameters that are passed from the final bill on the merchant's site to the payment form on the payment processing site, as shown in Figure 1. The developed application has to adhere to the defined convention on passing payment parameters.

To facilitate the development of the third type of e-commerce applications, VPOS (Virtual Point Of Sale) terminal software has been developed. It handles payment authorization in a form of a remote procedure call. The VPOS terminal communicates with an appropriate transaction server using SSL protocol and the strongest commercially available 128 bit key encryption. To achieve even greater security, a VPOS signs data it sends to the transaction server using 32-128 bytes keys.

The VPOS terminal is easy to configure. This pertains to types of cards accepted and transaction servers that handle authorization. Each type of card may be handled by a different server. Also, for greater reliability, for each card type, it is possible to configure a list of alternate servers. In case the first server on the list is out of order, the next one is contacted and so on. The VPOS terminal component is easy to incorporate in an e-commerce application. It is delivered as a set of Java libraries, well documented simple API (Application Programming Interface), and sample code that demonstrates the use of API. If necessary, engineering services can be provided to custom build an Internet store.

Security Issues and Experiences

Even before we started development in early 1999, we knew that the system would be the prime target of hackers' attacks and that security was of the ultimate importance. At that time, the SET (Secure Electronic Transfer) protocol was promoted by Visa. However, development of such a system and its certification at was a lengthy and costly process we could not afford. Besides that, SET is not practical since it restricts card holders to using only computers that are certified for their specific cards. For that reason, we decided to build a proprietary system, and verify card holders using E-PIN (Electronic Personal Identification Number). It turned out that this solution and the entire architecture is very similar to Three Domain (3D) model that started to emerge in 2000, as shown in Figure 3.

Figure 3.

The merchant's identity is verified by the acquirer and the card holder's identity is verified by the card issuer. A transaction in our system is functionally performed in the same way except that the issuer's and acquirer's functions are collocated. We expect that 3D model will be widely accepted when its specification is finalized. Then, depending on available funds, we may decide to separate issuer's and acquirer's functions to two servers and fully comply with the 3D model.

There are two aspects of security that we addressed: protection and prevention. We believe that we addressed both very successfully since none of numerous attacks were successful.

Protection pertains to actions aimed at minimizing the system's vulnerability to attacks when they actually occur. The most basic step is to use 128 bit SSL encryption that protects the system from eavesdropping. In order to protect from fraud with stolen card numbers, we introduced E-PIN. Cards are blocked after a settable number of attempts to enter an invalid E-PIN.

The next step was to build an elaborate system of security/access logs that log all interesting events on all active system ports. Events are ranked according to their importance, and may be filtered and shown in different colors on the administrator's console. The system clock is automatically periodically synchronized with an atomic clock so events can be matched with other logs like those of ISPs.

The final step was to carefully scan the system with a scanning tool in order to detect and replace faulty components of the operating system. If you don't do this, bad guys may do it for you. In the logs we found that the system was scanned by a US company that, guess what, specializes in Internet security. We also captured that local celebrity hackers poked around the system.

Prevention is a set of legal/marketing/media actions aimed at detracting people from even trying to break in the system. As we expected, break in attempts started virtually from day one. Logs contain enough information to locate would-be intruders. Legal actions against them are still not possible, or at least not easy, in Yugoslavia. Laws against crime in information technology are still under development. The legal validity of electronic documents, like logs, is still questionable. In countries where such laws exist, a legal case with good media coverage would greatly contribute to crime prevention and the system's reputation.

Nevertheless, complaints are regularly filed with administrators of offending domains. In the case of ISPs, some were cooperative and cancelled the accounts of offending users. Other ISP administrators do not even bother to respond, especially when attacks came from their own intranets and were most likely carried out by administrators themselves. In one case when an attack came from a university computer center, the offending computer was located, but not the person since students come and go to do their assignments. As a result of the filed complaint, the staff of computer center started to log student IDs and the times they spend working at each computer so any future attempt could be sanctioned.

Finally, the author created a media event by challenging hackers on a news group with a statement that "hackers have to realize that a new sheriff for software has come to town". That instantly provoked an avalanche of daily attacks that diminished after some time. The word about system's reliability and security got on the streets. Now, about one third of all transactions with cards, processed by the processing company, are made over the Internet, and about one half of all active cards are also used on the Internet.


In this article we described author's experience with the development of the first Yugoslav Internet payment processing system. The system has worked reliably and securely since September 1999. Its architecture is similar to the Three Domain model which specification is yet to be finalized.

About The Author

Dr. Dragomir D. Dimitrijevic (http://solair.eunet.yu/~ddimitri) received BS and MS degrees in EE from the School of Electrical Engineering, University of Belgrade, and a Ph.D. in CS from Polytechnic University, Brooklyn, NY. His extensive experience in software development includes working for a number of research and/or development companies/universities in the US and Yugoslavia. He developed various types of software ranging from low level assembly language software to high level applications on the Internet. Currently, he works as an independent consultant. Among other things, he has developed the first Yugoslav system for real-time processing of Internet payments and the first e-commerce applications in Yugoslavia.

The author can be contacted through
E-mail: ddimitri@Eunet.yu
WWW: http://solair.eunet.yu/~ddimitri

comments powered by Disqus