Licensing Linufix and all accompanying software referenced in this post are classified as free open source software under ...

4 Steps to Deploy Linufix as a Secure Payment Gateway


Linufix and all accompanying software referenced in this post are classified as free open source software under GPL licensing scheme. This does not mean that commercial usages of these software, as a whole, or partially, are free of charge. Please do not hesitate to contact Macronodes for more information with regard to Licensing and Copyright.

Challenge of a PSP business

Before beginning with downloading and running Linufix as a Payment Switch,
I take this moment to highlight the business need for such product!

In a PSP business, more transaction means more revenue. But PSP businesses face an enormous technology challenge when they want to expand their transaction processing network or add new added value services to their transaction processing capabilities. Cost of implementation is a secondary challenge.

Linufix, being a free bank-grade Operating System, brings Performance, Scalability, Security, Integrity, and Availability of a payment switch to any transaction processing business.

Anatomy of a Purchase

A brief on the transaction flow in a typical purchase scenario:
 As the flow is shown in the figure above, 1 the Cardholder initiates the transaction at the merchant site on a PoS terminal, 2 merchant's terminal builds and sends a Financial Request 0200* in ISO 8583 format, and 3 merchant bank's acquirer switch (or any 3rd party PSP on behalf of the acquirer bank) receives the transaction and validates the merchant and terminal IDs, checks card information including expiry date, applies financial logic such as surcharge, rebuilt the transaction based on Card Scheme authorization format, and sends up the transaction to the Card Scheme (Visa for instance), 4 Visa, again here opens the transaction, validates the acquirer institution id, finds the corresponding issuer bank and reformat the message to issuer bank's format and submit the transaction to issuer's host. 5 Issuer host tries deducting the purchase amount from the cardholder's bank account and if approved, sends back an approval to the Visa network, 6 Visa, since the transaction is approved, sends an approval message to the merchant acquirer's switch, and here, 7, on successful response, the acquirer fills up all necessary clearing and settlement data so that it can later at the settlement time, sends them to Visa for clearing purposes. And finally, 8, the merchant receives an approved on their terminal and finalize the sale.**

* In some implementations an Authorization request is first sent to guarantee availability of fund in the cardholder's account. In this case a subsequent Financial Advice 0220 should complement the purchase. You may see such implementations in hotel payments where they tend to do a pre-authorization and hold cardholder's intended purchase amount and do a completion transaction request later at checkout.

Have this rule in mind when making a decision between 0100 and 0200 transactions:
  • If the transaction is to have an actual effect on the cardholder’s account, then you use a 0200.
  • If the transaction is instead to put a "hold" on funds in the cardholder’s account in anticipation of a settlement record to come later, then you use a 0100.
** Failure cancellations, Refund processing, Logon messages, and Cutover/Settlement transactions are also among important transactions in a payment processing cycle which I scope them out of this article.

What makes Linufix different?

Linufix will be the unified acquirer Gateway and Payment Switch in this lifecycle.

Linufix transaction switching solution is shipped along with a collection of crucial software and packages that facilitate security, performance and scalability of any acquirer switching business.
PSP businesses often deal with following challenges in their ongoing operations:

Switch software updates  

Card Scheme mandates, customer business requirements, internal software and database design problems, are among the cases for which PSP software teams need to make changes in the core switch. It often come along with lengthy testing period and possibility of introducing another defect in the core system. Risk of running into an unplanned downtime and panic moment is too high and in PSP business missing a single transaction counts towards the revenue!
Linufix payment switching architecture comprises of loosely couple, independent building blocks that make it logically easy to understand by software team and safe to build and rebuild while scoping out the change from the rest of the system. For instance, the key and certificate management is totally independent of core transaction processing or loadbalancing between incoming and outgoing links are completely transparent to the financial logic layer and so on.

Managing keys and certificates

One big pain that is seen almost in all PSP businesses: There is always a secret key, clearly stored in the database somewhere. The key is often the switch master key that needs it to make the very first connection to security module for link encryption and pin translation. This is clearly a security flaw but often ignored by business until something very bad happens.

Linufix is equipped with a software security vault that makes it utterly difficult for even top notch developers who may have access to the production switch and database to see the master keys.  

Handling big data

There are potential of defining many efficient operational processes on top a well-integrated data but many PSPs have difficulty collecting their transaction in a cohesive manner.
Linufix resolves the problem with collecting big data by decoupling the operational database from the data warehouse. The operational database will be a light supper fast database that remove the burden of big bulky databases that can turn out to be a performance bottleneck. The data warehouse, on the other hand is fed with stream of incoming data without imposing any delay overhead on mission critical realtime operations of core transaction engine.  

Upgrade downtimes

Service downtime imposes an enormous costs to service provider.
Linufix is built upon LXC container technologies. This technology makes it possible to hotplug instances of Linufix switching system in a live environment without disrupting the ongoing service. For more information on how to achieve this mission, please read another post here.

Data transmission security 

Payment processors often spend extra on MPLS or dedicated link encryption and load balancing.
Built-in loadbalacing, SSL/TLS and VPN services offered by Linufix out of the box, saves businesses from more allocating these extra costs.

Linufix workshop - Running a Payment Switch

In this section, we cover how to trigger your first purchase transaction from a simulator towards Linufix.


- Download the latest version of Linufix from here. Following the deployment instruction in the Linufix official website or simply download the Linufix virtual machine from here. Running a virtual machine is fairly easy. Please follow the instructions listed here.

- Download the latest version of Macronodes Finsim from here.

Steps to setup the Payment Gateway and test it

1- Turn on Linufix machine. After boot completed, open a terminal and run the payment switch service via:

service eft_switch start

2- Run Macronodes Finsim from Applications menu and enter the Linufix machine IP address. Leave the port number to be default as 8585.

3- Build the authorization transaction, select ISO 8583 format and enter the amount. Leave other fields with their default values.

4- Send the transaction and receive the response.

Linufix Performance

Linufix switching platform can handle thousands of transactions per second. In order to benchmark the performance, reboot the Linfuix machine and open a terminal after boot completed and enter following command:

service eft_switch start benchmark

Then in the Macronodes Finsim, check the benchmark bottom and enter TPS. At anytime you can stop the benchmark in the Finsim and see the statistics.


Long story short! For those who are not familiar with the Linux container technologies, I highly recommend to search for LXC and Docker ...

Achieving 100% uptime in sensitive financial services with Linufix containers

Long story short!

For those who are not familiar with the Linux container technologies, I highly recommend to search for LXC and Docker technologies. And for those familiar with chroot concept in Linux, I can give a shortcut: Docker container or LXC technology is the same as chroot in the sense that it provides OS level isolation but in addition it gives mnt, pid, user and network isolation plus dedicated hostname and dedicated shared memory. In fact container technologies enables us to achieve a virtual machine-like isolation at the kernel level and not at the hardware layer traditionally offered by VMs. And in short, it means heaps of opportunities to optimize resource usages and reduce costs. In this post I assume the reader have basic knowledge of Linux but anyhow I will try to discuss the technology through a simple context.

First the problem should be acknowledged though; For anyone who has worked with commercial financial services such as core banking software, payment switch, or CMS systems, it is not that hard to recall the moments that the business undergoes fines for SLA violation ($1000  per minute in a company that I know) or receives frustrating client complaints. In fact this issue is kinda bolder in financial services rather than in other business sectors and the reason is of course obvious.

Anyway, before jumping into the proposed topology and technique, I show you how to make a container out of already running stable Linux host.

Create and build a base docker container from a running Linufix host (applicable to other Linux distros too)

- Open a terminal
- Run following bash commands

$ sudo debootstrap linufix-corebank-container bionic > /dev/null 
$ sudo tar -C linufix-corebank-container -c . | docker import - linufix-corebank-container 

In the above example, you created a container from your already running host Linux in few minutes. Of course you need to first install packages such as debootstrap and docker. Use apt-get to download and install the packages or search for updates in their host repositories.

You can properly test your docker by running "docker run" command. In the following example I show you how you can run a ssl server in your newly created container and connect to it from outside:

- Run the following bash command in your terminal

$ sudo docker run linufix-corebank-container /bin/bash -c "ip addr show && openssl s_server -psk 1234567890 -accept -cipher PSK-AES128-CBC-SHA -nocert"

Now in another machine execute following command:

$ openssl s_client -connect -psk 1234567890 

Note that is the interface IP address of my own Linufix container and in order to confirm it I added a "ip addr show" command as part of the container execution so that one can see what is the docker interface IP address. You can run following command to understand your docker's IP:

$ sudo docker run linufix-corebank-container ip addr show


Now that we learned how to create a container from our service, let's consider a generic view of our proposed network topology:

As depicted in the illustration above, we often have a dynamic loadbalancer in front of our service stack. But there are plenty of networks out there that even do not deploy a loadbalancer that I highly recommend to do so. There are a few free open source loadbalancers such as HAProxy that comes with plenty of features including dynamic discovery which we need for our solution.

The traditional problem in financial services is that once the system admins are updating a node's software, that node is out of order for a while and so the traffic is distributed between remaining nodes (quality is degraded). Even worst, if the network comes with no loadbalancer and therefore relies on a single point of failure (often we see this even in big banks!) then the system is completely out of order until the node gets updated and comes to the life again.


Check this out:
As depicted above, the first thing that we do is to create a container for our service and deploy it in node(s). This is called Current Production in the above figure. Then when it comes to transition time, in the same node, we deploy a new container that includes all the updates. Now for a while both old and new containers work in parallel and the loadbalancer balances our the traffic between them. Zero downtime achieved! At the last step of the transition when we already know that the new container works fine, we can bring down the old container and reach to Post Transition as shown above.

All above operational steps are fully supported in Linufix. Linufix ships with all necessary software and components that deliver loadbalancing and container management. 


As we move forward with heaps of next generation technologies, end user customers can't really accept underperforming services in financial sectors. Although it might be cumbersome for banks and financial institution to say goodbye to their COBOL era, but they have to embrace it sooner before it's too late. For many banks around the world, upgrading to the latest technologies can be similar to taking an tasteless painful drug but for them that might be the only significant cure! 


In this editorial, before I begin with Macronodes Payment Gateway features, I rather take the time to review the necessity of Omni-Chann...

6 Ways Macronodes Omni-Channel Payment Gateway Improves Merchants Business

In this editorial, before I begin with Macronodes Payment Gateway features, I rather take the time to review the necessity of Omni-Channel Payment technology in today's e-commerce.

What is Omni-Channel Payment? What is Multi-Channel Payment?

Often confused with Multi-Channel Payment, Omni-Channel is a technology concepts that acts as an aggregation layer on top of multiple Payment Channels!

 In a hypothetical scenario, assume Nike wants to establish multiple Payment channels to facilitate customer purchasing capabilities over legacy phone, online website, In-store, and on their mobile App. Hold on right here! This is Multi Channel Payment. Meaning that Nike provides multiple different channels to empower customer purchase operations. Each of those channels act independently and has their own interface with user and highly likely they collect user information independently. 

And that's exactly where business problems arise and the need for Omni-Channel is felt more than ever.

What is the problem? 

In the same Nike scenario, assume a customer receives an online Nike voucher and wants to spend it on next purchase. She checks Nike online website and selects the items she wants, adds them to the shopping card and instead of buying online, she decides to go to Nike shop in a near shopping center to try on the items before purchase. She takes the items and take to the cashier. At the cashier she is presented with an EFTPoS machine with the total fee! There is no discount promised on the online voucher! Call the manager! But I got this voucher in my phone and it's a valid Nike voucher! The manager: Yes we understand but apologies, the EFTPoS systems is not connected to online loyalty and unfortunately we can't process this voucher. 
Terrible customer experience. She has probably bought the items on total fee but she never forgets this inconsistency with the online and in-store systems.

How does Omni-Channel Payment help in this situation? 

In an Omni-Channel environment, all the channels are emerged into one entry point and collects all user information and has access to all user data. The customer agent to communicate with this unified channel is and abstraction layer over their credit cards: An electronic wallet represented through wearable or handheld communication devices such as Apple Watch or Smart Phones. Now the user profile that already collected the voucher and shopping cart items is stored in their watch or Smart Phones and it will be used at the in-store Point of Sale to process this emerging transaction! The EFTPoS machine, when presented with the customer watch or Smart Phone in via NFC, instead of doing an EMV transaction right away, it collects meta data information form the customer profile and does a price adjustment if needed. Then presents the right price after applying voucher and the customer pays the right amount.

How does Macronodes Omni-Channel Payment Gateway help merchants?

1. Business Intelligence 

Equipped with built-in big data and BI technologies, Macronodes Payment Gateway has access to every bit of information to deliver unique customer experience.

2. Support for both manual and smart device online shopping

 Customer can purchase online by entering credit card information in the PCI-friendly IFrame menu smoothly embedded in the merchant's online store, or they can use their smart device to capture the sales information through digital barcode and finish the payment in their smart device. In this case, the customers have zero necessity to present their credit card information online or even login to another profile such as Paypal to finish the payment.

 3. Same use experience at in-store purchases

 Customers can use their smart device to conduct an NFC transaction. The EFTPoS will use Macronodes value added service plugin to handle both metadata and the financial transaction.

4. Data

 All customer purchases, whether online, over the phone, or in-store will be cleared in a single settlement operation. Therefore, merchants can have a total view of their sales transactions connected to user profiles. They can leverage this unification of data to define better customer loyalty or any other marketing campaign.  

5. The network effect

 Macronodes Omni-Channel solution enables the users to involve their social network and therefore helps scaling merchant business without spending money on advertisement and marketing. 

6. Security

 Cardholders are not have to enter their credit card information every time on different merchant websites. Chargeback and Card Not Present fraud will significantly decrease.

Please contact Macronodes to discuss your solution.