Custom POS messages configured in a few minutes
Connect POS devices on HTTP, TCP, with custom headers
Optionally connect to databases, clearing, third parties
Store the card data to use in the POS message in Excel
Store and reuse Keys
Host cards, balances, update EMV, PIN, balance
Forward ISO8583 messages or settlement files to Interchanges
Incoming ISO8583 messages to custom debit systems, card management or Dispute Management
Great for Terminals Host, Routing, Cards Host or Balances Host
Built to be Flexible, Customizable and Repable
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
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
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
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.
Because sometimes you just need a server to test your interface. You want to approve everything in the beginning, then you want to test some fields and check some
values. Then you want it to check EMV cryptograms and generate ARPC, you need to check the PIN, or other validations.
You want to organize your project with steps for each kind of validation, and you have milestones for each. You do not want your Authorization Server to perform all the checks from the start, you want to test each part.You need the Authorization Server.
Ready to start your next project with us? Give us a call or send us an email and we will get back to you as soon as possible!