Money Transfer

How To Choose A Money Transfer Platform

How To Choose The Best Money Transfer Platform For Your Business

By Money Transfer No Comments

Do you know which features to look at before choosing a money transfer platform for your business?


There are a number of factors that define your money transfer business like platform success rate, integration time, pricing, etc.


So, if your answer to the above question is No, don’t worry, this blog will give you a checklist of 6 features you should refer to before choosing a money remittance platform.



  • Easy To Integrate

Is the platform Easy-to-Integrate?


east to integrate money transfer APIs

This should always be your first question when you discuss with a company about integrating their services into your website. Your business should not get affected if the integration takes longer (say a month).


For example, with Eko API Widget you can integrate multiple money transfer APIs and go live within a week.


Understand the integration process before you jump to conclusion. It’s wise to always keep your website developer in the loop if you are a non-technical person. He/she will be able to give you a clear estimate of the amount of time it will take to integrate.


Do check out their API documentation as a first step – Does it have sample responses, error codes, code snippets in different languages?



  • High Transaction Success Rate

high transaction success rate_EkoIt really hurts when a transaction fails or goes awaiting. Before you opt for a remittance money transfer service from a service provider, you should ask “What’s their transaction success rate or how many TPS (Transactions Per Second) their platform can handle?”


If you start using a service before asking this question and face frequent transaction failures, you may lose your customers fast and it will hamper your business.




  • Secure And Safe

Last year a news got viral when Amazon’s Alexa ordered dollhouses after hearing its name on TV for all those people who did not disable the voice ordering or did not add a password to their device.


Cryptocurrency is another industry that faces serious security issues. Take for example Bitcoin.  Their wallets have loopholes that can be easily exploited. Cyber attacks on Bitcoin are very much real. In fact, Bitcoin was one of the most targeted industries.


security protocols in APIs_EkoWe are surrounded by technology and sometimes even the most secure system gets hacked.


Adding security protocol in each API requests makes your system hack proof.


For example, to avoid any fraud, your system should ask for a secret PIN or OTP before making any transaction. This will make your transaction secure.


Also, make sure the sensitive data is encrypted from your server to your service provider’s server.


These features ensure a safe and secure transaction.



  • Dashboard To Manage Business

dashboard to manager businessThe dashboard should provide all necessary reports (like product-wise business growth, invoices, etc.) all in one place so that it’s easy for you to analyze the growth, compare month-wise profits and generate invoices.


It should give you a clear picture of how your money transfer business has performed and the profit you make out of your remittance business.



The dashboard that we give to our enterprise partners, helps them easily track their transactions and business growth.



  • Quality Of Customer Support

Even the finest technology sometimes face a technical issue. That’s normal. But what if the transaction is stuck and your customer is waiting outside your shop to transfer money?

quality of customer supportIt’s very important to ask your service provider “What’s their TAT (Turnaround Time)?” i.e. how much time do they take to resolve different kinds of problems such as

  1. Response Awaited
  2. Transfer done to wrong account
  3. eValue service for NEFT/RTGS/IMPS/Intra-banking

It is best to go with a company that gives 24*7*365 days support.



  • Pricing

We all get attracted to the product that offers more at the least price, but does that product help you build your brand successfully?

pricingPrice is important, but the cheapest product is not necessarily the best. Somewhere quality is always compromised either in terms of customer support, security, transaction issues or difficult integration process.


So, don’t let the price of the product define your business. Choose the service which best suits your requirements.



Since you are building your brand, you should tie up with a company and a platform with whom you can do long-term business, innovate continuously and implement new stuff easily.


You can not afford to invest time and money into multiple integrations.



Over To You


I hope this post will help you choose the best money transfer platform for your business.


If you know of any other feature in a money remittance platform that’s not listed here do let us know in the comment below. We would be happy to add it to this blog post.


If you are looking for a money transfer platform fill your name and contact number here or write to us at and we will get you started instantly.


Share the blog and help your friends/family choose the best remittance platform.


To your success!


Eko API Widget

(Updated) Introducing API Widget!

By Blog, Money Transfer, Remittance, Technology, Uncategorized No Comments

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.


Open Platform

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.


Another Roadblock

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”

On the retail side of Eko’s business, Eko developed a state-of-the-art progressive web app “Connect” combined with an in-house Interaction Framework and an API first back-end.


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.


Open “Connect”

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.


Eko_Connect Widget

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.



Widget Roadmap

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  and we will get you started instantly.

Most popular mobile devices in the Eko merchant network

By Money Transfer, Remittance, Technology, Wallet

Eko works with a select network of almost 10,000 merchants across almost all the states in India who facilitate remittance services for our customers.

A good portion of our merchants transact on smart-devices. The following is a glimpse of the popular device (manufacturers) that our merchants have used in Aug/ Sept 2016:


Samsung, Xiomi and Micromax win,
followed closely by LYF, Lenovo and Vivo,
surprisingly even Apple figures!

Smartphones ki jay!

Eko goes open source!

By Money Transfer, Others, Remittance

Team Eko is glad to announce that we are getting started with open source! You now have access to the best optimised algorithms and UI to process money remittance transactions at your merchant network.

Till date, this money transfer web application has processed more than Rs 4,000 crores and is being used by more than 2000 agents across the country.

Available now at:

blog p1

Now, partners/organizations can use this standalone website and deploy it on their systems. Developers can now modify the code and are free to develop or test our remittance APIs.

Frameworks used:

    1. Python
    2. Django framework 1.5
    3. Knockout.js
    4. Gumby framework

It is recommended to run the project in Virtual Environment  instead of changing the global installations as it stores all the dependencies required for this project in the Project folder itself .


  1. Download or Clone the Repository
  2. Please go through readme.txt for installation instructions
  3. After installation (including population of database), please review the workflow
  4.  Workflow
    1. Capture Sender Details
      • The merchant/agent enters “Sender Mobile Number” and presses “Go” button. This invokes “Get Customers API” which returns the following scenarios:
      • If customer does not exist – Invoke “Create Customer API”, which fires an OTP to the customer’s mobile number. On entering the OTP, the application invokes “Verify Customer API”.
      • If customer exists – Redirect to Recipient box
    2. Capture Recipient Details – In case customer exists, “Get All Recipients” API is invoked. If the list is empty or the customer wishes to send money to a new bank account, then the merchant/agent  can add a Recipient by clicking on “Add Recipient
      • Adding a recipient requires the merchant/agent to enter bank name, bank account details and recipient details. On entering the required details, the“Add Recipient APIgets  called. Different banks require different flows for adding a recipient efficiently, which has been explained here:
      • Selecting any recipient from the list invokes “Get Recipient API” and agent is taken to the Transaction box as shown in the image above.
    3. Capture Transaction Details
      1. Enter the amount of money to be sent and select the Transaction mode. Clicking on “Send moneybutton invokes Send Money API. The status of transaction is displayed as toast at the bottom of the webpage

This is yet another by-product of Eko’s Summer Internship  program under which we hire students from the best universities across the country and provide them a platform to explore our technology. The open source was developed by Siddharth Jandial (NIT J), Kunal Sachdeva (NIT J), Teja Surya (IIT D) and Alankar Verma (NIT R) under the guidance of Mr. Saurabh Mullick.

Recommended reading:

      1. Tutorial on Django –
      2. To know more about Virtual Environment –

Add Recipient Workflow – Simplified!

By Blog, Money Transfer, Others, Remittance, Workflow


We, at Eko, continue to work on providing a seamless and hassle free payment and transaction experience to our merchants, customers and partners.

For sending money to a bank account, a bank account needs to be mapped to a customer’s wallet. For that purpose, “Add Recipient” API is required. However, since different banks require different field parameters for registering a bank account, we have designed a process that simplifies adding of a bank account to a customer wallet.

We have implemented the changes in workflow in our merchant portal “Connect” for money remittance business and now we want to share the same process with our API partners.

4 Simple Steps for adding a bank account

    1. Capture Bank Name – Enable your merchant/customer to first select the bank (figure 1) to which money needs to be transferred. On selecting the bank name, invoke Get Bank API and Eko shall return the following details about the bank like:
      1. Full Bank Name (parameter name “name”)
      2. Account Verification is available or not (parameter isVerificationAvailable) – This signifies if bank has enabled verification of bank account feature or not. If value returned is “1” then verification is available else it is not allowed.
      3. IFSC code required or not (parameter “ifsc_status”) – Signifies if the IFSC code is required for money transaction or not
      4. Channel available for money transfer (parameter name “available_channels”) – This signifies IMPS is available or not and if not then, NEFT channel needs to be pused. The following values signifies which channel is available:
        -> ALL : 0
        -> NEFT : 1
        -> IMPS : 2

        gif 1

    2. Enter Recipient’s Bank Account Details – As a second step, enable your merchant/customer to enter the following:
      1. Recipient’s Bank Account Number – Only bank account number is required for bank, for whom IMPS is available. The next step is point 3.
      2. IFSC Code – If IMPS is not available for the bank selected. The next step is point 4.
    3. Account Name Verification – If Account verification feature is available, then Account Name Info API needs to be invoked, which instantly pulls out the Name of the recipient by either pushing Rs 1 transaction via IMPS or from Eko’s database. In the example shown in figure 2, it shows that for banks like SBI, etc where IMPS is available and account verification is available, only bank account details are required and recipients details are returned in response to Account Name Info

      gif 2

    4. Capture Recipient Details – If Account verification feature is not available, then following recipient details are required:
      1. Recipient’s Name
      2. Recipient’s Mobile Number
      3. IFSC code of the recipient’s BankIn the example shown below, when “Abu Dhabi Commercial Bank” is chosen as bank, for which IMPS and account verification is not available, bank details and recipient details are required

        gif 3
        In the below example, the customer/merchant has selected “HDFC Bank”, for which IMPS is available but account verification feature is not available, and in such cases bank account number and recipient details are required.

        gif 4

After capturing the details of the recipients, “Add Recipient” API needs to be invoked.

Unified Payments Interface / UPI, India – An introduction

By Blog, Money Transfer, UPI

blog imagev1

1. The essence of a payment transaction


Suresh, the sender, who needs to send the money
Ramesh, the recipient, who (obviously) receives the money


An amount, a certain quantity of money (which happens to be with Suresh)
A piece of cake, (which happens to be with Ramesh)


Suresh hands over the amount to Ramesh.
Ramesh hands over the piece of cake to Suresh.

End of scene. What you just saw was a payment in (bad) poetry followed up by a service delivery in lieu. Simple right?

2. The payment plot gets thicker…

Long time ago, with the advent of banking, people began to entrust the banks with their money and instead of directly making the payment (as you witnessed in the previous scene), began instructing their banks to make payments on their behalf. These instructions would mostly be in a written or printed form.

Now, banks by design had to deal with a lot of customers. So, they had to come up with some way to ensure that whenever Suresh asked them to move his money through a written instruction, they would be able to know for sure that it was indeed Suresh who had asked them and no one else.

For a good part of banking history (even now), bankers (and the legal folks) relied on what is known as a ‘wet’ signature. That is, Suresh would take out a pen and draw a scribble that was supposedly unique to his hand. The bankers would visually match the scribble with the scribble they had on record (whenSuresh had ‘signed-up’ for the banking service). If the bank employee handling the written instruction deemed there was a match, the bank pretty much followed Suresh’s instructions and made the payment on behalf ofSuresh.

3. And thicker…

Then came the computers, the internet, data-centers and the age of digital banking. PINs (Personal Identity Numbers) and Passwords got introduced as the shared secrets between the banks and its customers in place of the signature scribbles.

So now, Suresh on his computer would open up a website of The Scissor Bank, fill in a form providing Ramesh’s account number, say:11223344 (more on this coming up!) as the recipient, the amount and his secret PIN/ password.

The Scissor Bank would then digitally match the secrets and move the money to Ramesh’s account.

Suresh and The Scissor Bank have to be triply sure that no third party gets to know his shared secret PIN/ Password. Why? Because if even one more entity gets to know it, it no longer remains their super special shared secret! Right?

That brings us to two more lil’ issues as well.

One, Ramesh has to reveal his unique financial identity (account number: 11223344) as recorded by his bank to Suresh for Suresh to be able to pay him.

Two, if Suresh happens to have an account with The Scissor Bank (the shiny new bank round the corner), there is a need to have a mechanism to first move money between The Scissor Bank and The Rock Bank and then for the banks to individually move money to the designated accounts (not necessarily in that order). This introduced the need for Ramesh to specify additional routing information to Suresh.

Not that this was not partly solved. Card networks (Visa, MasterCard et al) and other switch and settlement providers put the plumbing in place but individually, each left atleast one gap in their service. While one under-rated usability, another killed convenience and another sacrificed security.

4. Enter, the untrusted hero

Then came the online merchants. Shops began to get replicated in the digital world. Suresh could now visit Ramesh’s online ‘’ shop and order a piece of cake and Ramesh would send over one of his delivery boys with what else but a piece of cake.

The Rock Bank and The Scissor Bank were of course happy, since Ramesh had agreed to pay them extra for enabling Suresh (and thousands of others likeSuresh) to buy from his ‘’ shop. Secretly, Ramesh was their hero but they could simply not trust him!

5. The one tiny little big problem

Remember the fact that Suresh and The Scissor Bank had a shared digital secret?

It so happens that when Suresh pays Ramesh on, he has to provide his financial id (account number: 99887766, The Scissor Bank). Which was kinda ok. The scary part was that, for a good while, he did not have to even provide his shared secret to authorize his payment! Which meant that Ramesh (or the evil digital pirate hacker Kruresh) could easily use this information to make Suresh pay for things Suresh had no intention to pay for (like buying a pirate ship).

So The Scissor Bank had to take Suresh’s shared secret and make sure that no one, not even Ramesh could see it. They achieved this but ended up with so many page hops that the payment experience ended up more like a trip down the adventure park. Why? because no page other than The Scissor Bank’s page could be trusted to fetch this information! So the experience ended up looking something like: Ramesh’s cake page hops to a generic payment gateway page, hops to a Scissor Bank page, which then hops to a bank confirmation page and then back to Ramesh’s payment receipt page. Whew! Each hop increased the chance of Suresh, simply dropping off.

Obviously, Ramesh wasn’t happy about it. Suresh certainly was not. Secretly,The Rock Bank was not happy about it and neither was The Scissor Bank.

6. Um… This was supposed to be about something called the UPI right?

Patience, my young friend.

The banking gods in India of course wanted to solve all the woes of all its people. So they decreed into being a not-for-profit super entity called the NPCI (National Payments Corporation of India). Its initial job was to provide a backbone for the inter-bank transactions, which it executed by creating the NFS (National Financial Switch).

Then it took on an even more ambitious product called IMPS (Immediate Payment System). This was a set of pipes that allowed 24×7, instant inter-bank transactions. Only a handful of countries have a payments infrastructure of this stature. Judging by its output, NPCI is evidently led by a set of really fine professionals.

Then, attempting to find a cure-all to all that ailed payments, in one shot, they gave software architecture rock-stars (these folks were also the tech forces behind the colossal UIDAI project) Pramod Verma and Sanjay Jain, among others, pretty much an open canvas to paint the picture of an ambitious piece of national payments infrastructure that would be a cure-all of sorts. Thus was born the Unified Payments Interface a.k.a. UPI.

7. Now back to the story

While UPI is capable of a lot of things related to payments and funds transfer, this story will only focus on a few things that are at its core. (Also, please be aware that these are the early days for UPI and my understanding may need improvements :). Anyway, here goes:

7.a. Introducing: The PSP

A PSP (Payment System Player) in the UPI ecosystem is a certified and trusted entity that acts on behalf of a bank (in the future, should technically be open to non-banks as well who are authorized to hold deposits). The PSP is actually the technology platform provider. Could be the bank itself or it could be an entity which works with a bank/ on behalf of the bank.

So, assume for now that The Rock Bank has a PSP named Rock and The Scissor Bank has a PSP named Scissor. The PSPs are the payment end-points as far as NPCI is concerned.

7.b. Introducing: The virtual address

Remember the problem where Suresh and Ramesh for various reasons had to make known to each other, their financial identities? While that by itself might sound benign, there are many situations where revealing one’s financial identity might be dangerous. For sure it is cumbersome.

So UPI talks about this thing called the virtual address. A virtual address takes the simple form of address@provider

For example, if Ramesh’s account with The Rock Bank may simply be calledramesh@rock and Suresh’s account may simply be called suresh@scissor

This is a simple format similar to email ids. Where this gets interesting is:

  1. Suresh could have a virtual address suresh@rock even though his bank isThe Scissor Bank!
  2. The validity of a virtual identity is absolutely flexible. So if The Rock Bank(which is the provider for @ rock addresses) so enables, this might be a permanent address or just a Monday address or even a one-time-use address or an address for only loose change! The definition and implementation is completely left to the provider. Neat!

Now, tokenization services already exist, especially where cards (ATM/ Debit/ Credit) have been involved, for similar reasons.

The virtual address concept however is fundamentally superior due to the following reason: While the token system is required to be provided only by the issuer (the entity which has issued the original card/ instrument/ holds money on your behalf), virtual address is a token service that is loosely coupled to the original issuer. Thus any PSP could issue a virtual address for any customer with any bank and on top of this, implement any business rule for its access. Also, the addressing scheme is much more inclusive and human-readable.

7.c. Introducing: The Common Library

Remember the fundamental ‘one tiny little big problem’ we talked about a bit earlier, due to which no one could ever safely collect customer’s shared secret except on the original issuer’s own interface?

UPI solves this by providing a mutually trusted interface. It does this through a common client library (currently provided as an Android SDK) that each PSP could embed in its customer facing app. The job of this piece of software is to provide a user interface to securely collect the user’s credentials (PIN/ password/ biometric) such that no one except the original issuer could decipher it.

Assume a case where Suresh is sending money to Ramesh but using a third PSP called Paper belonging to The Paper Bank.

[Recall that Suresh’s bank is The Scissor Bank and Ramesh’s Bank is The Rock Bank, it is eminently possible for Suresh to use neither of these two PSPs but a third one while still using the same underlying bank account! Why? Just because Suresh seems to like it so! – such a level of choice is customer empowerment by design]

The common library provides the underlying (acquiring PSP) Paper’s app only a context locked and encrypted credential block. Paper can only pass it on to NPCI through the UPI RequestPay API ‘as is’. The UPI framework will of course pass it on further to the original PSP (Scissor) for authentication along with the rest of the transaction payload.

There is another neat little trick up the sleeve of the common library. PSPs using the common library expose a deep linking hook (upi://pay/…) to merchant apps and web services that need to simply collect payments, without worrying about the implementation.

Imagine a merchant app JustAnotherKart which wants to collect payments, it simply has to invoke the deep link on the phone and the phone will display a list of all PSP apps available. The customer can then choose one and authenticate the payment.

7.d. Asynchronous by design

The most delightful thing about the way UPI has been constructed is by making everything asynchronous.

Most other online payment systems are synchronous request-response systems where the transaction acquiring system sends a transaction package and waits for a response. Asynchronous systems on the other hand are pretty cool. They send the transaction request and then chill out and do other stuff. Once the servers and other parties have processed the transaction, they call back on a designated API end-point exposed by the requesting party and simply update the status of the transaction. This enables robust implementations.

8. The creamy layer

Very interestingly, UPI is a set of services that sits as a layer on top of existing national financial pipes put in place by the NPCI. So it acts as a value adding layer, the creamy layer which does the following core functions:

a. Provide a layer of secure communications. By incorporating a cryptography protocol that requires each trusted end point viz. the PSPs to be able to communicate securely to the UPI APIs it ensures that a transaction is securely transmitted end-to-end.

b. Provide an address translation layer. Enables resolution of virtual addresses to the underlying financial addresses.

c. Provide a protocol for transaction request and response flows.

d. Provide a framework for liability, settlement, risk and issue resolution. This comprises of things that take place behind the scenes to make the actual flow of funds between the banks.

9. The end, almost

All in all, UPI is a futuristic payments infrastructure designed for India.

  • It makes it easier for people like Suresh and Ramesh to participate in the new digital economy.
  • It opens up the underlying banking infrastructure to payments and systems innovators to make apps and products that would otherwise never have seen the light of the day.
  • It helps the banks to stay relevant in these times by decoupling the storage and movement of value from the interfaces that could enable it efficiently.
  • A short-sighted view would be that it helps the banks compete with the new-age wallets. The better perspective is that it creates a more inclusive and inter-operable ecosystem comprising of all stakeholders (wallets will also be allowed in the near future, we are told).
  • It empowers the customers by giving them choice. No longer will a customer of bank A be locked into using a sucky mobile banking app provided by bank A. It essentially decouples transaction initiation and collection of authentication from the banks’ interfaces.
  • Improves the UX for merchant app checkouts. When implemented, this should be better than the page hop-skip-and-jump routine being imposed for securing transactions today.
  • Presumably, it lowers the transaction costs because of its superior design, interoperability, scalability and systemic risk reduction.

In the end, it is good to remember that all that Suresh actually wanted was to eat a piece of cake and all that Ramesh wanted was to keep baking them! Banking, wallets and all the technology built around em are pretty much a bunch of necessary evils. The best that they can aspire to be is to become as invisible and trust-able, as soon as possible. UPI seems to be pointed in that direction.

Further reading:


This article was published by Anupam Varghese, VP – Products, Eko

Link to the actual article is here:

How to launch money transfer services?

By Blog, Money Transfer, Others, Remittance, Wallet

blog image v4

You must be thinking that launching money transfer services in your merchant network would be a lengthy process. Eko has launched its APIs that allow you to launch money remittance services in your network in a jiffy. All you need to do is follow the five steps mentioned below:

1. Simply “Sign-in” on the developer portal and start experimenting with the staging APIs. If you like the APIs and it fulfills your requirements, please send an email to partnerships@ with your contact details.

Within 24 hours, our team will get in touch with you and guide you through our on-boarding process & commercials.

2. Complete Documentation Process – As a next step, you just need two soft copies of the following KYC documents (as per the table below) to get you on-boarded. Please ensure that the copies are self-attested.


We will send you two copies of the agreement. Please sign them and send it back to us.

3. Start API Integration – Create a working prototype of your remittance solution and share dummy user login and password with Eko team.

4. UAT Signoff – Eko’s Compliance and Quality Assurance team shall do a UAT of your solution in order to check if integration is consistent with Once Eko gives UAT signoff to the prototype, production credentials would be shared along with operational information.

5. Go Live – You would need to replace staging credentials with production credentials and staging URL with production URL in your code. And your product will be ready for launch!



Enable remittance services using Eko APIs

By Blog, Money Transfer

We are delighted to announce that Eko has launched Wallet based remittance/money transfer APIs. We, at Eko, have always believed that any network managers or other distribution networks should be able to provide remittance services to customers at their merchant outlets by simply integrating with our APIs. 


If you are looking to  provide remittance services at your merchant network, you have to simply follow the workflow mentioned below:

1. Check if customer wallet exists or not – If a customer checks in at your merchant, the first step should be to check if the customer has already used the services or not. For this, call Get Customer API. If the response is that customer exists then simply call Get List of Recipients API (Point no. 4) for that customer and otherwise call Create/Update Customer API. (point no .2)

2. Create a new customer wallet – To create a new customer’s wallet,  call Create/Update Customer API. The merchant needs to capture the following details to open the wallet:

1. Name

2. Verified Mobile Number – The customer’s mobile number can be verified by OTP mechanism or through a missed call. For completing the verification of a customer’s mobile number, you need to call Verify Customer API.

3. Add Recipient to a customer – After successful wallet creation, the merchant would need to add a recipient to whom the money needs to be transferred. In order for a customer to verify if he/she has provided correct bank account details or not, the following process needs to be followed:

1. Get Bank Details – To know if the recipient’s bank has account verification feature enabled or not, the merchant needs to enter the bank name. For this, you need to call the Get Bank Details API. This API will return if the IFSC code is required to be entered or not and if verification of account is available for that bank or not.

2. Smart Verification of Bank Account – If verification feature is available, then merchant needs to enter the account number as mentioned by the customer. For this, the Get Account Name API needs to be called. Eko returns the name of the beneficiary and other details when available in response. On receiving details like name of the bank account, the customer/merchant can correctly confirm if he intends to send money to the bank account he provided or not.

3. If bank account verification feature is not available for the bank mentioned then merchant has to enter more information about the recipient like:

a. IFSC Code

b. Recipient’s Name

c. Recipient’s Mobile Number

4. Show List of recipients for a customer  If a customer already exists, then a list of recipients needs to be returned so that the merchant can select the recipient to whom the money needs to be transferred. For this, Get All Recipients API needs to be called. In case the customer wants to send money to a new recipient, then Add Recipient API needs to be called.

5. Send Money to the selected recipient – After selecting the recipient to whom the money needs to be sent, the merchant would need to enter the amount that needs to be entered and some authentication mechanism like OTP or static pin to authenticate. After capturing the transaction details, Send Money API needs to be called. On successfully transferring the money via NEFT/IMPS, the merchant and the customer would receive SMS receipts for the transactions.

If you would want to start remittance services in your agent network, please check out the APIs at or write to us partnerships@ and we shall get you started very quickly.

Read More