Eko was founded on the basic principle of enabling financial transactions for anybody from anywhere. In the evolution process, Eko pioneered domestic money transfer service where customers earning in cash could simply remit money to their family by visiting a nearby shop. This model brought about Retail 2.0 where every retail shop wanted money transfer service. This Rs. 1 lakh cr per month opportunity also attracted big and small companies in the fray.
Eko did a great job of establishing a tech-driven efficient retail network of +25k outlets achieving unit economics. This only means driving maximum business with fewer people and paper involved. We have a mantra at Eko to be “Paper-less and People-less”.
The retail model still had a limitation – the business generated was directly proportional to the number of retail outlets acquired. For example, if you have 10 front-line managers each managing 500 outlets, then if the number of front-line managers is doubled then only the business would be doubled. Being a tech company, we wanted to disrupt this equation.
In 2015, Eko finally decided to open its platform so that any other third party organization could run a money transfer services on top of Eko’s platform. This was truly revolutionary and democratic since it allowed Eko to service customers in those nooks and corners of the country where Eko did not have any front-line managers.
In 2 years, Eko has +200 enterprise partners processing double the amount of transactions than its own retail network.
Driving inspiration from the Android story, Eko decided to further build the enterprise platform where “Made in India” desi payment applications could be made. While the number of applications using Eko’s platform was increasing but there was another challenge – The small enterprise partners with small or no technology teams were taking significant time (~2 months) to integrate with APIs.
With a minimum design and UI/UX background, the small enterprises were struggling to get their services live thereby losing business numbers.
Eko’s Interface – “Connect”
Interaction Framework is, in short, like a content management system for financial transactions. It defines a transaction in terms of one or more financial entities and how they interact with each other. This eases and automates the process of building dynamic yet simple and intuitive process flows for making financial transactions.
Eko opened Eko’s Connect UI as an API widget for our enterprise partners. Integrating Eko API widget in their application would take care of most API calls and give the enterprise a ready-made UI thereby requiring minimum coding.
Connect has been built in a modular way using latest web technologies like Web Components, Shadow DOM, etc that enables us to expose and embed any part of the Connect into any other web app in a very secure and seamless manner. We will talk about how to integrate the API widget in detail in another post, meanwhile watch the below video to know more about API widget.
Eko will further open more transactions like AePS (Aadhaar enabled Payment System), BBPS (Bharat Bill Payment System), recharge, etc on the API widget in future where simply you would change one parameter and the enterprise would be able to use it for other purposes as well.
Start your money transfer business here. For any queries drop a comment below or write to us at firstname.lastname@example.org and we will get you started instantly.
During current times of big cybercrimes and security hacks across the world, it is extremely important that your system is very secure. Especially, the industry that we work and the number of stakeholders like merchants, distributors, employees, etc involved, it is imperative for all DMT systems to be hack proof. As you scale your DMT business, your systems need to get more secure.
Current API Security System
Currently, we only ask for a static developer key for authentication and identification. We do communicate to our all API partners that their developer key is confidential and should not be shared with anyone. And only “developer_key” is not enough to secure the API call. There is a still some chance of a man in the middle attack. If the developer key gets compromised then anyone can misuse your credentials to do transactions. These security compromises can be catastrophic in remittance businesses. We have seen 2-3 such security compromises every 6 months for our API partners. Eko identifies these risks and has come with an improved API security system.
We have introduced two new parameters in our API ecosystem which will improve the API security
The above 2 parameters need to be passed in each API call and should be passed in the request header like developer_key.
How to generate the secret key?
Steps to generate the secret-key and secret-key-timestamp
- Encode key using base64 encoding technique
- Generate current date in milliseconds which will work as salt i.e. secret-key-timestamp
- Compute the signature by hashing salt and base64 encoded key using Hash-based message authentication code HMAC and SHA256
- Encode the signature using base64 encoding technique and use this as secret-key
A major pain point for our distributors, API partners and merchants was the unavailability of IMPS for certain recipient banks while remitting money. In such situations, we would compel our partners our partners to necessarily use NEFT. This severely affected the customer experience due to the time taken to reach the recipient. We wanted to give the luxury of immediate money remittance services to our end-customers at all times. This is the underlying motivation behind giving the capability to schedule transactions.
Even if a recipient bank IMPS is down, the merchant is shown IMPS as a payment mode and the transaction proceeds as usual. Except he/she is shown a message that their transaction will get scheduled and kept in a queue. A scheduler at the back-end will keep trying to push the transactions every 15 minutes. This process will keep recurring for approximately an hour (this time is configurable). After this, the scheduler stops and the merchant is notified about the transaction. The merchant now has three options:
- Reschedule the transaction: The scheduler starts again and tries the same process for another hour.
- Convert to NEFT: The transaction is pushed with NEFT as the payment mode.
- Refund: The merchant can initiate a refund and return the money to the customer.
In case the merchant forgets to choose one of the three actions above, then the system auto-refunds the transaction after a maximum 24 hours. In this way, there are now transactions lying idle in Eko system.
The auto-refund feature further acts as a proxy to convey adoption of this feature. The higher the system auto refunds, the lower the adoption. Additionally, we are able to drive the adoption as we can also uniquely identify the auto-refund transactions and the merchants executing those transactions. This has helped us drive the numbers and support additional business volumes that were lost to us before.