API EMBSwitch

ApiEMBSwitch is a combination of two main products: ISO8583 switches like BASE24 and an ESB like Oracle ESB or IBM ESB. This means that you use ApiEMBSwitch to switch both ISO8583 transactions and ESB transactions simultaneously. With ApiEMBSwitchHA, it allows you to handle any amount of transactions without any limits.

With ApiEMBSwitch you can integrate all kinds of existing systems with a new system like Oracle Database, Oracle Financial, Microsoft BizTalk Server at the same time without any problem.

With the ApiEMBSwitchHA version, you can have unlimited switching power to process all kinds of transactions that you want. As a real example, one of our Chilean clients, over 1,5 million transactions per day are switched by ApiEMBSwitchHA. There is a total of 8 servers configured, 2 load balancers, 4 physical ApiEMBSwitch servers, one ApiEMBSwitchHADC server, HADC stands for High Available Data Collector which is the TX console allowing the user to inspect transactions. 1 Nagios server used to perform real-time monitoring. From 2016 to now, there are zero seconds of downtime.

Achievements

Some connected coorpoerations list ... Isapre Colmena Isapre Masvida Banco Santander Multicaja S.A. Dicom PreviRed Autentia Isapre Consalud Isapre Cruz Blanca Isapre Banmedica Isapre Vida Tres and others

Features

• Secure and real-time POS/ATM/EFT transactions processing.
• Secure and real-time Bill Payments transactions processing.
• Stand in supported
• Standard ISO 8583 (87, 93, 03) supported. Also customized ISO 8583.
• Integration with business partners
• HSM Supported
• Integration with different systems within an enterprise
• Over 100 different endpoints which allow the switch to connect to almost any kind of connections: Queue, TCP-port, HTTP, HTTPS, SMTP, POP3, SFTP, WS-Soap, WS-REST etc.
• Over 60 ready-to-use Enterprise Integration Patterns (EIP)
• Fast implementation
• XML-based route definition
• Full level administration - dash board as high level monitoring
• Drill down administration - each transaction can be viewed and analyzed, input, output, elapsed time etc.
• Real-time notifications, including SNMP integration
• Persistent or no persistent transaction registering - no transaction will be lost even crash the system.
• Wiretap audit log - Asynchronous audit log database registering which prevents slow-down switch's performance
• Together with EMBFileTransfer a full functional payment switching solution can be build in very short time.

History

 

The birth of ApiEMBSwitch was a prototype payments switching system for a Chilean POS based payments switching company, Multicaja S.A. to replace its old switch which had a lot of failures and lack of proper support.

ApiEMBSwitch enables financial institutions and processors to realize online transaction validations and authorizations, just like Multicaja which has over 20,000 POS. ApiEMBSwitch also allows an enterprise or middle size company to integrate with its partners and/or its different systems.

ApiEMBSwitch is a key component to do any kind of integration. Click here to see EMB Switch usage examples.

Differences Between RPC (Stop and Wait) and EMB Switch

The big difference between an EMB (Enterprise integration patterns Messages Based) switch and an RPC (Remote Procedure Call which includes synchronous web service call) Switch is the EMB Switch is built with failure consideration in its design. And an RPC switch is generally in perfect condition in its design. Any transaction entered into the EMB Switch will be registered persistently and the RPC switch will generally not. So, for an EMB Switch, when a failure occurs, transactions can be reprocessed lately and an RPC switch will simply start everything from the beginning.

This feature allows the switch company to handle any customer complaint in a much better way. Because an exact result of any transaction can be obtained from the switch, so the exact reason can be told.

For a RPC based switch, a failure of switch, or a network link failure, hundreds of transactions in the switch will be lost without knowing their status of process and obviously can not tell in which status they are on.

High Level Architecture of EMB Switch

The basic role of a switch is to route transactions to their proper destinations. Diagram 2 shows there are three types of transactions, green, red, and gray. Each of them will be processed by the predefined path.

Core

The EMB Switch Core is a queue manager. Each transaction will be converted to a message and then enqueued into a queue. Then the message will be dequeued and then routed to its destination Transaction Authorization Company (TxA).

Other core components are Java Message Service (JMS) and Enterprise Integration Patterns (EIP) Implementation which allow higher-level components to orchestrate different transactions in easy way.

Monitoring and Administration

For each process step of a specific transaction, an audit record will be registered into the Audit Database. The record is generated and save through an audit queue asynchronously. By this design, the performance of the core of the switch will be not affected by the audit activities.

The audit database will be used by the auditor of the switch and used by the monitoring team and help desk staff. The user's role will be used to make a decision on which data will be retrieved to that role.

Just as shown in Diagram 1 and Diagram 2, the switch can be built easily to different usages. Diagram 1 shows an EFT switch without any local StandIn database, so each transaction will handle 100% online. The switch shown in Diagram 2 has a StandIn database that can process certain transactions locally.

Monitoring - Dashboard

ApiEMBSwitch Monitoring Dashboard provides a high-level overall view of the Switch. As shown in the Diagram, the TxO companies are located at top of the screen, which is renamed as Service Payments Collection Companies. And in the middle, the overall status of ApiEMBSwitch is displayed. And at the bottom, the TxA company's overall status is displayed.

Monitoring - Drill down Display

For each TxO, TxA, and EMB Switch, transactions can be queried and to see what and how are handled by the EMB Switch. Just as shown in the Diagram, for a specific transaction at a specific point of the route, several critical information can be obtained: status, elapsed time of processing, returned data, etc.

With help of this information, an auditor can know what is exactly done. For the monitoring team, they see the performance of the switch. The Help Desk staff can answer customers' complaints about their specific transactions.

Questions, feedback, suggestions? We would love to hear from you!