Proteros Data Systems Ltd. has designed and developed the next generation of financial transaction testing tools to aid the testing of mission-critical financial payment systems. Proteros’s Frurion™ product suite brings to market a set of innovative tools for simulating financial transactions, that create a repeatable testing process, that improve application quality, that reduce time to market and minimise costs of developing and testing financial systems and sustain a competitive advantage for our clients.
Frurion™ has been designed to be dynamically adaptable to changes in processing environments which do not require the underlying software to be changed. Instead parameters can be altered which in turn alter the way the system works. These changes can be applied using a set of tools known as the Editors.
Frurion™ comes equipped with all the tools and utilities required to prepare and test any card-payment host system. Its ability to change to circumstances dynamically means that less time is spent on waiting for the tools to be upgraded, allowing valuable testing time to be spent on testing.
In any card transaction there are primarily four entities involved in the process. The acquiring and issuing bank can be the same institution but carry out distinct roles in the transaction process.
The cardholder is the person who has been issued with the credit/debit card and has a certain amount of purchasing power. For debit cards it is the amount of money in the cardholder’s account (plus any overdraft). For credit cards, it is the amount of money that the card issuer is prepared to lend the cardholder (the credit limit).
The merchant is the entity selling the merchandise and where the sale occurs. This is usually a retail outlet which also has a Point of Sale terminal to interact with the card.
The acquiring bank acquires the debt on behalf of the merchant and guarantees payment to the merchant while it, in return waits for payment from the card issuer.
The issuing bank issues the card to the cardholder and, in the case of a credit card, allocates the credit limit available. The issuing bank facilitates the clearing of funds movement based on successful transaction activity.
Open and Closed loop Schemes
There are two types of Scheme that facilitate the processing of card transactions. These are:
1. Open Loop – Where the card is not limited for use at one merchant or one particular group of stores. Usually, these cards carry the logo of American Express, Discover, MasterCard, or Visa.
2. Closed Loop – These types of cards are only valid at one particular merchant or group of stores and are often prepaid or gift cards associated with the particular merchant.
When a cardholder makes a purchase using a payment card, the merchant must obtain authorisation for the purchase from the bank that issued the card – the issuing bank. In the case of a credit card, the Authorisation allows the cardholder to initiate a loan from the issuing bank that will ultimately need to be repaid. For a debit card, the authorisation allows the cardholder to draw down on funds available from the account the card is linked to. The authorisation is an electronic message that is instigated from the merchant’s POS terminal. The cardholder either keys in a personal Identification Number (PIN) or the card details are captured using the magnetic stripe on the back of the card with the cardholder signing of the purchase. The authorisation message is then sent through the network, ultimately waiting for a response from the issuing bank.
For authorisations that were successfully approved, the next step is the clearing phase. During this step, the acquiring bank collates all the authorisations that were successfully processed that day and batches them up into a file. The file is then sent to the issuing banks, via the Card Scheme in the case of an open loop system. The issuing banks then use the clearing information to deduct the monies from the cardholder’s account and to add line entries to their statement.
The settlement step is where actual funds are transferred between the parties to balance the authorisation message flows. The acquiring bank credits the merchant’s account. The issuing bank debits the cardholder’s account and sends payment to the acquiring bank to credit it for the funds it has just transferred to the merchant. In the case of a credit card the cardholder settles his/her account when the statement is received. In the case of a debit card the cardholder’s account is automatically debited. Finally, interchange fees & service fees are deducted from the various payments to compensate the various participating parties in facilitating the transaction flow.
The Data Editor provides a mechanism for low-level data entry. This facilitates testers being able to key-in data according to the message definitions. Furthermore the Data Editor validates the data as it is keyed-in to ensure it conforms to the message and field definitions. This ensures that data quality issues are eliminated and time is not wasted chasing down possible system faults as a result of poor data quality.
Once the field, message and data have been defined and created it is possible to use them to execute test cases. There are a number of tools that come with the base product to facilitate testing card-payment systems.
The system comes equipped with three real-time authorisation simulators that can be used to simulate any point in the card transaction network.
ISO8583 for Scheme testing
The Scheme test simulators provide the functionality required to load test data, which has been created during the data preparation process described above, and to then send requests to and receive responses from the host system under test when the ISO8583 protocol is being used. This set of simulators can be used to simulate either an acquirer or an issuer host system.
APACS PoS testing
The APACS simulators provide the functionality to simulate either the Point of Sale terminal and card or the acquirer system when the APACS standard message protocol is used. Test data created as part of the data preparation process described above can be loaded into the simulator and then used to simulate certain test conditions. The APACS standard for PoS terminal communications is predominately a UK only standard.
ISO8583 PoS testing
For terminals used outside of the UK, the ISO8583 standard is most often used. The ISO8583 PoS simulators have been designed to simulate either the Point of sale terminal or the acquirer.
- Expected Results creator – Once test data has been defined it is possible to create expected results to be used to compare against actual results and hence test the accuracy of the host system under test.
- Comparison Report – this utility produces an HTML report of the differences between expected and actual results and can be attached to an associated defect when an issue is being investigated.
- Hex Dump – some of the transaction messages carry binary data that cannot be read using conventional tools. The Hex Dump utility allows the tester to investigate a problem by being able to look at any give message or file in its binary format.
- Reference data – Each field can have a set of values assigned to it to limit the values that can be keyed-in during data entry. Reference data can be loaded from external sources or defined within Frurion™