Sample Recommended design for an Acquirer test cases suite, Scenarios and Regression

The payments converter has the capability to convert any payment messages to API requests to exchanges.

Integrate crypto payments or crypto purchase from within your system, ATM or Host for Bitcoin, Ether, and many other cryptocurencies.

Adding extra, custom fields to the ISO8583 simulator in 3 simple steps: Edit the spreadsheet and save, edit the message that reads the test data, alter the ISO8583 message.

Deploy then neaPay Payments switch router to easily route transactions based on BIN/prefix, amount, merchant, originating or destination insytitution, node.

1. As a container orchestration with Docker-compose

2. As separate services managed as stand-alone.

4 modes are available to the user out of the box:

1. RunOne - runs only the selected Test Case
2. RunScenario - runs only the selected Scenario
3. RunAll - runs all test cases in the list
4. RunLoad - runs the core in Load mode

When you need to customize your own test case, you need to follow some simple steps all the time.
In order to obtain this, you need to alter test data in Excel, save your new test data, export for the simulator, restart simulator with new test cases.

Changing test cases with the neaPay ISO8583 simulator is really easy because you just need to work with Excel.

Enabling traces in the ISO8583 Payments Simulator, just like the ISO8583 message converter and the ISO8583 Host, is a call to the system core to write additional data. This will, most of the times, show raw data (binary data is dumped as hex) for better understanding what is going on, what data is actually being used.

Most importantly, enabling traces shows dumps of TCP traffic or actual data being written to files, queries do database and so on. This is to verify that you are sending the correct data.