Overview
The client is a renowned provider of Payment Switch Framework, which includes a range of robust, in-store and host transaction management software that runs on multiple platforms—within a dial-up or WAN environment. Over 150 customers use this software to process millions of transactions each day at over 30,000 locations worldwide.
The client has developed a Payment Switch Framework, which comprises an Authorization suite and Settlement suite. RS was engaged to develop plug-ins for the client’s Java framework to support various Acquirers/Processors.
Various payment methods - Credit Card, Debit Card, Check, Pre-Paid/Stored Value/Gift Card, Private Label Credit Card, Electronic Benefits Transfer (EBT), Fleet Card, Phone Card, etc., and various financial transactions, e.g., Authorization, Sale, Return, Void/Reversal, Inquiry, Batch Close are supported by the framework and their plug-ins.
Objective
Authorization request and response messages are different among the Processors/Acquirer banks.
The message can be either in compliance with ISO 8583 format or Fixed/Variable length or XML format. If a merchant wants to use different processors for different payment instruments or change the processor at any point, so flexibility has to be provided.
The Authorization Suite of payment switch installed at Merchant’s premises serves this purpose. During authorization process, the switch accepts requests from various entry points, e.g., POS Terminal, e-Commerce, MOTO, Fuel Pumps, wireless, etc., in the switch’s proprietary message format. RS had to build Connectors to format the message according to the target Processors/Acquirer banks. To achieve this, the connectors were developed as plug-ins to the switch, which transforms the request message into Authorizer-specified request format and the response message to the proprietary message format.
The settlement suite builds settlement (deposit) file from the transactions stored in the Merchant’s database and sends it to the Processor for clearing. RS had to build connectors for this suite to build the deposit file according to the bank specification.
RS augmented the switch with 48 new connectors for Authorization suite and 17 new connectors for Settlement Suite.
Each of the connectors needs to be vendor-certified and merchant-certified with respective processors before putting them into production.
Our Approach Development of each connector started with receipt of the specification from Client. The development life cycle consists of:
Analysis: RS had to analyze the spec and map the message/ file format with Client’s proprietary format. Analysis and mapping document was created in this stage.
Development: Then the connectors were built based on the analysis document. Java Codes, including JUnit test cases and Database scripts are the outputs of this phase.
Testing: The connectors were unit-tested using unit test cases and functional testing was done using a POE Simulator and an Echo server (Dummy bank). When bank connection was available, testing was done with bank. Thus the correctness of the message was tested for different payment instruments and transaction types.
Certification: After delivery, client arranged certification of each connector, and RS had to provide support from offshore or through Onsite coordinator. After the vendor certification was complete, the connector was ready to be deployed on Merchant, where another round of certification took place.
We have developed 48 new connectors for Authorization suite and 17 new connectors for Settlement Suite within 135 Person months. This includes certification of approx 20 connectors.
Benefits:
Testing as a COE – Integration, System, Regression, Cross System and Performance Testing
Test lab creation and maintenance – that allows maintenance of test beds, test cases, test scripts for reuse and repeatability
Overview
The Client is a leader in electronic payment processing services. The client was satisfied with the software services provided by RS. After successful completion of Merchant Account Reporting System (MARS), the client engaged RS right away in a number of short-term projects with larger projects in the horizon.
The client provides businesses with services and software designed to automate the commerce transaction process in multi-sales channel environments.
The provider’s customers send credit card transactions (Auth, Purchase and Refund) to our systems to process, which are routed, to payment processors. The payment processors route them to the card associations. In each of these steps, the processor sends reports of the status of any given transaction on a periodic basis.
The provider was developing MARS (Merchant Account Reporting System) to provide their merchants with user friendly and rich reports of their accounting information. At a high level these reports were designed to:
Allow customers to reconcile financial data
Allow customers to view and manage financial activity in regards to the flow of money. Example: Purchase, Refund, Chargeback, etc
Allow customers to view financial data at summary level and detail level
The client invited RS to provide complete end-to-end development services in this endeavour
Objective
Transaction data is stored in database. The client would provide the merchants generating the transactions and being financially impacted by the transaction to do view and analyze transaction data through reports. Merchants would subscribe to reports various reports to view and download them. Access to the reports is based on merchant hierarchy and subscription type. The aim of the project is to define hierarchical relationship among merchant entities and develop multi-layered reports for merchants.
Our Approach
The file processing module was designed to read the different relevant reports, mine the data available in the reports and store the relevant data in a database designed by the client.
The reporting module read this data to generate various reports which include static reports and ad-hoc reports. These reports were designed and developed using Actuate. At a high level, there will be reports that are linked to other reports. When the user wants to see the details behind the summary data, they click a link from this report which will show the line item detail for the summary data.
The summary data was controlled by user permissions as well. The users were defined in a hierarchical structure based on their relation to the merchant. Access to the reports was governed by the user logged in to the system, his/ her permission level and subscription type.
