ISO8583 Authorization
Payments Host

Payments Host for Small and Medium Business

A Host for any acquiring protocol: ISO8583, TLV, CSV, XML, JSON

Handle any switch, member bank or Institution with no code changes

Easy to integrate with HSMs, Fraud, other banks

Switch, route, log, convert on the fly any payments

Built to be Flexible, Customizable and Reliable

Customizable business logic with flexible configurable rules

A great Host for cards, balances, validation EMV, PIN, balance

Forward ISO8583 messages or settlement files to Interchanges

Incoming ISO8583 messages to custom debit systems, card management or Dispute Management

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

Based on the neaPay core Engine, with authorization scripts for cards, balance, limits and rules check, the neaPay Host has unrivalled speed for limited-resource servers. It 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 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

neaPay payments components

Payments Authorization

T

Input sources

1. Directly from a user, in a secure environment, via an interactive UI or command prompt

2. From a pre-defined configuration file

3. Via commands from a web interface

Output Data

1. Database data that is used by the Authorization system. This can be a file, a direct connection to the database, or other format

2. Card Data that needs to be sent to the card printing company, in a file or via a direct connection, like a database, web host, FTP

3. Other data, like pin printing or other cardholder information, which can be sent securely to another system ro just a file

Simple Cards Generation Logic

Authorization - articles