Configurable payments transaction types
Iso8583, XML, JSON, fixed data, extracts.
Authorization scripts for
cards, balance, limits and rules check,
Top speed, tiny resource footpring
Runs on any platform on Java, with JavaScript authorization
scripts for transactions processing.
Use cards and message configuration from any input source, starting
from all databases compatible with Java, including custom binary
databases like HP NSK Enscribe and even just flat files. Configure
simple authorization rules in spreadsheets or use complex logic or
formatting in authorizations scripts.
Do not worry about
speed, all file-related configuration is loaded to memory, so it is
memory-to-memory fast.
How will my project start?
For cautious customers, we have the easy sequence.
First, we
set up the interface according to the specifications.
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.
Then we can start enabling more complex message
handling, checks, EMV, dynamic data and encryption. It is all built
in, but we can activate independently
Once all message-related
functionality is confirmed, we can start working on the
Authorization rules.
How do we authorize
Simplest form of authorization is done via generic rules, based on
prefixes, amounts, and generic matching.
A call to the
database, or to another system, is be done to check and retrieve
local data. Do not worry if you have some strange binary data
structures, we can match anything
Further on, we can call on
business logic to calculate EMV data, MAC or HSM calls.
You
have another host or fraud system? We can send a message to that one
too, no matter what kind of message it is.
If required, an
update of balance or card status can be sent to another system, or
just send to a logging system.
Local logging and Analytics are
set up for real-time overview of the system.
So, what if it does not work?
Well, we promise it will. There has not been a single interface
that we encountered which we could not implement. Also, we come up
with a very cautious approach which will be tailored in such a way
that you have nothing to loose.
And what if we want to do a big fast implementation?
Big&fast implementations involve a lot of risk, which we assess,
share, and agree upon, in advance. Usually such projects require
more people, more effort and more cost, so tell us about it.
Made to Authorize!
Big or small, Authorization host systems can be set up for almost
any system and requirements. starting from small simulated
environments
Example authorization host setups
Simple Simulated host
is usually used for members of your institution to test against a
server that is always available for their testing, in case you do
not want to buy another license of an expensive host system.
Small real Host
is very similar to the one above, but you can use certain features
of the real system, like cards data, key data, real HSMs, balances,
with or without impacting the data.
Real Host
will be set up for normal authorization, with all features,
interfaces and business logic