Designing UPI for eCommerce payments

UPI is a significant innovation in digital payments by NPCI. The UPI mission statement of democratizing digital payments and its focus on being a platform lifts the spirits of the digital payments ecosystem of India. Having seen UPI in its earliest form and launched as a payment method in PayU’s PSP stack, I have seen UPI struggle to match the approval rates of cards and net banking.

If UPI has to succeed as a trusted digital payment method, it will have to match the debit card approval rates, which typically range between 70-75% as an industry average. Let us look at some of the challenges in UPI and how to resolve them.

An asynchronous payment method leads to cart abandonment

A typical checkout experience in India expects the following user interactions:

  1. Select a stored card, enter card details or select a Netbanking option
  2. Get redirected to the bank’s ACS or Netbanking portal
  3. Complete 2FA or a similar authentication

All these steps happens in the same web-browser or mobile-app without user having to switch context. This is where the first challenge in UPI sets in. UPI is designed to work as an asynchronous payment method. The payment, in the case of mobile apps, can only be completed on the customer’s bank app. [There is an alternate flow for the web, which leverages MPIN-based hosted by NPCI. In the interest of mobile payments, the dominant transaction source in India, let’s however focus on app-based flow which is designed as an asynchronous payment method.]

A merchant enabling UPI as a payment method sends a payment request to the customer’s VPA (Virtual Payment Address). The customer receives a request on her bank’s mobile app and makes the payment through the mobile app. Upon success of this transaction, which the merchant identifies by polling a web service, the customer’s order is placed successful. Imagine this on a mobile phone where you have to switch apps for making a payment, and add to this the network chattiness we so often experience. This payment experience is going to face lot of drops.

Payment experience and inter-operability

In order to enable UPI on their mobile apps, merchants (or their PSPs) need to integrate a UPI mobile SDK that is provided by their partner bank. The bank’s SDK can natively launch its own bank’s app when a UPI payment is triggered. However in cases when the customer has a VPA of a different bank, it communicates with NPCI making the customer wait for a notification – often the customer has to switch the app manually!

UPI’s mission is to make payments (and not just funds transfer) inter-operable. The architecture is design around a four-party model (Sender and her bank, Receiver and her bank). While this is operationally active, it is time it is enable in the payment experience. It should not matter whether the merchant’s and the customer’s banks are the same. The merchant UPI SDK should always trigger the UPI:// deep-link that will launch the customer’s bank app irrespective of whether the SDK bank is same or not. This makes the payment experience consistent and truly inter-operable across banks.

SMS vs Push notifications

In addition to the design limitation in the payment flow, UPI relies on push notifications instead of SMS. Push notifications can be delayed and often unreliable for eCommerce payments that can have payment expiry constraints – imagine trying to book a ticket using a payment method that relies on push notification. You are highly likely to miss that favorite seat of yours!

Instead sending a SMS with a deep-link (upi:// ??) supported by the banks works most effectively. Since P2P use-cases do not need the SMS reliability, the cost of SMS-based notification can be passed to merchants or aggregators who wish to use this instead of an in-app notification.

I hope our friends at NPCI are listening and as they have done for RuPay, will rise to turn around UPI into an established digital payment method.

Sphinx for best commercial open source project

powered by Sphinx

Sphinx search ( is one of the fastest developing search engine. Sphinx is used by Craigslist amongst several popular sites. If you have not already tried Sphinx and you are interested in a building your own search engine, give it a shot. Some of the salient features of sphinx is around easier integration with MySQL, fast indexing and support for distributed searches.

Support Sphinx and nominate it for the community choice awards!

The rise and rise of Apple App Store

Today Nokia released its much publicized Ovi Store and reviews have not been too kind. Nokia expects 3.5 million developers in Forum Nokia ‘creating hundreds of thousands of apps‘. Nokia had originally released Ovi in October 2007 allowing customers to buy music and games. By that time, AAPL had already crossed $600M revenue in it’s ‘other music related product & services‘ segment [AAPL includes sales from iTunes Store in this segment]. This prompted me to look deep into Apple’s numbers around the App store using Gridstone’s SEC & Transcripts Search Engine.

Apple has always maintained an edge on all its peers, far and close, and grown consistently. The number of iPhone Apps hosted on the Apple App Store has grown QoQ: 900 (Jul 08); 5500 (Oct 08); 15000 (Jan 09); 35000 (Apr 09).

The July 2008 pricing outline for the app store cited “90% of the apps being priced at less than $10”. Considering 1 billion app downloads over 9 months, Apple would have sold 900 million paid apps over last 9 months. As of today, the top 10 downloaded paid apps on Apple App Store averages to $1 – translating to a whopping $900M revenue in the 9 months period and a yearly $1.2B revenue from Apple App Store. Even if we take a slightly conservative approach and put the number of paid apps to 2/3rd of its 2008 ratio, it would still be $800M of yearly revenue!

Where did Apple report all these numbers? In it’s April 09 10Q Apple reports a $1.2B (6 month ended) of sales from it’s software, service and other sales segment. This includes ‘sales of Apple-branded operating system, application software, third-party software, AppleCare, and Internet services’ and probably includes revenue from the App store. Apple is probably going to make close to $250M revenues from the App store in coming quarters, which is incredible!

[update 27/05/2009] I noticed that the valuations going around on the the internet seem to be between $20-40M in one case ( and an excess of $500M yearly revenue in another ( The devil is in the details. Nobody seems to have an estimate of how many paid apps are actually downloaded. The answer (or approximately so) is embedded in AAPL’s July 2008 transcript where it has announced around around 90% of the apps to be paid and priced below $10. Even if this number has changed, it probably will not be very different.