In this appendix, we present the architecture, implementation, and integration of BulaPay.
BulaPay software architecture
In this section, we present the software architecture of the BulaPay system . A transaction in the system involves in four parties: customers, vendors, e-commerce sites, and the BulaPay server. The commercial bank is optional for customers to deposit, as well as for vendors to withdraw money. Figure 4 shows the system architecture.
BulaPay provides customers and vendors a set of user interfaces to manage deposit, payments, and balance withdraw. It provides a set of transaction interfaces for e-commerce sites to lodge a payment request, process a payment, and check a payment status. Communicating with the SSL email server, BulaPay sends tokens and notification messages to customers and vendors. Commercial banks can make use of BulaPay’s interfaces to deposit and withdraw money. BulaPay stores user authentication, user access logs, payment transaction records, as well as deposit and withdraw records in a database system.
With the categories of goods & service and item lists, an e-commerce site includes BulaPay payment methods in its checkout option. When customers check out, it forwards the checkout operation to the interface of a BulaPay payment request. The site may check the payment status and update the status of its shopping cart or inventory. Customers and vendors can use a popular browser. The terminal operating system can be any platforms that install Adobe Flash Player 10 or later in order to access the BulaPay interfaces. The BulaPay system is a four-tier web-based architecture [37, 38].
Web tier The popular browsers, such as Internet Explorer Browser, Mozilla Firefox, Google Chrome, and Opera, can be used as a client browser in the BulaPay system. For accessing BulaPay management pages, the browser plug-in Adobe Flash Player 10 (and above) must be installed. Several Small Web File (SWF) objects embedded in BulaPay management pages provide the rich user interface for user data input and for rendering the EXtensible Markup Language (XML) document response into a grid form as a query output.
Web tier The Web tier contains the presentation logic of the application and runs on a Java EE server. The Web Tier in BulaPay contains Servlets that access the business logic in the EJB module. It is either Servlets or pages created by using the JSP technique (JSP pages). Acting as an important accessing point in the BulaPay system, Servlets receive requests from the client tier, communicate with the business tier that acquires payment records from the database tier, and generate dynamic content from them. The Servlets usually generate dynamic HTML pages, but mostly XML documents to the client tier in BulaPay.
Business tier As the EJB (Enterprise Java Beans) module, the business tier runs on Java EE servers and contains the business logic of the application. The EJB module contains the code that handles requests from the Web Tier clients, and manages transactions. The enterprise beans receive data from the web tier or client programs, process (if necessary), and send them to the enterprise information system tier for storing. The enterprise beans also retrieve data from storage, process (if necessary), and send them back to the web tier or client programs.
EIS tier The EIS tier is the persistent storage layer of the application. This tier is represented by the database where the messages are stored. MySQL 5  acts as the EIS Tier, and Java Persistence API (JPA) as the Standard Interface in BulaPay. (1) As an open source database, MySQL has the good performance, high reliability, ease of use, and dramatic cost savings. (2) JPA is a lightweight, POJO-based framework for Java persistence. Its major component is the object-relational mapping (ORM). JPA has additional mapping capabilities, flexible ways to determine the way the provider accessed the entity state, extensions to the Java Persistence Query Language (JPQL), and an object-oriented Java criteria API for creating dynamic queries.
One of key issues in payment systems is the monitoring of the security of payment transfer. The BulaPay core server generates a dynamic pay-out password called Checkout-Token using the UUID (Universally Unique Identifier) algorithm. Every payment request triggers BulaPay to generate a Checkout-Token, which is notified to the customer through an email. For other events relating to the transactions, the BulaPay core server notifies the customers and the vendors through emails as well.
While the BulaPay core server provides web service interfaces and HTTP services to customers and vendors’ sites, the data exchanges between these hosts are in a structured format of SOAP messages. To secure these messages, BulaPay employs Advanced Encryption Standard (AES) bits encryption utilities in the core server and customer clients. The BulaPay core server is deployed on the Java EE 6 application server. For each page request, a servlet session is created and stored on the server side. The customer browser obtains a new session-id before each transmission. The original data in a Simple Object Access Protocol (SOAP) message is encrypted in the source and decrypted in targets using the session-id as a key. The individual session-id is dropped once a request-response operation is completed. This approach is similar to the Transport Layer Security (TLS) and Secure Socket Layer (SSL), which are the most common web security standard employed in current web technologies.
BulaPay core server
The BulaPay Core Server (BCS) was implemented by the Enterprise JavaBeans (EJB) and Java Pertistence API (JPA) , accessing database backend to store customer accounts, transactions, and balance information [40–42]. An application server, such as Glassfish v Open Source Edition (a free, open source application server), which provides EJB and JPA support, is used for BulaPay system development, testing and hosting. Other application server with EJB and JPA facilities also can host BCS.
The BCS, which is developed by using EJB-based components, provides the web service interface and HTTP service interface for end users. The web service interface allows an e-shopper site to request payments, check the progress of payments, and update goods delivery by issuing SOAP request and response messages. The web service provides a platform-independent and language-independent interface that supports a wide range of possible e-commerce frameworks and shopping cart systems. The web service interface allows an e-shopper system to submit payment requests in one step. A successful submission will receive a response with a unique TopayId to confirm the request, which is lodged into the BulaPay system for further process.
For those e-shopper systems with the limited technical support, BCS provides the HTTP service in one or more steps to accept payment requests. In a case of a tight integration, a single HTTP URL with all necessary parameters directly lodges the payment request into BulaPay. In a case of a loose integration that inserts only a few lines of codes to create a hyperlink in an e-shopper site, a customer is guided to complete a payment request procedure step by step.
Developed by using common web languages such as PHP, JSP & Servlet, and ASP (Active Server Pages), an e-shopper site provides online services or goods by displaying a set of web pages. It is part of a shopping cart framework or an online shopping e-commerce solution. Separated from BCS and managed by any e-shoppers, the site can be hosted in any domains and platforms. In order to automatically issue the SOAP message for a payment request, receive the BulaPay response, as well as parse the SOAP message for updating the e-shopper record, a few code fragments should be appended to the checkout step in the e-shopper system. The open source shopping cart solutions such as OsCommerce (PHP/MySQL), KonaKart (JAVA/MySQL), and TYPO3 (PHP/MySQL, CMS solution with the shopping cart plugin) have been tested for integrating with BulaPay.
The manager of an e-shopper site should first register in the BCS system to obtain a unique BulaPay user ID (BulaId). She can then create an eShop to obtain unique eshop ID (eShopId). When lodging a payment request to BulaPay by using the web service interface, an eShopId and a BulaId must be included. BulaPay rejects any anonymous web service requests.
Selecting goods or services from an eshop site, a customer adds them to a shopping cart. When the customer checks out, the summary information for the transaction, such as description of the purchase, an invoice number, the total amount, the e-shopper eShopId and the customer BulaId, are inserted into a SOAP message, which is sent to BCS. For an accepted request, BCS responds with a unique TopayId (BulaPay Invoice Number) for the transaction. In the later procedure, the eshop can send a SOAP message request with the unique TopayId to check the progress of this transaction. The eshop manager should arrange the delivery of goods or services. The payment adds to the eshop’s balance and can be withdrawn from BulaPay to a local bank account when the goods or services have been received.
A customer uses a standard HTML browser such as Windows Internet Explorer. This allows the customer to use a desktop, laptop, notebook, or handheld device with a web browser to perform BulaPay operations. The customer should download and install the freeware Adobe Flash Player 10 or later for a particular browser.
For the security purpose, BulaPay encrypts customer information and payment data before web transmission, and decrypt the received data into a readable format to be displayed on a client browser. The encryption and decryption operation employs the industrial standard advanced encryption utilities and components. All these utilities are embedded into the Flash Player SWF components. These SWF components are embedded into individual HTML pages. The customer uses a standard browser for all kinds of data input. The customer processing a payment with a dynamic Checkout-Token.
In the customer’s browser, BulaPay stores a false login counter. When the customer enters a wrong username and a password twice within five minutes, the login component is disabled and there is no data transfer from this PC to BCS in the next three hours. This control protects the BCS from hacking attempts and unexpected data flows.
Integrating BulaPay with e-commerce frameworks
In this section we describe how to integrate BulaPay into common e-commerce frameworks. Integration is an important feature for e-commerce that employs electronic payment systems to transfer funds online. One of the simplest integrating methods requires only pasting HTML codes into an existing e-commerce framework, while advanced methods use API (Application Programming Interface). The API method allows for a seamless connection of an existing e-commerce site to a payment system. The BulaPay system consists of three integration interfaces, which are checkout express, payment standard, and payment pro (Web Service). These interfaces support the simple copy-and-paste integration, and the advanced API integration.
The code of the Checkout Express Interface in BulaPay is simply one line of HTML, which should be pasted into an e-commerce site. As such, BulaPay enables to collect payment online in the site. Integrating BulaPay Checkout Express, the HTML code requires only one HTML variable: eshop_id. The value is obtained from the BulaPay system when a vendor registers in an eShop. A HTML link or a button will be added into the check-out page of the shopping cart. When a customer clicks this link, a new page from BulaPay pops up to allow the customer to fill detail information about a payment request.
There are several PHP based e-commerce frameworks. WordPress and OpenCart are selected as examples to enable them to collect payments through BulaPay by injecting simple code fragments.
WordPress [43, 44] is an open source Content Management System (CMS), often used as a blog publishing application, as well as e-commerce platforms, which is powered by PHP and MySQL. As one of the most popular CMSs in use today, it has been used by over 12% of the 1,, big websites. Several e-commerce, auctions, donations, payment gateways, and other useful plugins are available for Wordpress to extend it as a full feature e-commerce platform. In the following example, the BulaPay Checkout Express method is integrated into Wordpress so that an author or a publisher is allowed to make money from their WordPress site by collecting a payment through the BulaPay system. (1) Register in BulaPay to activate an account, and login on to BulaPay; (2) Create an eShop to obtain an eshopid as the vendor identity; and (3) Install Wordpress and setup a site as “Academic Paper Share”. A new post and input contents are created in Wordpress.
OpenCart [45, 46] is a good open source shopping cart written in PHP. It was built by using a logical framework of MVC (Model, View, and Controller). The Opencart’s code is streamlined and easier to integrate and customize than some other bloated open source ecommerce solutions. A customer selects goods and adds them to a shopping cart.
To integrate the payment standard interface of BulaPay, four HTML variables are required in the HTML code: eshop_id, eshop_ref, amount, and desc. Assigned by the shopping cart system, these values are used by the purchase, except for the eshop_id. To employ the Payment Standard method, a HTML form with a POST method that assembles these four variables in a page is recommended. The form displays variables for reviewing before submitting the information to BulaPay. For employing the Payment Standard method, a HTML form with a POST method that assembles these four variables in a page is recommended. The form displays variables for reviewing before submitting the information to BulaPay. The variables may be obtained from the URL or the page input. This HTML form is embedded in the common Web server-side languages such as PHP, JSP, and Servlet. For example, in Wordpress or OpenCart using PHP, we can prepare a review page and the form. By adding this page and creating a hyperlink from the checkout page in WordPress or OpenCart, customers are able to click the hyperlink to lodge the payment request into the Payment Standard interface of BulaPay.
The BulaPay system provides multiple integration interfaces. For the open source applications the vendor can use payment process in BulaPay by coping-n-pasting a line of the HTML code. The web service interfaces provide a function of professional integration into common web technologies such as PHP and Jave/JSP.
BulaPay web service interface Web Services Markup Language (WSDL) describes network services, in an XML format, as a set of endpoints operating on messages that contain either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and bound to a concrete network protocol and a message format for defining an endpoint. The WSDL file describes web service interfaces to create a client consuming the web service. BulaPay provides three web service operations (sub-interfaces): ReadUserBalance: return the balance of a specified Bulaid; FindTopayidStage: return the stage of a specified Topayid of a payment; and CreatePaymentRequest: lodge a payment request and return a unique identity of Topayid.
Consuming BulaPay web service from PHP There are two options for consuming web service in PHP: PHP SOAP Extension, and NuSoap which is a SOAP Toolkit for PHP [47, 48]. PHP 5’s SOAP extension is the first attempt to implement the SOAP protocol for PHP in C. The extension is currently marked as being experimental. The SOAP Extension is only working in PHP 5, and must be enabled in a web server side. NuSoap is a collection of pure PHP classes that support PHP 4 and PHP 5 to create web service servers and clients. When the NuSoap class is employed, a developer copies the classes to any folder inside a web application, then refer to a correct path of the cipsas.com class applying SOAP functions in the application. This is a great feature for the software developer that does not need to change any setting in web server and the PHP runtime environment in which NuSoap web service support is integrated into existing applications.
Consuming BulaPay web service from JSP NetBeans  is used for the development IDE to create SOAP clients in order to demonstrate how to integrate BulaPay in a JSP web application. A new project - Java Web Application is created and selected a new Web Service Client by using the project panel. The WSDL file is specified for the web service with NetBeans. The IDE will generate a group of JAX-WS (Java API for XML Web Services) classes and the Web Service Reference for the BulaPay web service. Now the BulaPay web service operations are ready to inject to JSP. There are only few free Java based e-commerce applications available on the Internet. KonaKart is tested to integrate with BulaPay. As a java-based enterprise eCommerce & shopping cart application, KonaKart provides facilities that vendors can sell their products over the Internet. It includes an extensive set of online shopping cart features to suit the needs of online shoppers and retailers. But in KonaKart, only the customizable parts such as JSPs, payment modules, and shipping modules are opened to customers who may want to customize them. Therefore the vendors implement a JSP page to consume BulaPay web service interfaces, and display the SOAP response result in KonaKart for customers to take further actions.