Electronic Payment System for Custom Back Office Accounting Software

The Client

Our client was a company managing one of the largest eSport world communities with millions of participants. Keeping pace with IT tendencies in the sphere of accounting and payment, the company decided to shift membership payment services to the Web.

The Solution

Azoft provided a complete back-office accounting and electronic payment system, keeping in mind security, performance and reliability concerns. This solution was elaborated for a smooth integration with the client’s game server, community portal, authorization system and external online payment systems such as SoftKey, VeriSign, and Microsoft Dynamics GP (formerly Great Plains Software). Special attention was paid to designing an intuitive interface.

Azoft’s solution works with both physical sales (scratch card activations) and online sales (online payments); it supports complex transactions and MLM trees. The back-office ensures smooth updates, timely reporting, and collection of financial data. Due to a distributed architecture, the system functions 24×7 in the high-load conditions with thousands of multi-level transactions per hour.

Since our development team has been creating a system that functions in the global environment, the system has been localized. Azoft’s solution was integrated with various online payment systems such as VeriSign and SoftKey. For quick and convenient addition of new payments, a plug-in technology has been implemented.

Subsystem overview

• Payment
• Charging
• Scratch card
• Online services
• Administration
• Statistics
• Subscription
• User management
• Pluggable payment

Technical insight

The online subscription payment system performs two major functions.

• The system converts credit card payments (Visa, MasterCard, etc.) to the inner currency of the system which can be further used to prolong user’s subscriptions of online-services.
• Generates unique scratch card numbers. The scratch cards with the generated numbers will be physically issued and delivered to their owners. Later users can put money on their inner account using the generated scratch card number.

Technologies

Java Servlet/JSP, XSL/XSLT, Oracle 9i, PL/SQL, XML, JMS, MVC frameworks Apache Struts, Microsoft GreatPlains, Crystal Reports

Scratch card processing mechanism

The processing of scratch cards requires the approval of the system owner. After the processing has been approved, the system administrator gets an activation code and a serial number. For security issues both codes are configurable. Serial numbers are used in cases dealing with troubleshooting and customer care, activation codes — with billing issues and internal accounting.

The payments for client’s services could be divided into two phases. The first phase is the scratch card purchase. If bought online it is a virtual scratch card, if offline — a physical scratch card. The second phase is code activation. A user receives access to certain client’s services through entering his or her activation code; for the most transactions, two-phase commit is used.

All activation codes have special configurable values associated with them. These values refer to a particular period of time during which a user can access some particular service, e.g. participation in an international or local sports event.

Architecture

The modular architecture designed by Azoft allows hassle-free upgrade and further integration with third-party services like online services and online payment systems. The system supports multi-currency accounting. Being a global service, it offers intuitive multilingual interface. Another function is storing country-specific information like address format, etc.

Stability and high performance were Azoft’s main priorities for the project. To reach the goal, our team has created a distributed system: all the components and subcomponents can be distributed physically across several servers. To manage and monitor all system activities, an advanced administrative module has been developed; the logging implemented records all operations of the system performed by users, system administrators or owners. To access the system, an administrator must have client 128-bit certificate. Besides efficiency and stability, Azoft also focused on ensuring the highest security and the quickest recovery if anything has gone wrong.

Protocols

The web-service runs on a dedicated application server. A database-specific protocol is used for back-end and database communication. The interaction with external payment systems is carried out through a secure system-specific protocol. Due to a special engine developed by the team the integration via emails is also available. The engine could be either plugged or unplugged. System administrators can only use web interface and HTTP(S) protocol. HOP-GO clients access online services through web browser and HTTP(S). To communicate with external authorization subsystem the RMI protocol is used. The accounting module employs an external authorization subsystem along with interfaces. Most of the services are published in the RMI registry

Business logic

When implementing the system’s business logic, Azoft applied the service-oriented approach. ServiceManager subsystem is in charge of the control over each serving. All services register themselves in the Service subsystem, then ServiceManager refreshes the list of services currently available, allowing other components to search services by name. Moreover, once a service has been obtained by an external component or subsystem, ServiceManager offers a connection to the service’s database. ServiceManager is rather flexible: administrators could configure it to merge various clusters of the system, that work as a whole global environment. This has been achieved by employing a special approach invented to cope with several Java Virtual Machines, allowing clustering the system on several servers.

The presentation layer has been built with the help of Apache Struts framework, JSP and XML. Resin XSLT processor and XSLT formats have been used to transform XML into HTML code. The system includes approximately 30 complex use cases, 100 mediocre, and 150 simple use cases.

The innovative design, distributed architecture, and complex business logic granted the client a secure, intuitive and highly flexible online payment service. The resulting system can support the growth of the user community, reducing the cost of overall system support, the increase of revenue and success on the international market.