46. UPI AutoPay
Thanos, the mad Titan, is one of my favourite super villains. He is totally mad with a slight philosophical inclination. Thanos had one goal: collect 6 Infinity Stones and with the ‘snap’ of a finger, cull half of all living creatures so the other half can live a life of plenty. For the Mad Titan, that is the way to create ‘the perfectly balanced’ universe.
Let’s say Thanos jumps out of ‘Marvel Universe’ to ‘Payments Universe’ (of course, after proper counselling) with the vision to create a perfectly balanced recurring payment solution… Then what would that perfectly balanced solution be?
Let’s start with the requirements of recurring payments
Based on the frequency/periodicity of debit and the debit amount type, below are the possible use cases:
Requirements from stakeholders:
Next, let’s understand what are the requirements from the merchant (who wants to collect) and the customer (who is paying)
In a nutshell, Thanos’ perfect recurring solution should address all possible use cases and at the same time, must have extremely high coverage, low cost, seamless user journey and be efficient in performance. That sounds simple… isn’t it?
But I bet it will be more difficult for Thanos to build the ‘utopian recurring payment solution’ than fighting Avengers… why so?
Let’s revisit what we have and then come to what we got recently
In the offline world, recurring payment started with post-paid cheques and then came RBI’s ECS (Electronic Clearing System) and then came NPCI’s NACH (National Automated Clearing House)
In the online world, Standing Instruction on Credit Cards and later, a few debit cards were added to the solution and then came NACH’s online version (e-NACH or e-Mandate).
Note: Apart from these mainstream solutions, there are other recurring payment solutions. Direct Debit (Offered by selected aggregators on a handful of banks) and on-demand/recurring debit on wallets (remember how Uber used to debit PayTM wallet after completion of the ride?)
Similar to the Infinity Stones of Thanos, each of these solutions have positive sides but are not sufficient to create a harmonised recurring payment (refer the illustration 5 for detailed comparison).
Here is the intermediate summary
- Post-dated cheques — multiple issues. So in simple words — What? Why are we even talking about those?
- ECS is super inefficient and almost defunct now (no need to talk about it)
- NACH (Paper Based): It is paper based.. Flat fee model is super economical but delay & failures in registration & debit of mandate are a buzz killers
- SI on Cards: Realtime solution but limited coverage (only Credit cards and handful of Debit Cards) plus charges in percentage, so, it’s expensive in case of higher ticket size. Most importantly, it cannot be enabled for a few sectors (NBFC, MF etc.) and also, remember the card has expiry date so need to keep registering new SI every couple of years.
- NACH (Online): Limited coverage with 35+ banks but issues with real time registration and debit status and not to mention the “not so” user friendly flow
Note: Please refer these links to know more about SI on Cards, eNACH and Paper Mandates
Then… the UPI
Another important Infinity Stone, UPI 2.0 (released in 2017) disappointed many as it didn’t have recurring payments modules but just one (1) time mandate. The only best use case that I have seen is IPO subscription.
Then came, UPI AutoPay
Another Infinity Stone that can fix the recurring payment problem… NPCI announced its launch on the first day of the Global FinTech Festival. Let us analyse the solution
Mandate Life cycle
UPI Auto-pay mandate has various life cycle stages: Registration, debit, modification, pause and cancellation.. But before we start with life cycle, let’s see who all are involved
A. Mandate Registration:
Like any recurring payment solution, even Auto-pay works within boundaries and that is defined by mandate parameters. And these parameters are
- Start date: date from which mandate is effective)
- End date: end date of the mandate)
- Amount type: Maximum — any amount below this can be debited or exact — Same amount to be deducted
- Frequency: Daily, weekly, monthly, yearly, As and when presented
Amount type and frequency are interesting parameters… Depending on the use cases (as shown in Illustration 1), mandate has to be registered. Example: If the frequency is fixed and amount is variable (e.g. Vodafone postpaid bill where monthly bill amount may vary) then the parameter should be Amount Type: Max and Frequency is Monthly.
But if the frequency is not fixed (e.g. auto top-up of the wallet when balance hits the threshold) then frequency should be ‘as and when presented’ (kind of on-demand debit)
Merchant can initiate the mandate registration and the customer will approve from his/her UPI App.
Also, users can set a mandate on their UPI Apps for either P2M (mandate for Vodafone) or P2P (paying monthly salary to driver). The first case is tricky as it will throw off the reconciliation. So the PSP may not allow user initiated P2M registrations.
B. Mandate Debit:
Merchant should send debit notification to customer (on UPI App) 24 hour before the debit. The debit notification will have the debit time and the debit has to happen at that time. This is a unique process that is not available in other recurring solutions. It definitely gives more confidence to customers about the debit as (1) customers will know about the debit and not be surprised (2) customers can stop the debit (As that control is with the customer)!!!
Note: Customer has to enter the mPIN for the first debit for the merchant unless the debit is happening within the 1 minute of setting up the mandate.
C. Mandate Modification:
Only the end date and amount can be modified and for any other changes in the parameters, the entire registration process needs to be repeated as a mandate is built on Acquiring PSP, UPI App (on which mandate is set) and underlying bank account (if you wish to change any of these then it is as good as new mandate so new registration). Mandate can be modified by the customer (if mandate is customer initiated) or merchant (for merchant initiated mandate)
D. Mandate Cancellation
Mandate can be cancelled by a customer at any point of time via the UPI App where it is set (G Pay, PhonePe etc.). A merchant can also cancel the mandate.
E. Mandate Pause:
A merchant can pause the mandate and so can the customer.
Note: In case the user pauses or cancels the mandate, then the merchant’s acquiring PSP will intimate the merchant about the actions by the user.
Commercial Structure:
Pricing structure for the UPI Auto-pay will evolve over the period of time but below is the present structure.
a. Mandate Registration fee (Flat fee)
b. Mandate debit fee (slab wise flat fee)
c. Mandate on file fee (sort of yearly maintenance fee… Rx. X per year per mandate)
Banks/aggregators may simplify this structure and offer only mandate registration & Mandate debit fee.
Limitations (or Scope for future enhancements)
The present form of UPI Auto-Pay also suffers from certain limitations
- Transaction limit: Up to Rs.15,000 (earlier limit: Rs.5K) and if the amount is above Rs.15000 then the flow would be standard collect flow (user has to enter the mPIN)
- Notifications: For some use cases, it is not practical to send notification 24 hours in advance (e.g. Swiggy order or wallet top up or Ola rides, as user may order or take ride multiple times in a day or wallet might need to be topped up 2–3 times in a day) (I presume Auto-Pay cannot be used efficiently for Q III and Q IV of illustration A of cases.
- User power (too much): Auto-pay allows users to cancel the mandate and a typical NBFC won’t appreciate it as they would want control on debit when it comes to monthly loan repayment. So if the mandate bounces (either customer cancellation or insufficient balance) then the merchant would need remedy under Negotiable Payment Instruments Act
- Too cold to SIP: Mutual fund SIP is one of the biggest use cases for recurring payment, but all transactions should be done from a registered bank account only (Third Party Validation — TPV). Although UPI has this feature but I don’t think UPI Autopay is covering in-built TPV so the FinTechs/Aggregators/banks need to build it separately
- Commercial Model: Present cost structure is on the higher side compared to eNACH and complex with 3 slabs that includes annual mandate on file fees. When UPI is meant to simplify payments, the pricing should also follow same philosophy (i.e. simple)
Comparison:
Let us see how UPI Autopay is fairing compared to other solutions
UPI is an amazing payment ecosystem with multiple stakeholders (merchants, users, acquiring PSPs, UPI Apps, Issuers, NPCI). UPI is a great success story because every piece of the ecosystem worked like a well-oiled machine plus the GOI pushed it. But that is not the case w.r.t. UPI Auto-Pay.
Four months after the launch, the ecosystem is not completely ready. There is still a delay from UPI Apps and issuers to implement this flow. UPI Apps need to have mandate management section (refer to illustration from G Pay App) where user can see all mandates and manage them (approve, cancel etc.). Anyway, that is how eNACH was also evolved… one bank at a time and now there are more than 30 banks.
It is too early to conclude whether UPI Auto-Pay will be a success or not… let us wait how NPCI will solve the limitations. And as we know, already NPCI did solve one limitation i.e. transaction limit was increased from Rs.2000 to Rs.5000. But most importantly, I am curious to see whether the ‘scared / suspicious’ Indian user will adapt to this recurring payment solution.
In my view, there is no silver bullet to any problem… we need a combination of all the solutions… and that rule applies to Thanos’ ‘harmonised recurring payment solution’… maybe Thanos needs to wait longer, like he did in the Marvel Universe !!!
