This is a series of posts about our adventure with the most exciting project at, the progressive web app enabling Eko‘s merchants to make payments and financial transactions.

The original post is at:

The Past

About eight years ago, Eko introduced the simplest of all interfaces to bring banking, payments and other financial transactions to the masses: by dialing numbers on a basic mobile phone. But as the smartphones and laptops grew in popularity with our merchants, we introduced other smart applications. One of them was a simple web portal for money remittance called “Connect”:


The old connect portalThe website was immediately successful with our partner merchants, thanks mostly to its simple three-pane interface for quickly transferring money to any bank account in India.

In the last three years, the old Connect portal has already been used to transact for more than 670 billion dollars.

But soon, money remittance service was not enough. We wanted to introduce more services. The only problem was that our engineers had to individually design and build interfaces for these new services. And we realized…

  • we had to manually design and code each page/interface separately. The process was too slow!
  • the three-pane interface was only suitable for the remittance workflow
  • we needed a different interface for different services

And, as a solution, us lazy folks at Eko came up again with our common mantra:

generalize and automate!

Breaking From The Past

So, we came up with the following solution:

  1. The Interaction Framework: to generalize all the financial services (transactions) supported by our platform into interactions that take place between two or more entities.
    For example, a money transfer is an interaction between two bank/wallet accounts.
    Over this generalization, we defined requests, responses, parameters, complex validations, interaction relationships, interaction flows, dynamic behavior, etc. This became our Interaction Framework!
  2. A Progressive Web App: to build a progressive web app and automate the process of providing new services by leveraging the Interaction-Framework. We decided to use Google’s Polymer (which was still in beta, back then) and build custom web components purely on the front-end web technologies.
  3. An API Backend: to design a backend service on Node.js that would be totally decoupled from the front-end app.

In the next articles of this series, I would elaborate on our design decisions and the final architecture and discuss how we finally built the modern progressive web app.


The original post is at: