POS Device Simulator SPDH, HPDH

How to Test POS Devices Acquiring

Export card data, keys data to the simulator in csv format

Configure POS Device or any other Terminal data in the simulator

Configure test cases in Excel

Send standard POS messages out of the box to BASE24, Postipon, Alaric, Way4

If needed, customize the logic or your own custom POS Message

How will the POS simulation work?

Cards will be stored in an Excel sheet, as well as keys and terminal information

The core will use our message definition to create the POS message

The scripting engine will sent the transaction message for applying business logic

Once formatted, the transaction will be given back to the core for sending to authorization Host

The core will use the Outbound JSON definition to pack the message and send it to the Issuer connection

The incoming authorization response will be parsed, verified and checked for RC or other fields

Any number of connections can be defined

Any number of messages and message types can be used

Key features particular to our POS simulator

Authorization messages are fully customizable, separate building and parsing

All connections configurable and unlimited

Authorization message building logic can easily be customized to any format

Any type of connection is supported, including flat files, NSK enscribe, fixed clearing, SQL

Have automatic statistics and Authorization response checks

ISO Host: Receive transactions, process and respond. Iso8583, XML, JSON, fixed data, extracts.

The same engine as the Iso8583 simulator, but with authorization scripts for issuing. Runs on any platform where you have Java, and reads JavaScript authorization scripts that specify the logic to authorize transactions. Use cards and message configuration from CSV files or connect to databases. Configure simple authorization rules in spreadsheets or use complex logic or formatting in authorizations scripts.
Do not worry about speed, we took care of that, it all runs at Java speed.

When we do development on interfaces and start testing transactions, we like to start slow. First we run something very easy, with just a few fields. No RRN, no STAN, no PIN and EMV. Something easy to check connectivity and message parsing. So we set up the simulator to expect just a few fields and to approve all. That is easy with our Authorization Server, we just deactivate fields. Then we add functionality, like expiry date, so we activate that one too. Our Authorization Server has the logic for checking such fields already built in, but if the field is deactivated, it is not used. Upon activation, the field is checked and used on request and response. Then we add the STAN functionality, so we activate that in the Authorization Server too, and then we can test. We repeat these steps for each functionality we add.
This makes it easy to track issues, to split projects in phases, tasks and subtasks, to better estimate and keep the projects tidy.