Before looking at the options available, please consider the following... a payment card solution is a transaction processing system. Transactions processing systems are extremely sensitive to the following issues:
- Security - resistance to compromise.
- Volume - the ability to scale to, and maintain, a transaction processing rate of a given number of transactions per second (TPS).
- Latency - the time it takes to service a transaction from request entry to the response received.
- Concurrency - The ability to service in parallel multiple transaction requests.
While the first three are easy to understand, the fourth issue "Concurrency" is less obvious. Concurrency surfaces its' head during peak periods of transaction activity. Poorly designed payment solutions serialize the processing of transactions rather than process multiple transactions in parallel. This issue is especially prevalent in card-present situations involving the use of pinpads. The interactions that take place between the customer, pinpad, payment solution, and the processor can take many seconds and sometimes several minutes. If transactions are processed serially, transactions at the end of the line must wait for transactions before them to be processed. It is like standing in line at the bank waiting to cash or deposit a check. You must wait for the customers before you to be serviced before they serve you.
Understanding these four issues and specifically, your requirements relative to each is key to your ability to purchase an affordable payment solution that will meet your needs. Think about all the examples you have heard or read about where merchant's systems that failed of Black Friday. What is your Black Friday and what do you need to prevent a catastrophe? Knowing your requirements and careful choice of a payment solution is a critical first step. The second step is deciding how to best integrate your front and back office systems with the payment solution. Integration issues involve many complicated business and technical issues. Who should you turn to for advice? Integration expertise is not a strength of processors, banks, or acquirers. If you are running IBM POWER, I suggest that talk to someone with IBM POWER expertise to sort thru the issues.
CFXWorks believes that IBM POWER users represent a class of user organizations that will be especially sensitive to the above four issues. These organizations understand that their success requires seamless integration of their payment solution with their front and back-office systems. They understand the impact that failed or lost transactions can have on their business reputation and the time and resources required to manually resolve these issues isn't practical or affordable. Unfortunately, the sales and support personnel at processors, banks, or acquirers are completely lacking in integration expertise. If you tell them you need a payment solution that runs on any IBM supported operating system (AIX, Linux, or IBM i), DB2, and uses message queues you will hear dead silence on the line.
Our experience is that users of POWER won’t compromise on finding a solution that:
- Runs on their platform of choice.
- Uses their database of choice.
- Integrates using their programming language of choice.
- Supports their integration option of choice.
In addition to the concurrency issue there are two added issues that tend to impact in particular users of IBM i platforms:
- NO BROWSER – One of the major reasons organizations choose to use IBM i is that it is viewed by many as the most secure operating system available in the commercial marketplace. Browsers are considered by many to be an open door to compromise. Therefore, for security and control reasons many organizations reject the use of browsers at their client locations.
- THIN CLIENT – 5250 emulators are considered by many to be thin clients. Thin clients are required for the same reasons that browsers are rejected, lack of security and control at the client locations. By the way, don’t expect your processor, bank, or acquirer to even know what IBM i or 5250 emulators are.
Most CFXWorks users require multiple integration options. How you choose to integrate your eCommerce solution is likely to be different than how you integrate your call center. You may also choose to integrate your card-present transaction requests using another integration option. Here are some options that CFXWorks supports:
(1). Using Files - Integrate by sending requests to and receiving responses back from the payment engine using files.
(2). Using Data Queues or Message Queues - Integrate by sending requests to, and receiving responses back from, the payment solution using data or message queues.
(3). Using APIs that support web services or sockets - Integrate by sending requests to, and receiving responses back from, the payment solution using web services or sockets.
(4). Using iFrames – Although one might consider an iFrame approach a web service, we mention it here as a separate integration option. Integrate by sending requests to, and receiving responses back from, the payment solution using iFrames.
(5). Using Database Tables - Integrate by sending requests to, and receiving responses back from, the payment solution using database tables (see Back Office Systems).
Figure 5 – Option 5
One final thought about integration. For other than eCommerce, we strongly suggest that you format the data you pass back and forth using XML. The processors and acquires made a lot of changes that impact message content and syntax over the past two years. We believe that more changes are coming. XML gives you a lot of flexibility in implementing these changes. Our recommendation is don’t migrate to any payment solution that doesn’t support using XML syntax to pass information back and forth.
We hope you find the above useful. If you have questions or suggestions, please call CFXWorks 678-455-0952.