Monthly Archives

May 2016

Unified Payments Interface / UPI, India – An introduction

By | Blog, Money Transfer, UPI | No Comments

blog imagev1

1. The essence of a payment transaction

Actors:

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

Props:

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

Action:

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 ‘piece-of-cake.com’ 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 ‘piece-of-cake.com’ 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 piece-of-cake.com, 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:

http://www.npci.org.in/documents/Unified_Payment_Interface_API_Technology_Specifications%20_v121.pdf

…………………….

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

Link to the actual article is here: https://medium.com/@anupamvarghese/unified-payments-interface-upi-india-an-introduction-plain-and-simple-9bd11bfd5fbc#.cyy13c5z8

How to launch money transfer services?

By | Blog, Money Transfer, Others, Remittance, Wallet | No Comments

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 developers.eko.co.in. and start experimenting with the staging APIs. If you like the APIs and it fulfills your requirements, please send an email to partnerships@eko.co.in 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.

Picture1

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 http://blog.eko.co.in/enable-remittance-services-using-eko-apis/. 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 | No Comments

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. 

Eko_pic

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 developer.eko.co.in or write to us partnerships@eko.co.in and we shall get you started very quickly.

Read More