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:
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 (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.
SOURCE:
http://www.technologyevaluation.com/research/articles/development-of-an-internet-payment-processing-system-16681/
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:
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 (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.
SOURCE:
http://www.technologyevaluation.com/research/articles/development-of-an-internet-payment-processing-system-16681/
No comments:
Post a Comment