PhonePe’s 1st Birthday — Our Story Thus Far

Earlier this week we celebrated our 1st birthday, and the journey thus far has definitely been filled with many amazing ‘1st’s:

1st Android app for UPI-based user services (Aug 2016)

1st UPI-based app to cross 10 Million app downloads (Jan 17)

#1 Finance App on Google Playstore

1st iOS app for UPI-based user services (Jan 2017)

#1 Finance App on Apple Appstore too!

#1 in total UPI-based payment transactions processed in India.

1st fully-embedded PG solution (including UPI-based payment option) for 3rd-party merchants (the ‘PhonePe embedded SDK’)

These milestones were made possible in large part, thanks to the love, support and regular feedback from all our users, and for that we thank you all!

As in the movies though, the Good, the Bad & the Ugly always seem to travel together. We were naive in hoping that we’d be able avoid them for much longer.

First the ‘bad’ happened!

On Friday the 13th (ominous date. huh?), ICICI Bank blocked all its customers’ UPI transactions to/from ‘@ybl’ handle users. This happens to be the UPI VPA Handle, assigned to us by YES Bank, so ICICI in effect has also blocked all its customers from using all PhonePe products too.

Then the ‘ugliness’ started

During the past week, ICICI Bank and NPCI have made multiple public allegations — with an ever-changing narrative — against PhonePe. The first reason cited for the blockade was ‘data security concerns’ (may we ask what these are please??), then it was ‘restrictive trade practices’ (somehow this was concluded within 24 hours of our Flipkart integration going live. Hmm!) and finally the allegation has shifted to ‘violations of UPI inter-operabililty guidelines’. So which is it folks?

We’ve been responding patiently to these allegations with data and facts. Finally, on Thursday, NPCI issued a public release asking ICICI Bank to immediately remove the blockade. Then they’ve seemingly reversed their stance (what changed?) and claimed in a press release to have ‘directed PhonePe and Flipkart’ to make certain changes- yet again without elaboration of what exactly these violations are, or what changes they want to see. We’re yet to receive any official notice from NPCI on this matter to date.

Noteworthy to mention here is a little legal fact that NPCI has no direct legal jurisdiction to ‘direct’ PhonePe or Flipkart to do anything..

1. NPCI can direct its member banks.
2. PhonePe is YES Bank’s client, not NPCI’s client.
3. Flipkart is PhonePe’s client — definitely not NPCI’s.
   We have no direct agreements with NPCI.

But let’s stop splitting hairs. We all want this saga to end for the larger good of the consumer, and for the UPI star to keep shining bigger and brighter.

So we’ve decided that it’s in everyone’s best interest to publish our own detailed views on the matter, directly via this blog. This way, there is no conjecture on where we stand…

Here’s our side of the story

We strongly believe in the potential power of UPI to transform digital payments in India forever. That’s why we entered the UPI ecosystem so early, and have worked hard to build what is being hailed as the best P2P money transfer and payments app in the country. Our rapid growth and users’ testimonials is a reflection of the same.

So what exactly is PhonePe and how is it different?

PhonePe is a consumer-facing payments container that allows the user to use the payment instrument of their choice (cards, wallet and/or direct-from-bank payments using the UPI rails) based on the size and nature of the transaction, with the confidence that wherever you spend or to whomsoever you send money to, PhonePe will help ensure that your transaction happens smoothly. The many comparisons to various other UPI apps and UPI-based Payments apps shows us being the frontrunner in the eyes of our users.

ICICI Bank in its unilateral decision to block any and all transactions associated with the YES Bank VPA (@ybl) has deprived a very large set of early adopters of UPI from using their preferred channel to avail of UPI-based payments. In doing so, ICICI has cited two broad reasons — Security concerns around data being available to a third-party and lack of inter-operability for UPI-based payments in our apps/sdks. Both these claims are still unsubstantiated and it is our position that both are invalid claims. Rather than celebrating the success of UPI jointly and working together to build the ecosystem, ICICI chose to flex its muscle to overcome what they believe is competition. Here is the breakdown of how wrong they are.

So Called Security Concerns

PhonePe has been providing UPI-based payments using the YES Bank PSP SDK since the launch of UPI itself. All applications that launched UPI-based money transfers and payment solutions had to go through a stringent certification process laid out by NPCI that involved third-party audit firms to conduct independent application security and server vulnerability testing. Post that, there were closed user group tests to confirm that transactions routed via every bank handle was meeting the minimum bar for performance and scalability. The PhonePe app with the YES Bank PSP SDK has gone through these tests and only on the validation of these test results did NPCI allow the release of the application. Given these facts, making a press statement that data security is a concern without having reached out to any of the parties involved (YES Bank, PhonePe and/or NPCI) is nothing short of scaring our consumers without reason. Statements from YES Bank and NPCI reconfirming our position make us feel vindicated on the security front, and I believe our users are discerning enough to understand fact from fiction.

As a technology startup that is most supportive of the NPCI vision to make digital payments in India happen through UPI, we have always provided information and highlighted operational issues that has helped NPCI shore up UPI on many occasions, including identifying potential data security issues. NPCI has always been welcoming about our suggestions and been highly proactive in addressing any issues that we have identified. As an early mover, we could have used this information as a competitive advantage, but our goal has and will always be to make UPI successful and grow the digital payments market. We are more than happy to fight competition solely on the basis of building a better product.

PhonePe Isn’t Interoperable. Or Is It?

PhonePe launched UPI-based payment support on Flipkart and Myntra website in Oct 2016 using an API-based collect call model. This model involves the user having to open up their preferred UPI-enabled app to complete the MPIN entry. This solution is sub-optimal since it requires the user to change their app context to complete the payment. To improve the consumer experience, we launched a new solution that allows consumers to pay using UPI while staying within the Flipkart Android App. This solution is called an “embedded-SDK” solution. Both the above solutions have ALWAYS allowed a user to choose to pay using any VPA and conclude the payment on ANY another UPI app such as Pockets, BHIM etc. As I write this, more than 13,000 users have successfully completed UPI payments using 3rd party (non-ybl) VPAs through PhonePe products.

NPCI has a log of every UPI transaction obviously, and is free to challenge this claim. In fact, we’d welcome if they can publicly share details of how many users have successfully completed UPI transactions using 3rd party VPA handles on all the other UPI Apps (ie, Pockets, AxisPay etc), and other UPI-based Apps (PhonePe, Truepay etc).

So, What’s Causing So Much Confusion?

We believe the main issue relates to a rather unfortunate misunderstanding on where and when the inter-operability guidelines themselves come into play.

PhonePe’s Payment SDK on 3rd party merchant apps requires the user to first login to/register a PhonePe account before accessing any of our services. But, once a user is logged in and decided to pay for something using UPI as a payment option, we never mandate a user to link their Bank account to a @ybl handle.

As you can see, users are always free to enter a 3rd party VPA Handle and fire a collect call to their preferred PSP app. This was the case today on Flipkart until Friday night, when we decided to temporarily suspend our services on Flipkart until the matter is properly resolved.

Some quarters call this is an opportunistic growth hack, but our motivations for forcing users to login is simple. PhonePe is a consumer facing payments product — like PayTM, Freecharge or Mobikwik. It’s not a B2B payments aggregator like Citrus, Billdesk or Razorpay. We support multiple payment options including UPI, our own digital wallet, Credit cards and Debit cards. So we do (at least) a limited KYC of our users to create their wallet accounts (this is an RBI mandate for all PPI issuers!). Also, users who’re registered with PhonePe can save their preferred CC/DC card details and won’t need to enter 16 digit card nos every time. Similarly, they’ll be able save their preferred UPI VPAs (including non-ybl handles) with us if they choose to do so. A login-based relationship with a consumer opens up many many interesting opportunities to simplify their digital payment flows.

Moreover, we want our consumers to feel confident about the security and reliability of transactions done on any merchant site/app, if they use PhonePe to complete the payment. Also, given how nascent UPI itself is today, we believe its important to have a direct relationship with the consumer too. There are many articles already citing problems with auto-reversals of UPI money transfers and many payment aggregators have voiced their concerns openly about the same. We have ourselves seen multiple issues with bank debits on failed transactions not getting reversed automatically. In such a scenario, we believe that we should not behave like a mere spectator in the transaction path.

All the above choices are our, and I’m sure we will adjust and adapt our product choices at time goes by. But our choices shall be guided by our customer’s and merchant’s feedback only. Our UX choices cannot be driven by demands from individual banks to adhere to what they believe constitutes a great digital payments experience. It would be very unfortunate if big banks hold back the power of UPI, by enforcing their standards of consumer application design, UX and usability on other non-banking digital payment companies. Innovation is nobody’s captive angel.

Here Are Some Points For Merchants To Ponder Over:

• PCI hasn’t published its Merchant/P2P Guidelines in the public domain yet, but as we’ve just found out, merchants are beholden to all these guidelines anyways.
• Per the NPCI guidelines, as relayed to us by YES Bank, all merchants who want to integrate a bank’s PSP SDK for UPI payments (like we integrated YES Bank’s PSP SDK) must get a security certification from NPCI by February 28th, 2017. Your Bank is responsible for ensuring that you complete this certification in time.
• Will end merchants like Uber, Flipkart and Snapdeal be allowed to specify what their own payment pages look like, or is it the large Banks view that they will dictate the UX and Consumer flow choices of merchant sites/apps?
• If an end merchant believes that a payment request taking the consumer away from the merchant property (like the UPI Collect or Intent flow) is poor consumer experience and instead they like the inline UPI payments flow, shouldn’t the merchant be able to exercise that choice?

Here Are Some Points For Banks To Ponder Over:

• Can ICICI or even NPCI direct PayTM to allow users to make third-party VPA transactions on Uber without asking users to login to PayTM first?
• If this happens, is ICICI threatening to block its own @icici handle (which they’ve assigned to PayTM) if PayTM still asks its users to login??
• Can ICICI block @axisbank handle if (say) Freecharge integrates Axis Bank’s PSP SDK so its consumers can make UPI-based payments, and Freecharge’s own SDK is integrated on Snapdeal.

Here Are Some Points For PG Aggregators To Ponder Over:

• We’re sure payment aggregators (aka ‘Master-merchants) like Razorpay, PayU, TechProcess, Billdesk etc would like to offer UPI-based payment options to their 3rd party merchants. These master-merchants often compete directly with large banks for large merchant accounts. Who will define the rules of the game here, to prevent unilateral decisions being made in these situations?
• How will Payment aggregators like Citrus and PayU, that offer saved cards with a user login, support UPI payments? Will they have to offer some benefits/features before a user logs in, and some later? Will NPCI now also tell, and their end merchants, how to design their other Payment page UX flows?

In closing, we believe that the need of the hour is not to block one another, but to engage in more open discussions with all the stakeholders — Merchants, PGs, Aggregators, Banks and Consumers — voices being heard. That’s the only way for the UPI vision to be fully realized, and more such unfortunate episodes to be avoided.