Introduction
Early in 1999, the author was asked by E-Bank (http://www.e-bank.co.yu),
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 (http://www.rs2group.com)
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 (http://www.jisa.org.yu/2000.htm)
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 Amazon.com 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:
- Those
interested in collecting payments
- Those
requiring pre-processing and authorization
- 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 (http://www.mobtel.co.yu),
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 (http://www.simpaid.co.yu),
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 (http://www.atlantik.co.yu),
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 http://www.setco.org
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.
Conclusion
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