Auth n Capture : Introduction to India’s Digital Payments Ecosystem 9781639975143

Citation preview

Notion Press Media Pvt Ltd No. 50, Chettiyar Agaram Main Road, Vanagaram, Chennai, Tamil Nadu – 600 095 First Published by Notion Press 2021 Copyright © Aditya Kulkarni 2021 All Rights Reserved. eISBN 978-1-63997-514-3 This book has been published with all efforts taken to make the material error-free after the consent of the author. However, the author and the publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause. While every effort has been made to avoid any mistake or omission, this publication is being sold on the condition and understanding that neither the author nor the publishers or printers would be liable in any manner to any person by reason of any mistake or omission in this publication or for any action taken or omitted to be taken or advice rendered or accepted on the basis of this work. For any defect in printing or binding the publishers will be liable only to replace the defective copy by another copy of this work then available.

Dedicated to, Wonderful women in my life – Mother, Wife, Daughter, and Sisters And My late father

Knowledge is knowing a tomato is a fruit. wisdom is not putting it in a fruit salad

Contents

Recommendations Acknowledgements Preface 1.

Jargons

2.

Shaping the Payments Ecosystem 2.A 2.B 2.C 2.D 2.E 2.F 2.G 2.H 2.I 2.J 2.K 2.L

3.

Payment Players 3.A 3.B

4.

Reserve Bank of India NPCI Card Schemes State and Central Governments Industry Specific Regulators Courts Banks Payment Instrument Issuers Payment Service Providers Platforms Black Swan Events Customers Payment Instrument Issuers Payment Service Providers

Payment Instruments 4.A 4.B 4.C 4.D

Credit Cards and Debit Cards Prepaid Cards and Wallets Net-Banking Buy Now Pay later

4.E 4.F 4.G 5.

Guidelines 5.A 5.B 5.C 5.D

6.

PA/PG Charges or MDR Commercial Models How Payment Aggregators Make money?

Payment Aggregator – Integration 8.A 8.B 8.C 8.D 8.E 8.F 8.G

9.

Risk and Underwriting MID and Live ID

Payment Aggregator – Commercials 7.A 7.B 7.C

8.

Payments and Settlement Act of 2007 PA/PG Guidelines Prepaid Payment Instrument (PPI) Guidelines Guidelines for Cards including SI on Cards

Payment Aggregator (PA) 6.A 6.B

7.

UPI Cash Crypto Currencies

Payment Pages Save Cards or Card Vault Transactions Transaction Routing Understanding Success rate How to improve Success Rate Integration Final notes

Payment Aggregator – Operations 9.A 9.B 9.C 9.D 9.E 9.F

Settlement Time Early Settlement Settlement Amount Settlement - Account Refunds Curious Case of Chargebacks

10. Recurring Payment Solutions 10.A

NACH

10.B eNACH (e-Mandate) 10.C Standing Instruction (SI) on Cards 10.D UPI AutoPay 11. Virtual Account Number and Virtual VPA 12. Pay-out or Disbursement Solutions 12.A 12.B

Pay-out cases Pay-out Solutions

13. International Payments 13.A 13.B

Outward & Inward Remittance International Payment Gateway

14. BBPS – Bharat Bill Payment System 15. Wrapper/TSP (Technical Service Provider) 16. Offline Payment Solutions 16.A 16.B 16.C

POS (Point of Sales) Soft POS (ePOS) UPI QR Code

17. Sectors – Industries 17.A 17.B 17.C 17.D 17.E 17.F 17.G 17.H

eCommerce Travel Gaming Utility, Telco/DTH Education Insurance NBFC Mutual Fund

18. BaaS (Banking as a Service) Final Chapter Reference

Recommendations

A must read not just for all the fintech enthusiast but also for the ones who are willing to explore opportunities in fintech. What’s best about this book is that it explains in a much-needed simplified way the nitty gritties of the emerging trends in Fintech. It takes altogether a different skill to explain complicated concepts in simple form because simplicity is not that simple, and Aditya has brilliantly done that in this book. – Gunjan Kaur Jabbal (VP & Business Head) (Open Financial Technologies Pvt. Ltd) A few years back when I started my journey in payments product management, it took a lot of time and energy to understand the basics and the nuances of the space as there was no ready reckoner available anywhere. Fast forward a few years and Aditya’s auth n capture blog series is my first (and at times only) reference to any aspiring or new PM in the payments space. It’s fascinating to know that a more comprehensive version is coming out in the form of a book. An absolute must read for anyone looking to untangle the intricacies of the payment ecosystem! – Roshan Prabhakar (Product Management @ PayU, Flipkart) Schemes, PPIs, Acquirers, Issuers were among many payments related concepts I struggled to learn in my early years of fintech career. I wish a Payment Bible like this was available back then. This book is highly

recommended for people who want to learn Payment fundamentals by first principles. – Ravindra Govindani (Product Management @Amazon, PayU and Snapdeal)

Acknowledgements

I may be the sole author of this book, but it is the culmination of the experiences and learnings of many people I have met in my personal and professional life. A few of them taught me payments, a few guided me to excel in sales while many helped me to be a better person. Thank you - Rahul Mahapatra, Michael Chozhaa, Ishan Sharma, Nijesh Prakash, Aravind Ashok and Shweta Mohan for your unconditional support and guidance. Friends and colleagues from the companies that I have worked for, as well as banks and merchants - Without you, this journey would have been morose and dull. I would like to thank Dhinesh Radhakrishna, Madhavi Sharma, Animesh Lahiri, Vincent Lucas, Raunak Chaudhary, Harsha Chandra, Ramkumar, Sanoop Sreedharan, and Shreya Sharma. I would like to thank the leadership of the companies that I worked for: Kumar Karpe, Milind Kamat, Ramanathan RV, Vimal Kumar, Sheetal Lalwani, and Akash Sinha. Writing is difficult and writing consistently is even more difficult. I wouldn’t have started the blog without the nudge and encouragement from my wife, Michael Chozhaa, Sagar Gubbi, and Amit Nayak. Thank you, you are the best! I convey my special thanks to everyone who visited, read and followed my blog. Without your encouragement, I wouldn’t have taken up the task of

writing a book. Thank you, Swati Suramya for proofreading and editing the content. Your invaluable experience helped me shape this book. Finally, but most importantly, we are incomplete without our families. Whatever little I have achieved in my life and career is all because of support and encouragement from my family. Loads of love! – Aditya Kulkarni

Preface

‘Life moves’… so do people and money… In my short career, I have worked in two types of companies - the one who move people and the one who move money. In the first half of my career (Pre-MBA), I worked as a software developer with Automotive Giants (Bosch and General Motors) in different geographies and developed software that are critical for life saving ECU (Electronic Control Unit) modules (Anti-lock Braking System, Airbags). In the second half (Post-MBA), I worked with companies that moved money between people and companies. Both the sectors I have worked in are dynamic. Things change every other day and every other day there is a new problem for which a new solution must be imagined. People want to move from Point A to Point B. So, the automotive industry needs to keep innovating to ensure people move faster, safer, and cheaper. Similarly, money needs move seamlessly between two parties hence the payments industry needs to keep innovating to make sure payments are done efficiently, securely and economically. As you can see, the world of online payments has become huge. Growing economy, smartphone penetration, and cheap data has boosted online payments. And we are all part of this ecosystem either as consumer, vendor, merchant or FinTech professional.

I would say, we are living at a time where spending money is much easier than it has ever been in human history, and I am glad that I am working in this domain. The Payments or FinTech domain looks like a ‘jungle’ with a never-ending list of payment methods with various entities moving money in intricate ways. So, I started writing a blog ‘www.medium.com/authncapture’ about the payments ecosystem. As more people read and liked it, the more I wrote about payments. And after ~3 years, and ~60 articles, I decided to write a book. I have read a lot of books ranging from philosophy to history. But I never came across a book on payments. Is writing a book a good idea then? Yes and No. Yes, as there are no books about payments. No, as the payments space keeps evolving, so a lot of content of the book will be outdated in a few years. Still, I decided to go ahead and write this book to try and cover the fundamentals since the fundamentals don’t change. In the next 18 Chapters, I have written extensively about payment players, payment instruments, payment gateways, recurring payments, guidelines, and forces that shaped this industry and, also some of my personal anecdotes and experiences. But why should anyone read it? That is a good question. And the answer is also clear. This book is not just for someone who is working in the Payments domain. In today’s world, we are all part of the Payments ecosystem as a customer, a merchant or as a

vendor. We buy things on eCommerce sites, we transfer funds to our friends and families, we might be running a business and wish to collect payments or we receive funds for services that we provide. It is not necessary to learn about the combustion engine while driving the car. But surely, you need to know where the brake is, or how to turn on the head light. Similarly, the book covers fundamentals without going into technical details, so you know about your payments. Sounds Good? Then let’s start the journey!

Chapter 1

Jargons

Although we are familiar with payments/FinTech (at least as a user), there are a lot of jargons associated with the sector. I will try to explain the jargons throughout the book. Here is a small set of jargons to start with: Word

Explanation

2FA or AFA

Two-factor authentication (2FA) or Additional Factor Authentication (AFA) provides unambiguous identification of users by means of a combination of two different components: What you have - Card (number, expiry date and CVV that is printed on card) What you know - PIN (either static or One Time Password, OTP)

3D Secure

3-D Secure is an XML-based protocol designed to be an additional security layer for online card transactions. It was originally developed by Arcot Systems, Inc. It is also known as Verified by Visa or MasterCard Secure Code or American Express SafeKey.

ACS

Access Control Server is 3D Secure protocol and there are entities that provide 3DS solution for the issuing bank. Basically, these entities send and validate the OTP for the issuing bank.

Issuing Bank

Bank that issues cards to consumers or corporates.

Acquiring Bank

Bank that processes card transactions of different card schemes.

Word

Explanation

Card Association

Card Scheme or Card network is payment networks linked to cards. By becoming a member of the scheme, the member can issue or acquire cards operating on the network of that card scheme.

API

Application Programming Interface is a set of functions and procedures that allow two systems to communicate and exchange data

Credit Cards

Cards that work on credit line of issuing bank (entity). Spend amount is limited to the credit line. Customer is obliged to repay the spent amount after free credit period.

Debit Cards

Cards that work through the automatic deduction of available funds in a bank account to make a purchase or withdraw cash.

Prepaid Cards

Cards work on preloaded amount and the spend is limited to available balance. Prepaid cards are issued by PPI licenced entities. Depending on acceptance, prepaid card can be closed, semi-closed and open loop. Forex cards are also prepaid cards that can be loaded with non-INR currencies.

Mobile Wallet

These are digital prepaid instruments with intangible form factor otherwise they have all attributes of a prepaid cards.

Authentication, Three steps of card transaction: (a) Authentication - Card is Authorization authenticated with OTP validation (b) Authorization - Transaction is and Capture authorized based on balance & risks (c) Capture - Transaction is captured, and the settlement process begins. BIN

Bank Identification Number is assigned by a card scheme to each of its member financial institutions, banks, and processors. Usually, first 6 digits of the card number (Visa is upgrading it to 8 digits)

Card number

String of digits printed on the front face of the card (these digits signify bank identification number, category, currency etc.). Visa, MasterCard, RuPay: 16 digits Amex: 15 digits

Card Details

Attributes of the card that includes card number, expiry date and CVV (1,2)

CVV

Card Verification Value (CVV) or CVC (Card Verification Code) or CSC (Card Security Code) is 3 (Visa, MasterCard, RuPay) or 4

Word

Explanation (Amex) digits on back of the card that is used for transaction. CVV1: Part of magnetic stripe or EMV CVV2: 3 or 4 digits on the reverse of the card

CNP

Card Not Present transaction is done remotely by the user (basically, online transaction). CNP transactions are risky, so additional layer of security (2nd Factor Authentication) is mandatory. MDR for CNP transactions is higher compared to CP transactions.

CP

During transaction the cardholder or card is present at point of sale (Card swipe done at a grocery store). MDR for CP transactions is lower compared to CNP transactions.

EMV

Euro Pay, MasterCard and Visa, is a microchip-based technology designed to reduce fraud at the point-of-sale.

NFC

Near Field Communication technology allows users to make secure transactions with a tap.

Card Vaulting

Process of storing the card details (number and Expiry Date) by PCIDSS certified entity.

Chargeback

A dispute raised by a credit cardholder with an issuing bank. A merchant can provide proofs to defend the chargeback or amount is reversed to the customer.

Escrow Account

A special purpose non-interest paying account used by intermediaries to move funds. Regulation for escrow account is bit relaxed compared to nodal account.

GTV or GMV

Gross Transaction Value or Gross Merchandise value is the value of transaction processed.

KYC

Know Your Customer, set documents establish a business entity or person’s credentials.

Merchant

The business entity that sells goods or services to customers or businesses.

MCC

Merchant Category Codes assigned by card scheme for a particular sector or business. (E.g., Airline, Hospital, retail, Education etc.). MDR varies based on MCC.

Word

Explanation

MDR

Merchant Discount Rate is fee charged by acquiring bank to merchant. Sometimes, same is called as TDR (Transaction Discount Rate).

MID

Merchant Identification Number is a unique number assigned to each member merchant by an acquiring bank or partner bank. MID is used for identifying the merchant throughout the payment cycle (transaction, settlement, refund, chargeback).

NACH

National Automated Clearing House is Recurring payment platform managed by NPCI. NACH has offline (paper based) and online variants.

NEFT

National Electronic Funds Transfer is interbank transfer service managed by RBI. NEFT works in 30 mins batches and recently upgraded to 24x7.

RTGS

Real Time Gross Settlement is interbank transfer service managed by RBI. RTGS works 24x7 and allows for transfers above Rs. 2,00,000.

IMPS

Immediate Payment Service is interbank transfer service managed by NPCI. IMPS works in real time and 24x7. Limited to INR 2,00,000 per transfer.

Nodal Account

Nodal accounts are non-interest-bearing special purpose accounts used by intermediaries to move funds. Nodal account comes with strict governance and has limit that funds should leave the account in 3 days.

NPCI

National Payments Corporation of India is founded in 2008, is a notfor-profit organisation owned by a consortium of banks and promoted by RBI (Reserve Bank of India).

P2P

Person to Person transfer of funds.

Payment Aggregator

An entity that combines various payment processors and service providers (acquiring bank, banks, wallets etc.) on a single platform and offer payment services to merchants. E.g., PayU, BillDesk, RazorPay

PG

Payment Gateway is a piece of software that processes the card transactions. E.g., CyberSource, ISG, MIGS, FSS. An acquiring bank uses PG for processing.

Word

Explanation

PCI

Payments Council of India is a non-Profit organization of payments companies (payment aggregators, wallets, and PSPs) in India.

PCI-DSS

Payment Card Industry Data Security Standard is a proprietary information security standard for managing cards (storing, processing etc.)

POS

Point of Sales is a machine used to process card present scenario (fixed POS at retail store or mobile POS device).

Refund

A request posted by the merchant (on behalf of customer) for returning the transaction amount to the customer’s source account or card. A refund can be the full or partial.

RBI

Reserve Bank of India is central bank of India that is responsible for managing monetary policies including digital payments

UPI

Unified Payments Interface is a mobile based digital payment product by NPCI to facilitate P2P (Person to Person) as well as P2M (Person to merchant) transactions.

Chapter 2

Shaping the Payments Ecosystem

Just like how our planet is constantly getting shaped by shifting of tectonic plates, even the payments space is getting shaped by various forces. On the surface (for those who are not actively watching it), things look normal, but those in the FinTech or Payments space know how fast things move here. The space is truly complex and dynamic. Entities and actors that shape our payments ecosystem: Reserve Bank of India (RBI)

NPCI (and NUEs)

Card Schemes

Other regulators (IRDA, SEBI)

Courts

Governments (Central & State)

Platforms (Android, iOS)

Banks

Payment Instrument Issuers

Payment Service Providers

Black Swan Events

Customers

In this chapter, we will cover some of the key entities and events that have shaped and continue to shape India’s payments ecosystem. This is not final at all; I would say that we are still in the early phase of the grand payments journey and interesting things will continue to happen. 2.A Reserve Bank of India

RBI (Reserve Bank of India) is India’s central bank (Do not confuse it with the Central Bank of India, a Public Sector Bank). Every one of us knows the RBI as it is printed on our currency notes. But the RBI does more than just printing currency notes. Preamble of RBI describes the basic function of RBI is “to regulate the issue of Bank notes and keeping of reserves with a view to securing monetary stability in India and generally to operate the currency and credit system of the country to its advantage; to have a modern monetary policy framework to meet the challenge of an increasingly complex economy, to maintain price stability while keeping in mind the objective of growth” That is quite a mouthful… isn’t it? Below are the primary responsibilities of RBI Monetary policy Regulation and supervision of the banking and non-banking financial institutions, including credit information companies. Regulation of money, forex, and government securities markets as also certain financial derivatives. Debt and cash management for Central and State Governments Management of foreign exchange reserves Foreign exchange management—current and capital account management Banker to banks - Banker to the Central and State Governments Currency management Developmental role Research and statistics Oversight of the payment and settlement systems

The last one is of our interest. RBI is responsible for regulating payments. And RBI does it in different ways. 1.

Setting the Vision

RBI has broad responsibility and vision “To ensure that all the payment and settlement systems operating in the country are safe, secure, sound, efficient, accessible and authorised”. To achieve the goal, RBI sets the vision (literally publishes vision documents) and follows through it by rolling out policies and guidelines to achieve that vision. RBI has published vision documents for the following time frames: 200103, 2005-08, 2009-12, 2012-15, 2018, 2019-21. Whatever we see today in the payments landscape is done as part of these vision documents or RBI’s vision. 2.

Guidelines

RBI issues guidelines and periodically updates these guidelines. Below are some of the important guidelines related to payments. Payments and Settlement Act PA/PG Guidelines Prepaid Payment Instruments (PPI) Inward and Outward remittance Card and SI on Cards guidelines Master KYC guideline We will talk about these guidelines in detail in Chapter 5 - Guidelines 3.

Regulatory Sandbox

One of the biggest challenges with respect to innovation in financial services is: Regulation & Compliance. But without innovation, we cannot solve the larger problems. So, RBI provides the sandbox, a controlled environment where regulators, financial service providers can build solutions for certain problems. Such sandboxes help all the stakeholders to identify the risks and thus come up with processes, frameworks and solutions that can be rolled out for larger audiences. So far, RBI has announced 3 themes for Sandboxes First cohort (Nov’19): Payments on feature phones, offline payment solutions and contactless payments (Result: 32 companies applied and 6 were selected). Second cohort (Nov’20): Cross-border payments (Selection process is in- progress). Third cohort: MSME (Micro Small Medium enterprise) lending (Yet to announce). 4.

Statistics and Reporting

RBI also publishes data on various modes of payments including bank accounts, ATMs, debit & credit card. 5.

Measurement

We all know that digital payments are growing big but, have you ever wondered: How big is it? Is the ‘big’, ‘really big’ enough? Are they growing big uniformly?

How will one measure the growth or reach of digital payments? To answer these questions RBI has come up with the Digital Payments Index (DPI) to measure the extent of digitisation of payments. The RBI-DPI comprises five parameters with different weightage and each parameter further has sub-parameters. (As shown below)

Mar’18 is the base year with DPI 100. DPI for Mar’19 and Mar’20 is 153.47 and 207.84 respectively. RBI is planning to publish this on a semiannual basis. 2.B NPCI NPCI (National Payments Corporation of India) is an umbrella organisation for retail payments in India. It was set up with the guidance and support of the Reserve Bank of India (RBI) and Indian Banks Association (IBA) NPCI has launched many payments products and each one has contributed towards the growth of digital payments.

IMPS (Immediate Payment System) is an interbank transfer platform that facilitates 24x7, real time transfer of amount up to Rs. 2,00,000 (Refer Chapter – 12) RuPay: India’s own card scheme (In a way, India’s response to Visa, MasterCard, and Union Pay of China). Predominantly used in debit cards with negligible number of credit cards and prepaid cards. UPI (Unified Payments Interface) is a mobile based payment instrument that is built on IMPS rails. By far the fastest growing payment instrument in India with use cases of P2P as well P2M payments. (Refer Chapter – 4.E) *99#: A USSD (Unstructured Supplementary Service Data) based banking service that was supposed to enable digital payments on feature phones. Due to friction and limited TSP (BSNL and MTNL), the solution didn’t see much growth. BBPS (Bharat Bill Payment System) is a billing platform to enable bill payments through 3rd parties Apps (PhonePe, G Pay) and Agents (Bangalore One, Suvidha) (Refer Chapter - 14). NACH (National Automated Clearing House) is a recurring payment platform where NPCI acts as clearing house. The solution has both paper-based (Refer Chapter - 16.A) as well as online (refer Chapter - 16.B) variants.

AePS (Aadhar enabled Payment System) is Aadhar based disbursement solution. Ideal for direct disbursement (Government) use cases. Bharat QR: A universal QR that allows payments from UPI and cards (Visa, MasterCard, RuPay). In this book, I will cover only a few of these important solutions in detail. NPCI has floated two subsidiaries: (a) NPCI International payments Limited (NIPL) to promote these payment products globally (b) NPCI Bharat BillPay Limited (NBBL) to promote BBPS in India. NPCI is an amazing organisation that all Indians should be proud of. It has truly altered the payment landscape of India but in this long journey, has NPCI become too big to fail or a single point of failure? Even the RBI thinks that way in one its policy-paper. NPCI manages ~60% of retail payments on its platforms (UPI, AePS, IMPS, BBPS, NACH etc.). So imagine the impact if NPCI goes down for couple of hours! To reduce the dependency or single point failure, RBI has recently called for the forming of NUE (New Umbrella Entities). An NUE is a consortium of various companies that are experienced in the payments space in various capacities. The selected NUE(s) are expected to build infrastructure, platforms, or products to cater to domestic payments (maybe even cross-border payments). Below is the summary of RBI guidelines for the NUEs NUE to be Incorporated in India under companies act 2013 and will operate as a ‘for profit’ company.

Follow PSS (Payment Settlement Systems) Act. Company with more than 25% share will be considered as promoter. Rs. 500 Cr paid up capital with upper cap of 40% for the promoter and NUE should maintain a net worth of Rs. 300 Cr. Should follow good corporate governance; RBI will approve the board of director and may nominate board member. Players

Below is the list of NUE groups (Looks like an IPL tournament among companies!).

Expectations from NUE

In simple words, an NUE will have to do better than NPCI’s products or platforms. Can they build another UPI like solution? Maybe not - but yes, there is a lot that can be done in areas of bank transfers, cross-border payments, recurring payments and even at ATMs. I am sure interesting things will unfold once NUEs start rolling out their products.

2.C Card Schemes Card schemes or card networks are the entities that facilitate card issuance, security (3DS), processing, settlement, and card acceptance. Card schemes earn different types of fees for facilitating these services: (a) BIN fees (b) Certification fees (c) Interchange fee, which is typically% of transaction value processed. Visa, MasterCard, RuPay, Maestro and Amex are the leading card schemes in India. ‘Diners’ doesn’t have a direct presence in India but is operated by HDFC. Other big card schemes such as JCB, Discover, Union Pay are yet to make a splash in Indian market. Other services of Visa and MasterCard are: Disbursement: Visa Direct and Master Money Send are disbursement solutions where funds can be moved from a/c to the cards or card to card. Checkout: mVisa and Master Pass are checkout services of these scheme (imagine them as card wallet for easier checkout experience). Network Tokenization: Card is tokenized by the card network to facilitate super secure and efficient payments. There are few ways the card schemes influence the payments ecosystems: Issuance capabilities (e.g., NFC capability), platform features (e.g., tokenization), Commercials (plays important role in setting interchange for different type of merchant categories) and merchant acceptance (Type of merchants that are allowed). 2.D State and Central Governments

Both State and Central Government are important stakeholders in boosting digital payments as well as shaping the industry with policy changes. One of the biggest of such policy changes was ‘demonetization’ on 8th Nov 2016. Government of India (GOI) nullified Rs. 1000 and Rs. 500 currency notes. People and businesses had no other option but to use digital payments until new currency notes were available. Although digital payments have increased manifold since then, so has the cash. In fact, there is more cash in the system than before the demonetization. Irrespective of that, demonization forced people to change their payments behaviour. GOI has also taken decisions related to certain sectors such as banning crypto currencies (2018) and e-cigarettes (2019). State Governments also have shaped the domain by either promoting FinTech companies or banning certain sectors (e.g.: Andhra, Telangana, Orissa, Sikkim and few more states have banned online gaming merchants). 2.E Industry Specific Regulators There are other regulators that govern specific sectors such as IRDA (Insurance Regulatory and Development Authority of India) for the insurance sector and SEBI (The Securities and Exchange Board of India) for the regulated investments sector. These entities also have guidelines that impact the payments related to these specific sectors. E.g.: As per SEBI guidelines, regulated investment can be done only (a) by the registered bank account of the user (b) no credit products or wallets to be used for investment. 2.F Courts

India’s independent judiciary system (High Court and Supreme Court) have issued judgements for certain sectors. E.g.: Lifting blanket ban on Crypto Currency trading (2020) or allowing skill-based games (e.g., Rummy and Fantasy Sports). 2.G Banks Banks are the most important stakeholders in the Payments Ecosystem. They are the ones who provide APIs for various services such as Payment Gateway, Recurring Payments and Payouts. Every bank operates with different levels of compliance processes. Although they adhere to generic guidelines of RBI, GOI and Card schemes, they also have some amount of flexibility to decide on what type of merchants they would like to work with or want their payment service providers to work with. E.g.: SBI doesn’t allow wallet loading, HDFC doesn’t allow skill-based gaming. Banks also got consolidated either on their own (e.g., ING Vysya merger with Kotak) or mandate from Central Government (e.g., Combining of all State Banks under State Bank of India). Whenever such consolidation happens, the integration needs to be upgraded and customers need to be transitioned. Considering such mergers are rolled over a period of 1-2 years, there is enough time for everyone to get adjusted. The biggest jolt to the payments ecosystem happened in Mar’20 when Yes Bank was put under moratorium. Yes Bank was one of the mid-sized issuing banks, but it was the leading bank when it came to API driven services such as UPI, Payment Gateway, SI on Cards, eNACH and Payout. When the bank was put under moratorium, it instantly affected many Payment Aggregators’ transactions and settlements that in turn affected thousands of

merchants and their customers. The impact of the same was highest on PhonePe as it was completely dependent on Yes Bank for its UPI transactions, so PhonePe was blacked-out for a couple of days till they rolled out an alternative solution with ICICI Bank. Bank and payment players share unique relationships - They compete as well as work with each other. 2.H Payment Instrument Issuers Apart from banks, there are other entities that issue payment instruments such as wallets (e.g., PayTM), pay later products (e.g., Simpl), and cardless EMI products (e.g., Zestmoney) etc. Such products cannibalize the share of traditional payment instruments such as net-banking or credit cards but also increase the pie (convert cash orders to online). These companies are not immune to changing customer behaviour, regulatory frameworks, and intense competition. Example: Prepaid card issuers and many of the mobile wallets closed over a period due to intense competition from UPI and mandatory KYC guideline policies. But that doesn’t mean the new payment instruments won’t arrive at the ‘great Indian Payments Party’ - Expect more credit, BNPL, EMI products in the coming days who will keep adding diversity to our existing payments landscape. 2.I

Payment Service Providers

Payments is a super competitive space with multiple players, with a high possibility of commoditization of services. So, companies keep innovating or go aggressive on commercials and start price wars. Also, the industry is not new to mergers and acquisitions.

Naspers PayU acquired not only its competition Citrus but also few other companies in the Payments ecosystem: Wibmo (ACS solution), PaySense (Lending), Fisdom (WealthTech). Ingenico initially acquired EBS (e-Billing Systems) and then acquired TechProcess Payment Services Ltd. And then Worldline acquired Ingenico. Innovations, acquisitions, and price wars make this space interesting, dynamic, and messy. 2.J

Platforms

As mobiles have become an important channel of payments, mobile platforms such as Android (google) and iOS (Apple) have got bigger power in the overall ecosystem. In 2018, Google banned auto-reading of OTPs unless the companies followed a prescribed format. This had a significant impact on FinTechs, merchants who had SDKs to auto-read OTP. Eventually, Google relaxed the rule to read bank OTPs (only after whitelisting of Apps) but for other use cases, the Apps had to implement Google’s policies. Google and Apple charge 30% fees for digital goods. To avoid it, the gaming merchants do not distribute their Apps through Play Store or App Store. To reduce the dependency on these platforms, a few Indian companies are working on their app distribution platforms. 2.K Black Swan Events These are unprecedented events that no one could have anticipated, and no one would have factored in their business models.

One such event was demonetization on 8th November 2016. It was a positive boon to payments companies especially for the PayTM wallet. Remember, UPI was still not mature at that time. But all and all, demonetization boosted digital payments in India. The second such event was the Covid-19 pandemic. The entire world changed within weeks in March’2020 and we are still living in that pandemic. The pandemic also boosted digital payments as our shopping and education moved ‘online’. As people locked themselves in their houses, the online gaming sector boomed, and ‘bored’ people binged on OTTs (Netflix, HotStar & a hundred others). Pandemic affected few sectors positively such as OTT, Gaming, eCommerce, eGrocery, EdTech while few sectors came to grinding halt such as Travel & Hospitality. Only time will tell the long-term impact of this pandemic on our lives and businesses. 2.L Customers Yes, you are the most important stakeholder in this ecosystem. What if you decide not to pay online? What if you prefer cash over UPI? India has come a long way in digital payments because of users. As users, we started trusting these online payments, we started trusting online businesses. All these regulations, innovations and price wars are for us. To provide us a secure, reliable, and economical way to transfer funds to our family or friends, buy products online, book flight tickets or pay our bills. The Road Ahead

We are still at the beginning of the payments journey. As many more business models evolve, many payment players and their products will shape these sectors. We are in the most interesting times of the Great Indian Payments Journey.

Chapter 3

Payment Players

Let’s start with the fundamental meaning of ‘Payments’. At one end there is a merchant, who wishes to collect money from its customers and on the other end there are customers who want to pay. And in simple terms ‘online payment’ is all about moving money from customer(s) to merchants. Not just that, this movement of money has to be done securely, efficiently and economically! There are companies who are in the business of this money movement, and they make money to perform these activities. To make a payment, a customer needs a ‘Payment Instrument’ that is issued by ‘Payment Instrument Issuer’ and to process (or accept) those instruments, merchants would need ‘Payment Processors’. 3.A Payment Instrument Issuers As the name suggests, these are the entities that issue payment instruments that a user or a company can use to make the payments. Here are a few of the payment instruments: Cards (Credit Card, Debit card, prepaid card) Bank account UPI Wallet

Alternate credit product (cardless EMI and pay later products) Cheque and Demand Drafts Cash (Yes, it is also payment instrument) Crypto Currencies Payment instruments can be tangible (e.g., cards) or intangible (e.g., UPI or wallet) that can be used to make payments. The source of funds for the instrument can be bank account balance, pre-loaded amount, or credit line. Read more about payment instruments in Chapter 4. 3.B Payment Service Providers To make a payment, the customer should have at least one of the Payment Instruments and the merchant should have the means to accept or process those instruments. The acceptance mechanism is provided by Payment Service Providers. In the Payments world, we use the word ‘integration’ i.e., basically a set of APIs that are established among ‘merchant Payment Service provider Payment Instrument Issuer’ to facilitate the fund movement related activities such as transactions, settlements, refunds, and dispute management. There are various types of Payment Service Providers depending on their integration with merchant: 1.

Payment Instrument Issuer = Payment Service Provider

A payment instrument issuer can ONLY process that instrument. Merchant needs to have direct integration with these entities. Example: Wallets, Net-banking, alternate credit products (pay later product), Amex cards.

To process a particular wallet (E.g., PayTM), the merchant will have to do direct integration with wallet issuer (i.e., PayTM). Similarly, only Amex can process Amex cards. 2.

Acquiring Banks

These entities process certain types of payment instruments. These are intermediaries who connect merchants with issuing entities. Example: Acquiring Banks (that use PG - Payment Gateway) process certain types of credit & debit cards, or Acquirer Bank can process UPI transactions.

To process Visa and MasterCard credit & debit cards, merchants would need to integrate with HDFC acquiring banks that in turn will use PG (Payment Gateways) such as FSS, ISG, MIGS or CyberSource for processing. 3.

Payment Aggregators

There are few disadvantages in the above two methods. If merchant wants to increase payment coverage (support multiple payment instruments), here are the problems: The merchant has to do multiple integrations that means deploying more resources. The merchant’s operation effort increases due to multiple settlement files from each entity. To address these issues, Payment Aggregators were born. As the name suggests, they aggregate multiple payment processing entities (acquiring banks, net-banking, wallets, and credit products) on a single platform and offer bundled solutions to merchants that increase payment coverage and reduce integration effort while doing single settlement for all types of transactions.

Examples: BillDesk, PayU, Ingenico ePayments, CC Avenue, RazorPay (30 more such big & small companies) Note: People refer Payment Aggregators as Payment Gateway, but they are not same. No harm in referring but keep in mind that PG is card processing software and payment aggregator is platform that bundle multiple processing entities. 4.

Payment Containers

These can be considered as ‘lite-payment aggregators’; they also partner with acquiring banks, aggregators, acquiring PSP and wallets on a single platform. A container can enable user to create UPI ID, vault cards and have wallet. And use these payment instruments to do P2P (person to person) or P2M (person to business) transactions. (Subject to capabilities) The primary difference between an Aggregator and Payment Container is that the user has to create an account with the Payment Container and login to that account every time before accessing the payment instrument to make the payment.

A merchant can integrate directly with the Payment Container or through Payment Aggregator. Example: PayPal, AmazonPay, PhonePe 5.

TSP (Technical Service Provider)/Wrapper

These entities provide a platform for merchants to integrate with multiple Payment Aggregators, Payment Containers, Wallets, and other types of payment processors along with additional features such as unified ‘card vault’, unified dashboard, routing engines etc. These TSPs bring technical advantages that ease integration and routing activities but stay away from settlements. Example: Juspay, DreamPay, RazorPay’s Optimiser Merchants can have integration with any of the above Payment Service Providers or a combination of Service Providers to process payment instruments. Example: A wallet can be integrated directly or through a Payment Aggregator. Cards can be processed by direct integration with the Acquiring Bank or by Payment Aggregator who uses the Acquiring bank. All this may sound a bit confusing and complicated, but it is not. I would say the payments ecosystem can be likened to Matryoshka Dolls (Russian Nesting Dolls), one payments entity within another one but operating with the aim of moving money from point A to point B.

Chapter 4

Payment Instruments

Payment Instruments are the means that are available with customers to make payment. These instruments are issued by various banking and nonbanking (FinTech) entities. Some of the instruments: Cards: Credit, Debit and Prepaid Wallets Banking account UPI Alternate credit products (e.g., By now Pay later, Cardless EMI) Cash (Yes, still an important payment instrument) Cheque & Demand Draft (Yes, they still exist but I am not going to talk about these!) These Payment instruments are linked to a source and that source can be funds in your bank account, pre-loaded funds, or credit line. (Shown below)

1.

Bank Account based: Customer’s spend is limited to available balance in the bank account.

2.

Prepaid based: The amount to be loaded to the instrument and then user can spend within the available balance. The balance amount on the instrument doesn’t earns interest.

3.

Credit Line based: Customers will have a credit line and can spend within that credit limit. And customers are obliged to pay back the credit amount that he/she has availed. Any delay in repayment will attract interest fees.

4.A Credit Cards and Debit Cards There are three main types of cards: Credit Cards, Debit Cards and Prepaid cards. In this chapter, I will talk about only credit and debit cards. a.

Credit Cards

These are issued by scheduled banks, selected non-banks (Amex) or NBFCs (SBI Cards and BOB Cards) along with card networks (Visa, MasterCard, RuPay, Amex). Qualified customers receive credit line (or credit limit) based on issuing entities’ criteria and the credit limit can be used for purchases at

merchant terminals (both offline and online) and for cash withdrawals at ATMs. Here are a few features of credit cards: Credit limit: Customers get credit limit which depends on their profile (salary, profession, company, spending, repayment discipline and credit score). Spending Rules: There can be limit on spend across various channels (in store, online and cash withdrawal). Also, cards can have restrictions on international payments. Credit Period: Customer is obliged to repay the spent amount on or before the due date (billing is done once a month). Delayed repayment or non-payment attracts charges (interest on credit) and affects the customer’s credit score. Variants of Credit Cards: There are two main type of credit cards: Consumer Credit cards (issued to customers) and Corporate Credit Card (issued to companies). Also, there are co-branded credit cards that are issued by a bank for a particular partner company (e.g., Amazon-ICICI card, Citi - Indian Oil card). b.

Debit Cards

These cards are issued by banks along with the card network and the card is linked to the customer’s bank account. Customer’s spending (purchases and cash withdrawals) is limited to the balance in the account. Even debit cards have a few rules with respect to the limit on daily cash withdrawal or spends on online purchase or usage territory. Know your card: Here is how a standard card looks like.

Some of the standard features of the card are: 1.

Card: Card can be virtual or physical. Physical cards can be of plastic, metal, or wood.

2.

Card Name: Usually specify some sort of branding (Regalia, Super Saver etc.)

3.

Issuing Bank: Bank that has issued the card (e.g., ICICI, HDFC).

4.

Card network: These entities that define the issuance and acceptance framework (E.g., Visa). The network plays a three-part role: Gives the BIN to the issuer. Sets up frameworks for acceptance of the cards across channels. Defines and enforces dispute management and arbitration guidelines.

5.

Card Number: This is the unique number of the card. Length of card number can vary from 13 to 19 digits depending on the card scheme. Example: Visa Credit card that I have has 16 digits, but Amex has 15 digits.

First digit is MII (Major Industry Identifier). Amex: 3, Visa: 4, MasterCard:5 1–6 digits are BIN (Bank Identification Number) or IIN (Issuer Identifier Number) and these numbers identify the issuing bank. Card schemes are preparing to issue 8 digit BINs this will require changes at issuer, acquirer, merchant and processor’s end. 7th to the last but 1 digit are unique card account number Last digit is the checksum digit that validates the correctness of the card number. It is done by the Luhn’s algorithm or Mod10 algorithm 6.

Expiry date: Validity period of the card for usage, and beyond that period the plastic card will turn into ONLY PLASTIC.

7.

Cardholder name: Name of the cardholder printed on the card. Sometimes there won’t be any name (E.g., Debit card that is part of welcome kit when you open new bank account).

8.

EMV Chip: EMV (Euro Pay, MasterCard, Visa) is a global standard to provide better security through chip-based transactions. Card is inserted in POS to process the transaction.

9.

Magnetic Stripe: The stripe behind the card that has encoded card details and can be swiped at a POS machine to process the transaction.

10. CVV2/CVC2: Card Verification Code (CVC) or Card Verification Value (CVV) is 3 digits (Visa or MasterCard) or 4 digits (Amex) on the back of the card which is used as additional information during the online transaction. Note: CVV1/CVC1 is encoded on EMV Chip and magnetic stripe and validated during POS transactions.

11. Signature Panel: The cardholder can sign on this panel. Earlier days when 2FA (PIN prompt) was not mandatory the signature had value as the cashier could cross-check the signature on the reverse of the card with signature on receipt. But it has no value now. Entities that play a crucial role in card processing:

a.

Card management system: A platform that manages the lifecycle of the card, risk, and rules. Lifecycle management: issuance, activation, hot listing, blocking and reissuance of cards. Risk Management: Velocity Checks and risk checks. Usage Rules: Spend controls, spend channel control and geographic control.

b.

Card Switch: Piece of software that connects the issuing bank (CMS) to the card network.

c.

Authentication or validation system: Mechanisms deployed to validate the transaction. In case of POS transaction, it will be PIN and in case of online transaction OTP/password. ACS companies provide this authentication service for online transactions.

d.

Acquiring Bank: Banks that use Payment Gateway to process the card transaction when the customer uses the card on the merchant terminal (Physical and online).

Along with 30-45 days credit period, EMI conversation of large ticket purchase, revolving credit (move the due amount to next cycle) and reward programs continue to fuel growth in credit card numbers (count and volume). Although UPI has cannibalised share of cards and BNPL (Buy Now Pay later) products are posing new threat, I believe cards will continue

thrive due to their form factor, acceptance, and other goodies they bring to the table. 4.B Prepaid Cards and Wallets In this chapter, we will talk about prepaid cards and mobile wallets as both share many common traits irrespective of their form factors, such as, Issued under PPI (Prepaid Payment Instruments) License of RBI. Spend is limited to the load or balance available on the instrument. Available balance doesn’t earn interest as funds are parked in a nodal account. Can be issued after completion of KYC (Minimum KYC: allows balance up to Rs. 10,000 and Full KYC allows balance up to Rs. 2,00,000). There are few deviations: Acceptance channels may vary for prepaid cards and wallets (e.g.: wallet can’t be used on a POS machine, but card can be swiped.) Cards come with Expiry Date, but wallets don’t (technically). Types and Variants:

There are two main types of prepaid instruments: Non-reloadable: Instruments can be loaded ONLY ONCE but can be used multiple times before the expiry date till the balance amount is exhausted (E.g., Gift Cards). Reloadable: Instruments can be loaded multiple times and can be used multiple times till the instrument is within its validity period (E.g., PayTM wallet, Meal card, Forex card).

Then there are different variants depending on their acceptance network. Closed loop: Acceptance is limited to single merchant or group of merchants. Semi-Closed: Accepted by a large network of merchants (but not all). Open loop: Accepted by a wider network of merchants.

Few other rules for prepaid payment instruments:

a.

Limit on the amount that can be loaded Gift Cards: One time loading Reloadable Instruments: Minimum KYC - Rs. 10,000 and Full KYC - Rs. 2,00,000. Forex Cards: $2,50,000 per year (with one-time max amount of $10,000).

b.

Currency that can be loaded Domestic — INR only Forex — Other currencies

c.

Restriction on cash withdrawal through ATM or transfer to bank a/c Gift Cards are not allowed for cash withdrawal as well as transfer to bank a/c. Reloadable cards and Forex cards can be allowed for ATM withdrawal. Balance amount can be transferred back to bank a/c.

d.

Restriction on acceptance based on MCC (merchant category code): card is accepted only with type of merchants (e.g., Sodexo card at Grocery merchants). MID (Merchant Id)/TID (Terminal Id): Health card that works at partner hospitals. Territory: Forex card issued by Indian banks is not accepted in India, Nepal, and Bhutan).

A decade ago, people believed in great potential of prepaid cards. Think about it, a payment instrument that doesn’t require bank account or credit history but can be used for purchases and cash withdrawals. Such instrument can be used for many use cases such as financial inclusion (Direct Benefit Disbursement), money transfer, add-on card for kids etc. But the prepaid card business model had its own issues, such as: KYC process Card procurement and shipment cost Banks faced challenge in positioning prepaid cards against their own debit or credit cards. Before the industry figured out the solution for these problems, ‘mobile wallets’ came and stole the thunder.

On the other hand, wallets showed immense promise. After the initial wave of mobile wallets (PayTM, Mobikwik, Freecharge etc.), Telecom companies also launched their wallets (Vodafone M-Pesa, Airtel Money, Idea Money, Tata mRupee, Jio Money etc.). However, today, PayTM is the market leader, Mobikwik is struggling, Freecharge changed a couple of owners (First Snapdeal and now Axis Bank) and is trying to morph into a financial services company, and Ola Money became Ola Money post-paid (wallet + credit product). The fate of carrier wallets was no different. A few died (Idea money, Tata mRupee), and the very few that survived because of the sole reason that their patrons have deeper pockets (Airtel, Jio). My heart weeps silently for Vodafone M-Pesa, the company that built an amazing financial inclusion story in Kenya, sadly had to shut down its operations in India. Irrespective of the business model, the biggest blow to these wallets came from the RBI when the regulator made the KYC mandatory. The logic is irrefutable: when prepaid cards follow KYC norms then why not mobile wallets? On the one hand, with mandatory KYC and on the other side the rising popularity of UPI, the wallet story started crumbling. Future of Prepaid Instruments

Merchants continue to have their closed loop wallets as an easy way for pushing refunds, a tactic for increasing customer stickiness. But with instant refund solutions, these wallets also may lose their charm. Only a few types of prepaid cards have some value: Gift Cards (because these are a lazy person’s gifting choice), Forex cards (Quintessential for overseas trips) and Specialised cards (Sodexo).

But this status is changing with the growth of a particular sector – NBFC/LendingTech. As NBFC/LendingTech companies cannot issue credit cards so prepaid cards are used as instruments to lend the money (by doing just in time funding to the prepaid card). In Apr’21, RBI have issued new guidelines for prepaid cards/wallets: Balance limit is increased to Rs. 2,00,000 Interoperability among PPI instruments Cash withdrawal at ATM and POS PPI entities can set-up operations for NEFT/RTGS transfers With these new guidelines and boom in neo-banks & LendingTech companies, prepaid cards and wallets may get another shot at not just revival but a remarkable growth. Let’s wait and watch! 4.C Net-Banking Net-banking is unique to India’s payments ecosystem. Due to low penetration of cards, net-banking was quite popular during the dawn of online payments. Apart from online payments, a net-banking account can be used for transfers to other bank accounts (RTGS, NEFT and IMPS transfers), and bill payment of credit card and other utility bills. In this chapter, we will focus on online payments using net-banking. Net-banking is a payment instrument where customers can transact using a bank account that is enabled for online payments. User’s spending is limited to balance in the account (unlike wallet, the balance in this account earns interest). During the transaction, the user is redirected to bank’s website to complete the validation (customer id, password/IPIN).

As step-up validation, some banks may pose additional authentication steps such as OTP, security question or grid challenge. Types of bank accounts

There are two types of accounts viz. retail and corporate: Retail accounts (belong to individual users): Retail transactions go through a standard validation process. Corporate Accounts (belong to business which can have more than one user): Corporate net-banking transaction may have makerchecker process of validation (Maker will initiate the transaction and checker will approve the transaction) Integration

Net-banking is one of the biggest value propositions that Payment Aggregators bring to the table. 45+ banks allow online transactions, so it is not practical for merchants to do 45+ separate integrations and moreover many of these banks do not even have capability, bandwidth, or interest to do direct integration with merchants. So, Payment Aggregators bundle all these banks together and offer them to merchants on a single platform. Some Payment Aggregators have direct integration with a few large banks (HDFC, SBI, ICICI, Yes Bank, Kotak, Axis) and for other banks they use another payment aggregator’s platform. (Didn’t I tell you…. payments ecosystem is like Russian Nesting Dolls… One payment player inside another, and so on!) Road Ahead

Net-banking ‘was’ an important payment method because of (a) lower credit card penetration (b) fear of using cards online. Over a period, net-banking users started moving to debit cards (as every bank account has a debit card) but the rise of UPI drastically affected netbanking transactions. Erosion of net-banking can be attributed to both merchants and customers alike: Customer: Multiple hops to complete the transaction, nonoptimised mobile pages and remembering password (not a userfriendly flow). Merchant: Success rate is inconsistent and lower; commercials are higher (than debit cards) for majority of sectors. Few years ago, net-banking options were prominently displayed on merchant’s checkout pages. But nowadays net-banking options are at the bottom of the page or hidden as the merchants still wants to have it but don’t want users to pay using those. Exceptions

Net-banking is still a dominant payment method in investment, NBFC and Education sectors. Below are some of the reasons: Commercials: Flat pricing for above mentioned sectors. So, whether the merchant bears the charges or passes to the customer, it is economical. Features: Net-banking provides TPV (Third party Validation) feature which is important for regulated investment sector (Mutual Fund or Stock brokerage).

Amount: UPI has a limit (Rs. 1 Lakh per day) so for higher ticket payments (e.g., School fee payment or investment), Net-banking is suitable. Although UPI has evolved over a period (e.g., TPV feature) and has lowest possible commercials (‘zero’ since 1st Jan 2020), net-banking has some breathing space to survive for a few years. Closing Remarks

There is not much upside for banks to re-innovate ‘the net-banking’. Also, as the Govt. of India is merging PSU banks, in the future there will be fewer banks than there were we years ago. The bigger question is, “will payment aggregators lose their importance if net-banking ceases to exist one day?”. 4.D Buy Now Pay later In this section, I will be covering unique kinds of lending products called Buy Now Pay Later (BNPL) products. The idea behind these products is to give ‘small credit’ to users for a particular period (couple of weeks). Users can make purchases in a partner merchant network using the available credit and then repay the utilized amount. A few of the big names are Ola Money Post-paid, Simpl, ePaylater, LazyPay (of PayU). Also, few banks have their own BNPL products. What are they up to?

People typically want credit to cover or fulfil (a) Big expenses (maybe to buy a bike) (b) aspiration (I want that iPhone now!)

(c) Emergency. But are these pay later products meeting these credit requirements? No, they are not. BNPL companies give small credit lines to users so what exactly are they up to? Their play is different, here is what they are trying to do Most of our spends are on small tickets e.g., Food order, medicine, utility bill, or bus ticket booking. So, BNPL companies are targeting these use cases (or merchants who are in those businesses) and trying to replace credit cards and/or other payment instruments. BNPL looks like great instrument because a.

Reach: There are only 2.8 million credit cards so what about people who do not have credit cards. So, let’s give them card-less credit.

b.

Ease of payment: Card or net-banking transactions go through 2FA or multiple hops, but these payment instruments have simpler user flow.

Participants:

1.

Users: People who avail credit line from the BNPL company (issuer)

2.

Issuers: Entities (FinTechs, banks, NBFCs) that issue the BNPL credit line to users. These entities are responsible for user on-boarding (KYC validation, approval of credit line), building acceptance (where users can pay using BNPL), providing customer support and collection of repayments. Note: A merchant also can build its own BNPL product that will work only on the merchant’s site (e.g., Flipkart Pay later) or merchant’s partner network.

3.

Merchants: Merchants (online or offline) where the user can make transaction using BNPL instrument

Do stakeholders see value in BNPL?

How credit is given:

One simple way is to check the credit score, but millions of potential users are not part of credit score systems or new to credit (NTC). On what basis do you give credit? So, build your own logic to give Credit Score to users. This alternative credit scoring can be based on education background, job history, mobile bill, utility bill or social media presence, and so on and so forth. After that, put a mix of AI/ML to make sure the ‘right amount of credit line’ is given to ‘right person’. Typically, issuing entities start with a small credit line and eventually increase it. Example: At first, I had a Rs. 1000 credit line from Ola Money Post-paid and now it is Rs. 10,000 (I used it often and repaid the due amount on

time. I am a good user!) Working of Pay Later products:

A. User on-boarding: Users need to register with pay later entities and receive a credit line and then he/she can use the credit line to purchase products or services from the merchant network. B.

Acceptance: A pay later instrument can be processed by the same pay later company (‘payment issuer = payment processor’ model). There are two main ways they can integrate with merchants: Direct: Integrate with merchants directly (via TSP as well.) Payment Aggregator: Integrate with Payment Aggregator(s) and the payment aggregator will offer it to its merchants.

Note: BNPL can be built on UPI which will remove the limitation of acceptance as UPI is almost universally accepted. A user will get a unique Virtual UPI ID and it can be used for online payments and even can ‘Scan & Pay’ on UPI QR Code at stores. Standard Flow:

First time flow: Merchant calls eligibility check API (Check whether customer is valid and what is the available credit). Then the user needs to complete the authentication leg to complete the transaction. Subsequent flow: Eligibility check is done and then customer just approves the transaction (no authentication required as token is stored after first transaction).

UPI Flow: If the BNPL is built on UPI then the assigned UPI handle can be used to initiate payment on a merchant site (Collect flow or intent flow) or Scan & Pay (UPI QR Code based) C. Repayment Typically, the credit period is 15 days. Post that, the user has to repay the consumed amount. Repayment is either active or passive. Active: User will have to go to the issuer entity’s website/app and pay the outstanding amount through CC, DC, NB or UPI (standard PG). Users can also pay back using Virtual account or Virtual UPI ID Passive: User can set one time mandate (on card or account) and the user’s registered instrument will be debited periodically. What if the user doesn’t repay?

Nothing will happen – BNPL issuers will block the user or may block the user on its partner network. But beyond that it won’t affect user’s credit score. (Only carrot and no stick) Who is paying ‘Pay Later’ companies?

To give credit to customers, ‘pay later’ companies need money or a credit line. There are three ways Pay Later Companies get the money. Own money: If you have enough money then deploy it. Technically, they cannot do it. Equity: Raise money from VC or PE and deploy it. Cost of equity is super high, so it doesn’t make sense. Debt: Get credit-line from NBFCs or Banks and deploy it. Debt is cheaper than equity but comes with an obligation of repayment. (Most popular)

Revenue Models:

These companies do not charge interest to customers, but late repayment or non-repayment of due amount will attract penalty fees. Merchant is charged MDR as merchants understands MDR model and used to it. MDR and/or Penalty fees are cleverly arrived after factoring cost of funds, risk costs, and write-off to be done for Non-performing Assets (NPAsusers who do not pay back). Here is the detailed working of the revenue model:

Revenue Lines MDR from merchant Late repayment fees from the user

Cost Items Cost of funds or Interest costs Charges borne during repayment NPAs (non-performing assets) Infrastructure cost Customer acquisition cost

In summary, to be profitable, the issuing entity should get the lowest interest rate from NBFCs, reduce repayment charges, control customer acquisition cost, and charge higher MDR to merchants but most importantly, reduce NPAs. ( Just stating the obvious). There are two ways to reduce NPAs: Proactive: Give credit to creditworthy users and have mechanism to pull the money for repayment of due amount (mandates) Reactive: ‘have a stick’, i.e., block the user from using other services, degrade credit score (if have access) The Future:

Credit is one of the most important financial tools that drives growth. In today’s FinTech landscape, it looks like everyone is eager to ‘give money’. So far things are looking bright for BNPL products. Today we have different entities operating the BNPL program: FinTechs (LazyPay, Ola Financials, Simpl, PayTM post-paid), Banks (HDFC), Neo-banks (Bullet by Jupiter) and merchants (Flipkart, Amazon). Even foreign companies started their operations here (e.g., Sezzle). FinTech pundits are betting that BNPL is the next biggest thing in the ‘payments world’. They may be right or may be wrong (just like any other prediction ever done). But it’s too early to say how things will shape up in the coming days. For now, BNPL loosely work on ‘take the carrot and I don’t have stick’ model. If NPAs increase, then companies will have to close down. So, I would say “credit is fun, until it stops being”! 4.E UPI

Today, we do various types of transactions: P2P (C2C), P2M (C2B), B2C (P2M), B2B, G2C and C2G (P=Person, C=Consumer, M=Merchant, B=Business, G=Government). This calls for the efficient way of transferring funds. It started with cash, cheque, and demand drafts, and then we moved online with RBI’s NEFT and RTGS. Then came NPCI’s IMPS which works in real time and 24x7 but still has limitations in terms of adding beneficiary details (Imagine asking for account number and IFSC Code!). Then came the most disruptive payment mode — UPI (Unified Payments Interface) with the simple idea of making the solution easier, mobile friendly, user friendly and real time. To explain this, let me start with its basic jargons and entities: VPA (Virtual Payment Address) or UPI ID: Looks similar to an email ID (9192939495@upi or tony.stark@okhdfc). A retail consumer would need a bank account and valid debit card to create a VPA. Issuer PSP: Bank/PSP that creates the VPA. Acquirer PSP: Bank/PSP that processes VPA transactions. Issuer and acquirer talk to each other via switch (UPI Switch which is managed by NPCI). Payee: Person/entity which is receiving the money in ‘beneficiary bank’. Payer: Person/entity who is paying the money from ‘remitter bank’. This is familiar… Doesn’t it feel like a card transaction? A unique card issued by the issuing bank and transactions processed by the acquiring bank via card scheme. But UPI comes with some twists, some

smoothness, and a whole lot of awesomeness! Virtual Payment Address (VPA) or UPI ID

VPAs are interesting not just because they look like email ids but because of unique attributes: One VPA can be linked to multiple banks (but one bank will be primary) A bank account can be added or deleted Multiple VPAs can be created on a single bank account

Security Device & PIN

Didn’t I say that UPI is mobile friendly? That is great but it’s not sufficient unless it is ‘super’ secure. Security is achieved by device binding and SIM binding combined with PIN or fingerprint to open the UPI App and another PIN (Personal Identification Number) to validate the transaction. In summary, UPI follows 2nd Factor Authentication (2FA) as prescribed by RBI. UPI Apps

Two types of entities can develop UPI Apps Bank (ICICI, HDFC etc.) FinTech Companies/merchants (PhonePe, G Pay, AmazonPay etc.) — As only a bank can create VPA or connect with an NPCI switch. So, these companies tie up with bank(s) (e.g., PhonePe — Yes Bank and ICICI Bank, Google Pay — HDFC, ICICI, Axis & SBI) Payment Flows

Ishan and Nijesh went out for dinner at Nando’s. Nijesh owes Rs. 750 to Ishan. Both have UPI Apps, so either Nijesh can transfer funds to Ishan or Ishan can ask Nijesh to transfer the money via a UPI App. Here is how the transaction is done. Let’s also throw in some complexities for better understanding: There are two types of payments Pull Payment: Payee (Ishan) sends collect request to Payer (Nijesh) Push Payment: Payer (Nijesh) initiates the transfer to Payee (Ishan) Also, the flow varies depending on the number of entities involved. Here are few combinations: Two Party Model, Three Party Model and Four Party Model: a.

Two party model:

b.

Three Party model:

c.

Four Party model: Let’s proceed with the Four Party Model (Payer PSP, remitter bank, Payee PSP and beneficiary bank are different entities) and see how ‘Pull’ and ‘Push’ payment models work.

Merchant Transactions

If a merchant wishes to collect funds via UPI, then the merchant would require a VPA. Current or nodal accounts do not have debit cards — so how will a merchant create a VPA? In this case, the acquiring bank will create a VPA for the merchant. Merchants can enable UPI by integrating with either an acquiring bank or a payment aggregator, who in turn, uses acquiring bank(s) or directly integrate

with a UPI App (e.g., PhonePe) Refer Chapter 8.C (Transactions) to read more about the collect and intent flow on UPI. Success Rate of UPI Transactions

As you may have noticed, there are many entities and actors involved in completing one transaction. At each step, every entity and actor are a potential point of failure. There are a few things that can be done to improve the performance and success rate. Refer to Chapter 8.F. Additional Features/Products A.

QR Code

QR codes are an innovative way of making payments and incorporated beautifully in the UPI ecosystem. A QR code is nothing but payee’s (receiver’s) VPA in QR format. There are two types of QR Codes: Static (where the amount needs to be entered by the payer). Dynamic (where the amount is already embedded in the QR). Both are efficient solutions for different types of use cases. Static QR fits better in case of brick-and-mortar stores (stick the QR near the checkout counter) and dynamic QR can be utilized perfectly in converting Cash on Delivery (COD) cases to online payments (embed the QR code generator in delivery person’s App so he can generate a QR at the customer’s door or stick dynamic QR on delivery package so user can Scan & Pay). B. Virtual VPA

Let’s say there is a B2B merchant who caters to 10000+ retail companies and the merchant wants to implement a UPI solution where retailers can make payments to the merchant. A custom or virtual VPA based solution is a good approach as the merchant can create unique customised VPAs for each of the retailers making it easier to reconcile and to facilitate settlements. Read the details in Chapter 11. C.

Mandate: One time and Recurring

The recurring payment on UPI started with a one-time mandate (UPI 2.0 released in 2017), which has very few practical use cases such as IPO subscription and security deposit refund. In 2020, UPI Autopay was launched with full recurring payment capabilities. But this solution also suffers from certain limitations. Read more about UPI recurring payments in Chapter 10.D: UPI AutoPay. D. UPI Pay-out

UPI is a perfect solution for many B2C as well as B2B (business to consumers or businesses) payout use cases such as vendor pay out, incentive pay out, disbursement of incentives or winnings of game etc. UPI runs on IMPS, so the pay-out is done in real time and 24x7. You need a source account, UPI rail and UPI ID of the beneficiary to transfer funds. If there is no UPI ID, then even the account number and IFSC code of the beneficiary will work. Read more about payout in Chapter 12 Closing Remarks

In a short period, UPI gained tremendous popularity among users as well as merchants. Users appreciate the convenience and merchants are thrilled with the performance & cost (the most economical payment mode, by far). For these obvious reasons, many merchants nudge their customers to make payments using UPI. This is where I am going to end this chapter on UPI but there is more when you read along as I have covered UPI transactions, UPI recurring payment and UPI payout in future chapters. 4.F Cash “Cash is the king and digital is divine” that’s what RBI said. We can debate about the second half of the sentence, but the first half is indisputable. Cash is undoubtedly ‘the king’. A lot of people ‘like’ cash…. It is easy to understand, it is tangible, it can be hidden from the taxman and if you have plenty of ‘it’ then you can swim in that like Uncle Scrooge (From Disney’s Duck Tales). India’s cash landscape, working, and its various complexities are quite broad so I will have to narrow the scope to online commerce. ‘Is cash acting as a catalyst for eCommerce growth or creating a hindrance? Or who will win the race, cash or online payments?’ Let’s see! Irrespective of all the talks about the digital economy, cash still, remains an important mode of payment. Even in online eCommerce, more than half of the transactions are still cash (on delivery). Many users who have the means to pay online still prefer cash. There are many reasons for usage of cash:

Lack of trust in the merchant (whether my dress or food will be delivered) Fear of paying online (oh… what if they steal my money?) Lack of knowledge about how to use a payment instrument, or simply random stubborn reason, ‘I prefer cash only’ (let us not ignore the ignorant people) How ‘Cash’ helped eCommerce grow?

Cash on Delivery (COD) helped merchants to build trust. After successful order fulfilment (may be multiple orders), a sceptical customer would start paying online. (FYI - I am one of those sceptics). eCommerce merchants do not mind cash (although it has its own problems) as long as they are selling. How ‘Cash’ is a hindrance to eCommerce?

a.

Cash collection and associated cost: Either the merchant’s delivery person or 3rd party logistics/delivery company will collect cash from the customer. If cash is collected by the 3rd party delivery company, they charge additional cash handling fees apart from delivery charges from the merchant. If a merchant’s delivery person collects cash, even then the bank charges cash management charges to handle cash. The point is cash is not free.

b.

Fear of losing cash: Delivery person may lose collected cash.

c.

Refunding cash transactions is a bigger problem. Merchants cannot send a person to a customer’s home to return the money. Can they?

How do you deal with cash?

Companies tried and are still trying various ways to convert COD (Cash on delivery) orders to POD (Payment on Delivery) through various means:

a.

Mobile POS machines to swipe cards.

b.

ePOS or Soft POS: Mobile SDK that can generate dynamic QR code or send payment links or even facilitate NFC payment.

c.

QR codes: Send static UPI QR Code (amount needs to be entered while scanning) with the delivery person or stick dynamic UPI QR code (amount is embedded in the QR) on the package so the customer can pay using UPI App (or even cards using Bharat QR).

d.

Send payment links to customers so customers can click & open it and pay using cards, net-banking, wallet, or UPI

No surprises that there is no silver bullet to the COD problem. Each of the above methods has one or other issue ranging from data connectivity to limited payment options to commercials. After doing all this, if the customer still wants to pay in cash, they can’t say ‘no’ to her. Refunding ‘Cash’ orders

Cash orders create bigger problems when it comes to refunds. When a cash order is cancelled/returned, how do you return the refund amount to the user? Reverse logistics person who collects the product from the customer is not responsible for returning the money. So how do you deal with this situation? There are multiple options to deal with it: a.

Put that refund amount in the merchant’s closed wallet and thus avoid hassles of refund plus feel happy that you have increased ‘customer stickiness’ (customer has to buy something on your website as funds are stuck in that closed loop wallet).

b.

Collect the customer’s bank account details and push the money to that account via IMPS or NEFT.

Note: Merchant should be sure that account details are correct by (1) collecting the cancelled cheque (2) doing penny drop to that account to verify the beneficiary details. c.

Collect UPI ID and push the refund amount to that UPI ID. Note: Merchant needs to validate the correctness of the UPI Id and beneficiary details

Problems start cascading when you will have to do these processes (mentioned in b and c) at scale with efficiency. Closing Remarks

When Uber started its operations in India (2014), ‘cash’ option was not available. But eventually, Uber added ‘cash’ option. So, every merchant wants every customer to pay digitally but cash is inevitable. And when you add ‘cash’ option, it will bring its own set of challenges along with it. India is one of the advanced countries when it comes to innovations in digital payment. Government and RBI have a great vision for digital payments. Demonetization, reducing MDR on payment modes (UPI, RuPay Debit Cards), innovative platforms (UPI, BBPS etc.), penalties for cash handling, regulations & frameworks for securing merchants and customers - Many such actions were taken to boost digital economy but still there is more cash in circulation than ever. So, a complete digital economy is a dream and a very big dream. But India is progressing one step at a time towards that. But for now, we have to live with ‘cash’ and have to figure out better ways (solutions, processes) to move to digital. 4.G Crypto Currencies What is the difference between a competition and a substitute?

For Indigo Airlines, the competition is SpiceJet or Air India. But who are the substitutes to Indigo Airlines? Those can be buses, trains, ships, or cars. But who is the biggest substitute for the airline? Aren’t those Zoom, WebEx or Google Meets (at least for business travels)? Think about it! Similarly, let us see who are the competitions or substitutes to online payments? Maybe ‘cash’… right? You can shower a thousand words of praise about online payments, but cash is still cash, cash is the king. And Cash is the biggest competition to online payments. There is one more important substitute - “Crypto Currencies”. Maybe not so much in the Indian context (at present). But one cannot ignore the rise of digital currencies. I will just touch upon the topic here. Crypto currencies are everything that you don’t understand about money combined with everything that you don’t understand about computers — John Oliver What is money/currency?

That is a simple question - we all know ‘what is money’, right? Are you sure? Investopedia defines money as “a medium of exchange for transaction purposes” We started with goats (barter system), precious metals and now reached currencies (coins and banknotes).

There is not much difference between the note issued by the RBI and the one designed by my daughter… ‘as long as you “believe” that these have ‘value’. A currency note is nothing but a ‘promise’ - a promise that the person holding it can exchange it for goods/services worth that amount. That is ‘literally’ printed on the note along with the signature of RBI’s Governor. “I PROMISE TO PAY THE BEARER THE SUM OF FIFTY RUPEES” With RBI issued Rs. 50 currency note, I can buy anything worth Rs. 50 in a grocery store. Come to think of it, Bantu Money also has a value, in exchange for her money, she allows me to watch any NEWS channel of my choice for 1 hour. The only difference is that the entire country believes in RBI’s currency and only the 3 people in my family believe in Bantu’s currency.

So, if enough people believe ‘something’ (be it peanuts or Pokémon trading cards or Bitcoin) has a value, then yes, those items can become currency for them. How Crypto Currencies are min(t)ed?

You need to generate the currency, so the central bank will print currency notes based on various macroeconomic conditions (earlier it used to be against gold). Irrespective of this, a currency note is nothing, but a loan and it’s expected that all currencies issued will return to the bank. Expectedly, there is a limit to how much money you can print. If you print more, then you will push the economy to hyperinflation (‘Rapid, excessive and out-ofcontrol general price increases in an economy’ - Investopedia) and that is what happened in Argentina and Zimbabwe. In Crypto Currencies, as money is created virtually, it is created by a process called ‘mining’ (it is not a simple concept to wrap your head around). For now, let’s say computers do this “something” and Crypto Currencies get generated — but that doesn’t mean there is an infinite supply of virtual money. If that was the case, then these currencies wouldn’t have good ‘value’ because if supply is more, then the value will drop. Hence, there is a limit to how much virtual money you can create. (If creation has no limit, then some currencies have logic of destroying currencies to keep check on number of tokens in circulation). Ledger & Verification

For government issued money, the central banks keep a track of it — how much is printed, how much is with banks and how much is in circulation. As crypto currencies are mined by not one single authority or entity, everyone (call it ‘node’) will keep the ledger. That is called a distributed ledger. These distributed ledgers need to be updated every time there is a transaction.

Considering the central banks’ money is printed and managed by one entity, that entity has to provide systems/platforms to transfer it between entities. In India, for domestic transfers we have NEFT and IMPS whereas for cross-border transfers, we have outward & inward remittances. In crypto currencies, there is no such barrier or central clearing house. Anyone can transfer money to anyone, but every time the transfer happens, distributed ledgers need to be updated. So basically, everyone (node) is keeping count of everything.

Let’s summarize these points:

Money has value if everyone believes in it Money can be created out of thin air Limit the supply so currency’s value won’t slide Have ledger to keep the count Have mechanism to exchange it

When these points are brought together, crypto currencies are born. And today, we have thousands of crypto currencies with notable ones such as Bitcoin, Ether, Dogecoin. How Crypto Currencies can be useful?

Let me give you a simple example of cross-border payments.

If you see, the transaction that usually takes 5–6 days by traditional process can be done within minutes. Think of it — there is no issuer, acquirer, clearing house/switch hassle, just simple wallet to wallet transfers. Wonderful, isn’t it? What is the problem then?

The most important concern with Crypto Currencies is, they are not issued by the Government or RBI. Also, there is no clear end-to-end tracking of fund movement (who owns it and whom it is being transferred to). So, the government will not allow the creation of a parallel money network that may allow black money, terror funding that can even undermine

national security. Crypto Currencies became the hottest topic of discussion in 2017 when their value rallied. A bunch of Crypto exchanges started, and a lot of people started investing. But India’s stance about crypto currencies was not clear. Although a few Payment Aggregators and banks facilitated payment services to these Crypto Exchanges (to invest and withdraw), many big payment service providers and banks stayed away from this frenzy. Then Government and RBI banned crypto currencies (in April 2018) and all the companies vanished. Only in March 2020, after the Supreme Court order, crypto exchanges started mushrooming again. But still, many banks and payment providers are not ready to work with these Crypto currency exchanges. Way Forward

GOI stance is clear that it won’t consider Cryptocurrencies as legal tender, but GOI and Regulator are aware of the future. So, the RBI is talking about having India’s own digital/virtual currency just like what China is doing. Does it really has value? Especially considering our domestic payments platforms are much more efficient (thanks to UPI, IMPS, NEFT) compared to other countries. Maybe we will wait till we know more about the shape, size, and form of RBI’s digital currency. Blockchain/distributed ledger is an interesting concept and has many applications in KYC management and supply chain management. Many advocates of Crypto Currencies (including my friends who randomly invested in those tokens) have high hopes and big words commending Crypto Currencies. But at this point of time, “you cannot take ‘it’ to the bank” (pun intended).

Chapter 5

Guidelines

Long ago when I was a teenager… I asked my close friend, “What do we need to ride a bike?”. Without a second thought, he said, “We need a bike… just a bike”. The answer made perfect sense at that moment but later, I realised that we needed a license, bike insurance, knowledge of traffic rules and most importantly, money to buy a bike. What did I learn? There are guidelines that apply in all spectrums of life – a few are mandated by governing or regulatory bodies, and a few are self-imposed. ‘Red light’ at a traffic signal means that we should stop the bike — that’s by regulation. But if there is no cop at the signal & no traffic but you still stop at the red light, that’s self-regulation. Payments/FinTech cannot operate on self-regulation (as it involves people’s money). So, RBI (Reserve Bank of India) is the regulator that sets the guidelines. Below are some of the important guidelines related to payments ecosystem: 5.A Payments and Settlement Act of 2007 This is the main guideline that is followed by the online payments industry. This is not one single document but rather, multiple notifications that are

drafted over a period. One needs to read all notifications and related guidelines to get the complete view. A few of the notable points of these directives are: Intermediaries (Payment Aggregators, acquiring bank or payment service provider) should move money via nodal account (collect money from acquiring banks and other payment service providers to nodal account and then settle to merchants). Also, do not keep funds in the nodal account for more than 3 working days. If funds are held in account for more than 3 working days, then the intermediary needs to provide justification. Follow the Master KYC (Know Your Customer) guidelines while on-boarding merchants. That means: Conduct due diligence about the merchant (business model) and collect KYC documents of the merchant and its director(s) or authorized signatories. These are not stringent guidelines, so the industry was more or less selfregulated (basically, everyone is expected to do the right thing when no one is watching them). No certification required and nothing to report back unless you appear on RBI’s radar. However, it so happened that, along with the growth of digital payments, even the frauds increased. Hence, the RBI had to regulate various aspects of payments (mandatory 2nd Factor Authentication, data localisation etc.). So now, PGs (Payment Gateways) & PAs (Payment Aggregators) need to be regulated thus, the RBI came up with a comprehensive (almost) set of guidelines in March’20. 5.B PA/PG Guidelines

Here are the 8 broad points:

1.

Authorisation: Get an authorisation from RBI to run a PG or PA business.

2.

Capital requirement: Do you want to move the money for merchants? Then first, show the money. That is a minimum of Rs. 25Cr net worth.

3.

Merchant Due Diligence: On-board merchants after due diligence and follow Master KYC (Know Your Customer) and AML (Anti Money Laundering) guidelines.

4.

Security & fraud prevention: Follow highest level of security, data protection, data localisation practices along with PCI-DSS and PADSS compliance.

5.

Customer Grievance: Customer is important, safeguard them and address all customer complaints/grievances. Also, appoint a nodal officer.

6.

Fund movement via Escrow: PG/PAs can move funds via escrow accounts. PA can maintain 2 escrow accounts with 2 different banks. There is higher flexibility in terms of holding the funds in an escrow account (depending on confirmation, delivery, and refund dates). The

cherry on top is an opportunity to earn ‘interest’ on a non-core portion (if PA and Banks agree). 7.

Governance: Bring in corporate governance in the company.

8.

Reports: Different types of reports need to be submitted to RBI on annual, quarterly, monthly, and non-periodic basis. All in all, this is a guideline, and I am sure guidelines will be refined over the years to build a more robust payments ecosystem.

Here are few observations (again, only a few notable ones): Super small aggregators may not meet a few criteria, especially the capital requirement. So many such companies may morph into resellers to bigger aggregators or shut down or get absorbed by other Payment Aggregators. If Payment Aggregator earns interest on a non-core amount that was kept in an escrow account, then will the banks increase MDRs? (Liabilities of the bank have increased… isn’t it?) ATM PIN cannot be used as 2FA for card-not-present (online) transactions. Payment Aggregators cannot enforce transaction limits, but only bank/issuing entity should (not a good rule if PAs want to tighten the velocity checks). Refunds can go to a different source if the customer is fine with it. Merchants can park funds in advance towards refund processing. Refund to source via payout solutions (IMPS, NEFT, UPI, Visa Direct, Master Money send, wallet) may become popular. Card vault: This part keeps changing. First, guidelines said that only PA/PG can store cards and not marketplaces (e.g., Flipkart or Amazon) but later it was changed that only banks can store the

cards, not even Payment Aggregators. Looks like there are two options: Payment Aggregators/merchants can have a card vault in a bank (literally) or move to tokenization (which will take a long time to be ready). Entities need to comply with new card vault guidelines by the end of December 2021. 5.C Prepaid Payment Instrument (PPI) Guidelines Prepaid Payment Instruments work on pre-loaded amount i.e., amount has to be pre-loaded on the instrument (Card or wallet) and then available balance can be used for purchases (in-store and online) as well as for cash. Below are the guidelines for the issuance of prepaid payment instruments: Type of Entities: Banks and non-bank entities can apply for PPI license to prepaid instruments (Cards or wallets). Capital requirement is Rs. 15 Cr positive net worth. PPI licensed entities to procure separate approval from RBI for cobranded cards (Co-branded card is launched for a merchant in partnership with issuing bank and card scheme) Funds of prepaid balance are parked in non-interest-bearing special purpose account (e.g., Nodal Account or escrow account). Prepaid instrument can be issued only after completion of KYC (Minimum KYC: allows balance up to Rs. 10,000 and Full KYC allows balance up to Rs. 2,00,000). Prepaid Instruments are allowed for cash withdrawal at ATM or POS (depending on type). PPI licensed entities can avail NEFT/RTGS facility by directly setting up accounts with RBI - But RBI is yet to share clear guidelines on this.

PPI entities to allow interoperability among payment instruments (e.g., my PayTM balance can be moved to Freecharge) - But RBI is yet to share clear guidelines on this. Salient Features of Prepaid Payment Instruments: 1.

Acceptance channels may vary for prepaid cards and wallets (e.g.: wallet can’t be used on a POS machine, but card can be swiped).

2.

Cards come with Expiry Date (Gift Cards: 1 Year, Reloadable Cards: 3 years) but wallets don’t expire (technically - but deactivated if wallet inactive for more than 1 year).

3.

Limit on the amount that can be loaded Gift Cards: One time loading Reloadable open loop cards: Minimum KYC - Rs. 10,000 and Full KYC - Rs. 2,00,000 Forex Cards: $2,50,000 per year (with one-time max amount of $10,000)

4.

Currency that can be loaded Domestic — INR only Forex — Other currencies

5.

Restriction on cash withdrawal through ATM or transfer to bank a/c Gift Cards are not allowed for cash withdrawal as well as transfer to bank a/c Reloadable cards and Forex cards can be allowed for ATM withdrawal. Balance amount can be transferred to bank a/c

6.

Restriction on acceptance based on

MCC (merchant category code): card is accepted only with type of merchants (e.g., Sodexo card at Grocery merchants). MID (Merchant ID)/TID (Terminal ID): Health card that works at partner hospitals Territory: Forex card is not accepted in India, Nepal, and Bhutan). 5.D Guidelines for Cards including SI on Cards RBI has rolled out multiple guidelines on cards to safeguard the users while doing Card-Present (in-store payment) and Card-Not-Present (payment on merchant’s website/App). Recently, RBI tightened the guidelines on Standing Instruction (SI) on Cards. Below is the snapshot of various guidelines that are enforced by RBI

Guidelines specific to SI on Cards (Mandate on Cards)

Coverage: All types of cards (Credit, Debit, Prepaid), Scheme (Visa, MC, RuPay, Amex etc.) Debit limit: Maximum of Rs. 5000 per debit

First transaction (done for mandate registration) should adhere to 2FA (2nd Factor Authentication) or AFA (Additional Factor Authentication) Pre-debit Notification: Issuing banks should send pre-debit notification to the cardholder at least 24 hours before debit. Also, issuing banks should provide an option for the customer to opt out. Post-debit notification: Issuing Bank should send post-debit notification to the cardholder Cancellation: Issuer to provide an online facility for the cardholder to cancel the mandate (Customers can either opt only out from a specific debit or can opt entirely out of the mandate. Cancellation of mandate should follow 2FA/AFA. Dispute Management: Separate dispute management process for recurring payments from the regular chargeback process. Payment Aggregators and Acquiring banks should not add new customers to existing SI on Cards model from 1-Apr-2021 but can continue to honour already registered mandates. Deadline to adhere to above guidelines: 31st Sept 2021 Note: Links to all guidelines are listed in ‘Reference’ section at the end of the book Closing Remarks

When Uber started in India (2014), Uber was using outside India PG (Payment Gateway) and skipping 2FA (OTP) to provide seamless user experience. RBI told Uber to adhere to 2FA plus other FEMA guidelines. I am sure Uber’s lawyers might have put forth some grand arguments to counter it. But in India, Uber may be running the cabs, but RBI owns the

road (metaphorically). Without much choice, Uber moved to PayTM wallet to provide that seamless experience. Here is one of my experiences: Mandatory 2FA was rolled out in 2012. That time, I was working at enStage (Wibmo, now acquired by PayU). We were into ACS service and open loop prepaid cards. To adhere to new guidelines, we had to replace the existing cards (As the service code has to be updated in the magnetic stripe of the card). This is an additional cost to the issuing banks. At times, the guidelines feel a bit troublesome as the ecosystem has to undertake additional efforts to ensure the adherence. Although we say that change is constant, frankly, nobody likes when things change. But in the long run these guidelines will help build a secure and efficient payments ecosystem that both customers and merchants/business can rely on.

Chapter 6

Payment Aggregator (PA)

Payment Aggregators (PAs) are the prominent players in the payment ecosystem. Many times, people confuse Payment Aggregator with Payment Gateway (PG). Payment Gateway (PG) is a piece of software that is used by acquiring banks to process card transactions. That’s it. CyberSource, FSS, MIGS, ISG are some of the PG providers in India. Whereas Payment Aggregator (PA) brings multiple payment options (Credit cards, Debit Cards, prepaid cards, Net-Banking, UPI, Wallets, Alternate Credit products etc.) on a single platform by integrating with various payment processing entities. BillDesk is the ‘official’ pioneer of payment aggregation in India and 20+ years later, BillDesk is still the market leader. Today there are more than 30+ Payment Aggregators in India. Some of the prominent ones are BillDesk, Ingenico (Earlier TechProcess), CC Avenue, RazorPay, PayU, Cashfree, ZaakPay etc. And there are smaller ones such as AirPay, Paykun, EaseBuzz, IppoPay etc. In the next few chapters, we will talk about integration, performance, settlement, and operations related to Payment Aggregators. 6.A Risk and Underwriting

Risk is the underlying theme of payments; all processes including technology, features, guidelines, and merchant on-boarding process are designed to reduce the risk. MDR (Merchant Discount Rate) is the barometer of that risk in the payments ecosystem. An e-commerce company may have a MDR of 1.80% on credit cards but an education institute will enjoy 1%. Reason for this differential rate is ‘the risk’ associated with these two different sectors. Similarly, differential rates apply on POS (point of sale) and online transactions. In case of POS (i.e., CP-Card Present scenario), the transaction charges are much lower compared to online payments (CNPCard Not Present scenario). “Think of it like an insurance premium of a term policy. The premium amount for a 28-year-old non-smoker will be much lower than that for a same age person who smokes. Insurance companies perceive the second person ‘riskier’, so the premium goes high”. Risks in the Payments Ecosystem

There are two main types of risks: Financial Risk (where the entities can lose money) and Reputational Risk (where entities can lose credibility). These risks can be attributed to fraudulent transactions and excessive chargebacks. The risks can be mitigated by regulators, card schemes, banks, processors, and payment service providers by enforcing guidelines, security protocols and processes. Example: Velocity checks (limits on transactions, amount), risk management engines (IP tracking, device fingerprints), tokenization,

encryptions, PCI-DSS Compliance, 2nd Factor Authentication. One of the ways to reduce risks in the payments business is on-boarding “good merchants”. Good Merchant

Merchant’s business model It is important to understand a merchant’s business model: sector, product/service offering, deliverables, mode of delivery (physical or digital), business cycle (regular, seasonal), vintage of merchant, merchant’s financials, founders/directors background, Terms of services, refund, or cancellation policies. Collect and verify merchants’ KYC documents (as per Master KYC guidelines) Company PAN

Articles of Association & Memorandum of Association

Company GST number

Authorized Signatory’s/Director’s KYC (ID and address Proof )

Certificate of Incorporation

Board Resolution of appointing authorized signatory

Address Proof

Bank A/C details (Cancelled cheque or bank statement)

Every merchant has a different business model, an e-commerce company may deliver goods in a day and another one may take 15 days. A merchant may deliver service online (e.g., Gaming) but others will do physical delivery (e.g., Food Delivery). A merchant may allow refunds (e.g., Travel Booking) and another one may not allow refunds (e.g., Examination fee). So, Payment Aggregators should understand the merchant’s business model, processes, policies, and information available on customer touch points to ‘underwrite’ the merchant.

Most importantly, Payment Aggregator should on-board merchants whose business model is allowed as per the guidelines of Government, Courts, RBI, Card Schemes, and the partner banks. Reason for Underwriting

Payment Aggregator is just a facilitator of payments, the banks are the one who issue MID (Merchant ID), process payments and move funds. So, the Payment Aggregator is underwriting (taking guarantee) the merchant to use the bank’s payment system. So, Payment Aggregators have to be careful while on-boarding the merchant and follow due diligence to make sure the right merchant with a reasonable business model is on-boarded. Whoever is deemed as risky is not on-boarded because the cost of doing business with the wrong merchant is tremendously. Example: PG Charge: 2%, back-to-back cost = 1.90% So, the Payment Aggregator has to process 2000 transactions of Rs. 500 each to make a profit of Rs. 1,000 and only one valid chargeback of Rs. 1000 due to bad merchants will wipe out that entire profit. Imagine if there was a fraudulent transaction of Rs. 20,000. You can calculate how many transactions the Payment Aggregator has to process to make up for that loss. Closing Remarks

Yesterday’s start-ups are today’s unicorns and yesterday’s big guns are now out of business. New business models evolve every day. Just because there is risk that doesn’t mean Payment Aggregators shouldn’t do business but need to mitigate that risk. 6.B MID and Live ID

Banks are the one who process the payments and a Payment Aggregator is just a layer above those banks. To process transactions, the Payment Aggregator needs to procure MID (Merchant ID) from the banks and then link those MIDs to the Live ID of the merchant.

MID Procurement

To procure MIDs from banks & wallets, the Payment Aggregator collects business details & KYC documents of the merchant and submits them to banks in specified formats. Partner Banks and wallets reserve the right to issue the MID for the merchant. Sometimes banks may seek additional documents or clarifications related to the merchant’s business model. Note: Banks usually refer to Terms of usage, privacy policies, refund or cancellation policies that are written on the merchant’s website/App. MID issuance policies followed by banks are a combination of: Guidelines set by card schemes such as Visa, MasterCard, NPCI Policies/regulations by RBI and the Government Bank’s internal compliance or risk policies Example: SBI doesn’t issue MID for wallets, HDFC doesn’t issue MID for rummy merchants

MID issuance Time

The MID approval process varies from one bank to another. TAT (Turn Around Time) may vary from 2 days to a couple of weeks. Master MID

Payment Aggregators can have better SLA (Service Level Agreement) with the banks for issuance of MID. But that is not practical as banks work with multiple Payment Aggregators. a.

Master MID as a stop gap arrangement: Every Payment Aggregator will have industry or MCC (Merchant Category Code) specific Master MID from the banks. Payment Aggregator is a merchant of the bank and Payment Aggregators’ merchants are sub-merchants to the bank. The Payment Aggregator can configure those generic MIDs to start with and replace them with bank approved MIDs.

b.

Major challenges in using Master MID: Master MIDs are issued at standard pricing so it may not be possible for a Payment Aggregator to run the show without making losses (e.g.: Credit Card rate of generic MID is 1.85% but Payment Aggregator’s commercials with merchants is 1.80%. So, if generic MID is enabled then the Payment Aggregator will lose 0.05% of value for every transaction). Solution: Procure Master MIDs with different pricing from different acquiring banks and configure them intelligently to reduce the loss.

c.

Slippery Slope with Master MID: Banks do not approve certain types of merchants. A Payment Aggregator can on-board such merchants on Master MID. But that is wrong and eventually when the bank catches such practices then Payment Aggregator will face either a penalty or get black-listed by the bank. So, beware!

d.

Approval for net-banking: Except 9-10 banks, all other banks work on carpet approval wherein Payment Aggregator issues MID based on its discretion and then shares merchant’s details with banks (if needed). So, Payment Aggregators can enable 25–30 banks without any approval or delay. Large banks that provide explicit approval: Allahabad Bank, Axis, Bank of India, City Union, Corporation, DCB, Deutsche, HDFC, ICICI, IDBI, IndusInd, Kotak, SBI, YES Bank. Most of these long tail banks do not have process or tech capability to issue individual MIDs for the merchant. They didn’t develop it because they are not big in acquiring business. So, these banks gave carpet approval to PAs and have a revenue sharing model.

e.

Merchant Specific Vs. Master MID: Have you ever checked what the narration is, in a card statement or bank account statement when you do an online transaction? If a merchant is configured on its own MID, then the merchant’s name would appear in the statement. In case a merchant is on generic MID, or transaction is done on one of carpet approved banks then Payment Aggregator’s name will be shown. (Refer below)

Live ID (issued by Payment Aggregator)

Live ID is a unique identifier issued by a Payment Aggregator to a merchant (sometimes they call it MID but for ease of discussion, we will call it Live ID/LID).

As mentioned earlier, MIDs issued by the banks & wallets are linked to this Live Id. Transactions, refunds, settlements, chargeback, card vault of a merchant are all linked to this unique Live ID. Some of the attributes of Live Id are: Settlement Account: Each Live ID can be configured with one settlement account (If a merchant requires multi-account settlement, then use scheme codes/Split Payment solution). Acquiring bank: Multiple acquiring banks can be configured for one Live Id (helps in configuring performance-based routing for cards). Commercials: One set of rates (MDR) can be configured for one Live ID. Fee Model: One type of fee model (upfront deduction, Surcharge, or Invoicing) can be configured for one Live ID. Meaning, you cannot configure hybrid models (e.g., net-banking on upfront and Debit card on surcharge model). If you come across such cases, then issue separate Live Ids. Card Vault: Card vault is linked to the Live Id (ideal case). Example: A merchant has to Live Ids (A1234 and B6789) then saved cards at A1234 will not show in B6789 unless card vaults of those Live Ids are merged. Number of Live Ids: Payment Aggregator can issue multiple Live IDs for a merchant without additional approval from banks. With these two chapters, we have completed the on-boarding processes of a Payment Aggregator. Let’s discuss the next topic - Money i.e., Commercial Models.

Chapter 7

Payment Aggregator – Commercials

The fundamental objective of a business is making money. This becomes more interesting in the payments business as it is all about moving money. In the next three chapters, I will cover how Payment Aggregators make or lose money in this business. 7.A PA/PG Charges or MDR When various entities move the funds from Point A to Point B, they charge certain fees. Payment Aggregator will charge MDR (merchant discount rate) to its merchants (which merchant can choose to absorb or pass it on to the customer). Typical charges will be: Percentage (%) of successful transaction value (E.g., 1.80% of transaction value) Flat fee per successful transaction (Rs. 10 per transaction) Mixed pricing i.e., combination of % of value + Fixed Fee (E.g., 1.80% + Rs. 1) Note: There is additional 18% GST applicable on these charges. Factors that influence MDR

1.

Type of merchant category (whether e-commerce, Utility, or insurance)

2.

B2B or B2C business model

3.

Domestic or international transaction

Also, the MDR depends on the Payment Aggregator’s back-to-back commercial arrangement with banks and other Payment Service Providers. Also, the Payment Aggregator will offer MDR to the merchant based on the merchant’s volume, merchant’s brand and of course, PA’s loss absorbing capacity. Typical commercial structure for different merchant types (sectors):

Important note:

Credit Card rate is higher for eCommerce sector compared to Utility, Education, insurance Supermarket (and eGrocery) sector has MDR of 1.10% - 1.25%

EMI on cards will have same rate as Credit cards (for the sector) Payment Containers offer bundled rate irrespective of the payment mode (E.g., 1.25% irrespective whether user pays using UPI, wallet, credit card, or debit card). PhonePe can be enabled only with UPI and/or Debit cards options. Google Pay is enabled for free (as it is only UPI and it is an issuer side PSP). B2B companies enjoy flat fee on net-banking (Except CITI and sometimes HDFC). CITI net-banking is always in% (not that useful as CITI is shutting down retail business). MDR is exempted for UPI and RuPay Debit cards (from 1st Jan 2020). MF, Brokerage, NBFC can get flat on debit cards (from selected acquiring banks). Credit cards and wallets are not allowed in investment & NBFC sectors. External control of MDR

Wallets and BNPL companies have complete say in their pricing. Net-Banking is a bilateral arrangement between the payment aggregator and bank. So, banks work on a fixed fee model (E.g., HDFC, ICICI, Axis, Kotak, Yes) or revenue sharing model (other banks). Credit card rates are decided by interchange arrangement as dictated by card schemes.

Debit cards and UPI rates are dictated by the Government of India with the purpose to boost digital payments.

Debit card rates are capped since Jul’12 and later UPI was included for price control. From Jan’18 till Dec’19, GOI has reimbursed acquiring banks @0.25% for transactions below Rs. 2000 for debit cards and UPI. The reimbursed amount was split among acquirer, issuer and card schemes but since Jan’20, GOI stopped reimbursement. As per GOI, transaction fees/MDR is not applicable for RuPay debit card and UPI. But Payment Aggregators do charge some fees and call it with different names: TSP charges, platform charges or infra charges etc. Let’s move to the next chapter, where we will see how the MDR is charged. 7.B Commercial Models There are three commercial models in practice: Upfront Deduction, Surcharge, Invoicing.

Let’s assume: PG Charge or MDR = 1%, GST = 18%, Transaction Amount = 100 1.

Upfront Deduction

Payment Aggregator deducts the charges and GST amount before settling the transaction amount to the merchant. (Sectors: eCommerce, Gaming, Travel merchants) Customer Pays = 100, Payment Aggregator deducts = 1.18 and merchant gets = 98.82

2.

Surcharge

Let us say the merchant doesn’t want to bear the charges then who will bear it? The user. Payment Aggregator’s charges + GST amount is passed on to the user (Sectors: Utility, Government, Education Institute) Customer pays = 101.18, Payment Aggregator keeps = 1.18 and merchant gets = 100

3.

Invoicing

Sometimes either merchant or merchant’s business model doesn’t allow to either deduct money upfront or apply surcharge to the user. In such cases, the Payment Aggregator will raise monthly invoice to the merchant. (e.g., Mutual Fund Sector) Customer Pays: 100, Merchant Gets = 100 and Payment Aggregator will invoice amount = 1.18

Payment Aggregators avoid invoicing models (as much as possible) for obvious reasons: (a) It is always a pain to collect money from others (b) there is an opportunity cost (A month delay in getting the money from the merchants). Settlement from partner banks to Payment Aggregator

There are two sets of rules followed by the banks and other payment issuers and service providers. Gross settlement: Entire transaction amount is settled to the Payment Aggregator. The charges are raised on monthly basis (E.g., net-banking). Net Settlement: Charges are deducted from the transaction amount and then settled to Payment Aggregator (e.g., acquiring banks). 7.C How Payment Aggregators Make money? The main purpose of a business is to make money. Not just revenue but also profit. And Payment Aggregators are not an exception to that.

A Payment Aggregator relies on partner banks, wallets, or other payment processors to enable payment services to merchants, so the Payment Aggregator will have to pay those entities. Top line and bottom line of a Payment Aggregator depends on how it manages commercials with merchants and costs with the partners (banks and other payment issuers). Pricing Principle

Wherever cost is fixed cost, charges should be higher than cost (Example: If fixed cost is 1.50% then charge to merchant should be 1.50% or more). Wherever there is revenue sharing arrangement, don’t worry about making loss but try to keep the top line intact (Example: On 50:50 revenue sharing model if you close commercials at 0.50% instead of 1% then you won’t make a loss, but your revenue will be reduced to half ) Note: To stop aggressive pricing for net-banking transactions (revenue sharing) some banks set a floor cost. Example: 50:50 revenue sharing with minimum 0.40% of transaction value. This forces the Payment Aggregators to give a rate of 0.80% and above. Impact of pricing on the P&L

Example A: Standard commercials with healthy margin

On processing Rs. 10,00,000 per day, Payment Aggregators will make a profit of Rs. 325. i.e.Rs. 1.18Lakh profit in a year. Imagine the profit if the Payment Aggregator processes Rs. 10 Crore per day… Awesome! Example B: Super competitive pricing (Say… to win the merchant)

I dropped the commercials on credit cards below bank cost and ended up making a loss of Rs. 175 per day which translates into a loss of Rs. 63,875 for a year. Now let’s do what we did in the last example but in the opposite. Imagine the loss on processing an amount of Rs. 10crore per day. From awesome suddenly the situation becomes gruesome, right? This is the beauty of the ‘volume game’: A small margin translates into huge profits over a period but with a small mispricing, Payment Aggregators will end up losing huge money. A simple way to make profit!

The MDR offered to a merchant should be higher than the cost. But it is next to impossible to follow this rule for all merchants across all payment instruments. So, the optimal approach is to try to make profit at the merchant level rather than on each payment instrument for that merchant. If you get correct details of total GTV, transaction count for a period (month or year) and transaction split across various payment modes (CC, DC, NB etc.) then you can provide differential pricing for different payment modes and still have profit at the merchant level. Other avenues to earn Revenue and Profit

1.

On-Us rates: Say Payment Aggregator has differential rate for On-Us (acquiring bank and card issuing bank are same) and Off-Us (acquiring bank and card issuing banks are different) from multiple acquiring banks then process On-Us transaction for respective issuers and thus can optimise the cost.

Here is an example of how such routing optimises the cost of processing.

In the above example, the profit margin is maximum if the Payment Aggregator uses two acquiring banks and takes advantage of differential pricing offered by both acquiring banks. 2.

Subvention: Banks enjoy the ‘float’ (money in a/c). Banks often work with Payment Aggregators and give subvention of a few basis points (bps) against volume commitment. Banks don’t work on this model all the time with all the Payment Aggregators. Example: Bank A has given subvention to Payment Aggregator A for merchant A. But the same bank will not enter a

subvention deal with Payment Aggregator B for the same merchant as there is no additional gain for the bank. Also, the flipside is that the Payment Aggregator who availed a lucrative rate basis volume commitment may have to put money from their own pocket if the volume commitments are not met. 3.

Account Benefits: Payment Aggregator’s nodal account is quite lucrative for any bank as a huge amount moves through the account. Although Payment Aggregators cannot earn interest, banks are ready to plough back some amount to the Payment Aggregator against the float or provide better rates or give priority in partnership deals or RFPs. As per the new PA/PG guidelines of RBI, the Payment Aggregator is allowed to move from nodal accounts to escrow accounts. Also, RBI has allowed PAs to earn interest on ‘non-core’ amount of those escrow accounts.

4.

Banking Products: A Payment Aggregator can offer other banking products to its merchant at healthy margins. Lending can be cornerstone product – A payment aggregator can offer lending to its merchants by partnering with banks or NBFCs. It is not necessary to offer explicit lending but can be baked as part of core offering (e.g., early settlement). Payment Aggregators can also issue co-branded credit cards to its merchants. Payment Aggregators can earn revenue streams in these products as well. Please refer Chapter 9B – Early Settlement and Chapter 18 – BaaS for more details

Where does a Payment Aggregator lose money?

a.

Auto-refunded cases: Merchants who need instant gratification would want Payment Aggregators to configure auto-refunds if transaction status is not definite (Success/failed) within specified time. When the transaction is successful then the Payment Aggregator will mark the refund and won’t give settlement to the merchant. But the acquiring bank has marked the status successful so it will deduct the charges from the Payment Aggregator’s settlement. As there is no merchant settlement for that transaction so Payment Aggregator ends up losing that amount.

Example: Transaction Amount = 100, Charges: 1% + GST. Then Payment Aggregator ended up losing 1.18 for the auto-refunded case. b.

Surcharge (bad configuration): Earlier we had covered the surcharge model, where PG Charges (+ GST Amount) are passed on to the customer. This model is typically used by merchants from Utility, Government, education and B2B sectors. But banks do not distinguish between transaction amount and surcharge amount, for the bank’s point of view, it is one single amount. So, the bank applies its rate on the total amount, not just the transaction amount.

Payment Aggregator collects = 11.80 (i.e., 1% of Rs. 1000 + GST) But Acquiring bank deducts = 11.94 (i.e., 1% of Rs. 1011.18 + GST) So, Payment Aggregator lost = Rs. 0.14 (If you remove the GST component from calculation, then the loss would be INR 0.12). And as payments is a volume game so more the transactions, more the loss. c.

Chargebacks where PA couldn’t recover money from merchants: We discussed this earlier in the Chapter 6.A, a mismanaged chargeback will end up wiping large profit as Payment Aggregators work on thin (or zero) margins. Example: PG Charge: 2%, back-to-back cost = 1.90% So, the Payment Aggregator will have to process Rs. 10,00,000 to make a profit of Rs. 1,000. And one mismanaged chargeback of Rs. 1000 will wipe out the entire profit.

d.

Fraudulent Transaction: Payment Aggregators will have to compensate banks or merchants if a fraudulent transaction is attributed

to Payment Aggregator and such cases impact the merchant’s revenue/margins badly. Imagine if there is a fraudulent transaction of Rs. 10,000 then the Payment Aggregator has to process INR 1Crore GMV to compensate for that single case. e.

Main reason for loss is ‘bad commercials’: Pricing is a major differentiator and entry point for new Payment Aggregators to get transaction shares from large merchants. And a Payment Aggregator will have to beat not only other Payment Aggregators but also acquiring banks, wallets (who also can directly integrate with merchants). Subvention won’t happen every time, so the Payment Aggregator will have to undercut competitor’ rates and many times the rates eventually go lower than actual cost and thus they start losing money.

How to beat the price war:

Create a niche segment (won’t always work as payments is volume game). Differential pricing strategy for small, medium, and large merchants. Choose which battle you want to fight (decide for which merchants you will undercut the cost). Deliver the value (performance, operation support) for long run engagement. Tighten back-to-back costs with unique processing arrangements (on-us routing) and fix revenue leakages (due to surcharge model or auto-refunds).

Better engagements with banks to avail privileged rates. Diversify product portfolio and thus create stickiness. Note: I haven’t factored infrastructure, admin, and support costs. If you consider these costs, then entire calculations will be different. If most of the Payment Aggregators are losing money, then why compete on price? The idea of price war is simple: knock-out the opponents with your deep pocket (funding from VC/PE) and then be the dominant player. If competition is for valuation but not for value creation, then price will be the only differentiator and price war is inevitable. It is high time the payment service providers should start taking this price war seriously else no one will make profits and just burn VC/PE company’s funds. “…the best result will come from everyone in the group doing what’s best for himself and the group” — John Nash

Chapter 8

Payment Aggregator – Integration

In this chapter, I will cover the most important aspects of payments such as how to build a payment page, how to build a better card vault, different types of transactions of payment instruments and how to improve success rate by optimizing transaction logics. 8.A Payment Pages Payment Page is the page where the customer selects the payment method (cards, net-banking, wallet, payment container, UPI, credit products etc.) to start the transaction. Below are the various possibilities in payment pages. A.

Payment Aggregator hosted page (non-Seamless or redirection flow): Payment page is hosted by a Payment Aggregator. When the customer clicks on the ‘pay’ button, the customer is redirected to Payment Aggregator’s page to select the payment method and proceed with the transaction.

Pros •

Simple Integration so less effort

Cons • • •

B.

Limited control on the page design Limited to payment modes offered by the Payment Aggregators Locked in with the Payment Aggregator

iFrame in merchant’s site: Merchants can embed the Payment Aggregators checkout page into the merchant’s website as an iFrame. Overall look of the page is in the merchant’s control except the iFrame part. Pros: Slightly better control on page look Cons: Cannot add multiple Payment Aggregators or add radio button for each Payment Aggregator.

C.

Merchant hosted page (Seamless): Payment page can be hosted by a merchant where the merchant will list the payment methods.

Pros • • •

Better control on page designs Flexibility to add multiple Payment Aggregators, banks, wallets etc. With routing logics, merchant can optimise performance and commercials

Cons • • •

Effort to maintain the page and manage routing logics Integration effort when new PSP is added Need to have card vault strategy to provide uniform user experience

Working of ‘Seamless Flow’

Each Payment Aggregator, wallet, and banks issue a unique MID for merchants. Each bank, wallet or Payment Aggregator also has unique code (e.g., bank code). So, with a combination of Live Id and Bank Code, merchants can route transactions.

Capturing card details in Seamless Flow

Card details (number, CVV2, expiry date) can be captured by PCI-DSS compliant entities. If merchant is using non-seamless (redirection) page or iFrame page of Payment Aggregator/TSP, then anyway cards are entered on Payment Aggregator/TSP’s pages. If merchant is PCI compliant then it can capture card details.

If the merchant is not PCI-DSS compliant and using seamless flow, then card details shouldn’t hit the merchant’s website or App. So, in this case, the Payment Aggregator/TSP provides iFrame elements that can be embedded in the merchant’s page to capture card details. Points to be considered while developing card capture page (merchant or PA) Do not allow non-numbers in card number, expiry date, CVV2 field Check card number length depending on card type (Visa, MasterCard, RuPay: 16, Amex: 15) Expiry date checks (months should be 1 to 12 and expiry date should not be older than present month) Length of CVV2/CVC2 (Visa, MasterCard, RuPay: 3 and Amex: 4) Implement Luhn’s algorithm or Mod10 check on card number to identify wrong card number. Closing Remarks

The best payment pages that you have seen (e.g., Amazon, Flipkart, Swiggy, Zomato etc.) took years of effort. So, payment pages are not static or can be done with one time effort but need to be refined and upgraded from time to time. 8.B Save Cards or Card Vault You might have noticed that many merchants give the option to ‘save the card, for future purchases. Card vault is important for a merchant because: Enables faster checkout experience

Success rate of transaction done with saved cards is higher than regular transactions If a customer has saved the card that means the customer will return to purchase and that indicates loyalty, repeat purchase possibility and higher LTV. a.

Do you want users to save their cards?: Just because there is a feature that doesn’t mean the merchant has to go for it. A merchant should consider a few points before enabling a ‘save card’ feature. Frequency of purchase: An insurance merchant has repeat payments but that is once a year, so it really doesn’t make sense to save a user’s card, but it is important for a food delivery App where users order frequently. Mobile App is dominant channel: Entering 16 digits card number every time on a mobile App is cumbersome so the ‘save card’ feature will help creating faster checkout experience Lock-in with one Payment Aggregator: Cards saved with a Payment Aggregator will be locked-in with that Payment Aggregator. So, in future if the merchant wants to integrate with another Payment Aggregator will face challenges with respect to unifying card vault. So, a merchant has to think whether it really needs to ‘vault’ user’s cards and then decide on strategy accordingly.

b.

Consent to save: There are no specific guidelines about taking customer’s consent before ‘saving card’, and this is purely a merchant’s business decision.

A merchant may seek consent from user to save card (little checkbox is shown with ‘save card’) and some merchants save card without explicit consent from customer (usually mentioned in the Terms of usage). c.

How to ‘Save Card’: Card is saved against a unique ‘user id’ (mobile number, mail id or unique customer id) and the user can store more than 1 card. So, every time the user comes to purchase, then all saved cards stored against that user id are shown. Note: As card vault is connected to a unique id that is why the ‘save card’ option is not shown when you login as ‘guest’ because ‘guest’ doesn’t have a unique Id.

d.

When to ‘save’: Typically, a card is saved only when the transaction is successful. It is possible for vaulting cards irrespective of the status of the transaction. But it is not a good idea to save the card details for unsuccessful transactions. This is the wrong method as a card with wrong credentials might get saved and a transaction done with that card will always fail.

e.

What is ‘Saved’ in the vault: Only card number and expiry date are saved. A repeat user needs to enter the CVV2 to proceed with the transaction.

f.

Ownership: The merchant owns the card data. Usually, Payment Aggregators do not cross expose one merchant’s card vault to others.

g.

Card Migration: Saved cards can be migrated from one PCI-DSS compliant entity to another PCI-DSS compliant entity based on the merchant’s instruction (remember… saved cards are a merchant’s property). But (definitely) the Payment Aggregator A who has vaulted the card will resist the migration to another Payment Aggregator B, even if the merchant is insisting on it, as Payment Aggregator A doesn’t wish to lose the lock-in on that merchant.

h.

Deletion of saved Card: Based on merchant’s request the Payment Aggregator and TSP can delete the card.

i.

Live Id & Card Vault: Card vault is linked to merchant’s Live Id. If a merchant has two Live Ids (e.g., A1234 & B6789) then saved cards at Live Id A1234 will not be shown LB6789. If a merchant has multiple Live Ids but requires a single card vault, then card vault should be merged for applicable Live IDs. Example: Ola has multiple Live Ids (depending on business line) but has a combined single vault. This is done to provide a uniform user experience because customers are storing cards on Ola App, and she doesn’t care about the underlying Live IDs, channels or business line.

j.

How to use ‘Save Cards’ in marketing/promotion campaigns: What does it mean when a customer saves a card? Ans: Customers have the

intention to come back again (and again) to make additional purchases and that means the lifetime value of such a customer is higher compared to the customer who didn’t save the card. So, merchants and banks can offer tailor made promotions for transactions done with saved cards or give extra incentive for users who save cards. Past and Present

At present, any PCI-DSS certified entity can vault the cards that means merchants, PAs, and TSPs apart from Issuing & Acquiring banks can save the cards. Below is the example of various entities that can save cards and pros-cons of that model.

A.

Merchant: A PCI-DSS compliant merchant can save the cards. (Refer: Screen A above) Pros

• •

No lock in with any Payment Aggregator or bank or TSP Better control on routing

Cons • •

Huge costs related to audits, insurance, resources Risk of saving card (remember, everything in payments is associated with risk)

Although this model is superior, it is extremely expensive. Think of it like having an elephant as a pet. It is an awesome feeling but extremely costly. B.

Payment Aggregators: All Payment Aggregators are PCI-DSS Certified entities and can provide card vault service to merchants. There are two different ways Payment Aggregator can enable card vault: 1.

Merchant Specific: A Payment Aggregator can save cards for each merchant separately. Basically, compartmentalize the card vault. So, card details are not cross exposed. (Refer Screen B1) In cases of re-direction (non-seamless) flow, customer is entering card details on Payment Aggregator’s page and vaulting is done by the PA. (Refer Screen B1 above) In seamless flow, the card is captured on merchant’s website/App. PA will give iframe elements to achieve this without need for a merchant to be PCI-DSS compliant.

2.

Common Checkout: Some of the Payment Aggregators and payment containers allow users to store cards and can be accessed (with login credentials) where they are enabled.

CC Avenue’s Checkout (Refer Screen B2) allows users to vault cards and can be accessed where CC Avenue Checkout is enabled. C.

TSP/Wrapper: These companies act as Wrapper over payment service providers including acquiring banks and Payment Aggregators. (Refer Screen C above) Pros

•

•

Cards are not locked in with any Payment Aggregator so merchant can use any Payment Aggregator/acquiring bank of its choice to process card transactions Merchant can enjoy benefits of card vault, but TSP will do PCI-DSS heavy lifting

Cons • •

TSPs may charge additional fees to merchant TSP will become single point of failure

Future

As per PA/PG guidelines of RBI, merchants, Payment Aggregators or even TSPs cannot save the cards. This guideline will be enforced from 1st Jan 2022. One of the alternatives is, ‘card tokenization’ - Basically cards will be tokenized at card network level. Although it is a good and secure solution, it is a time-consuming program as each issuing bank will have to implement it for all card schemes. That means the cards need to be saved in acquiring or issuing banks. So, all Payment Aggregators will be creating a vault at the Bank and store and fetch cards from that bank. 8.C Transactions

This is where the payments start. Different payment methods have different transaction flows and some of the payment methods can have different flavours of flows. A.

Cards (Credit, Debit and Prepaid)

Do not get overwhelmed by the complexities of the above flow diagram (trust me, it is much simplified than the actual flow!). Below is the summary of main steps: 1.

Customer enters card details (Card number, expiry, CVV2 and name on card (optional) and initiates the payments (through acquiring bank or Payment Aggregator).

2.

Directory Lookup: Visa/MasterCard directory will check the card and identify the issuing bank and ACS (Access Control Server) page of issuing bank is opened.

3.

Authentication: In this leg, ACS of the issuing bank will trigger OTP (One time Password) to the user via SMS and/or email. User to submit the OTP on ACS page.

4.

Authorization: Once the authentication is successful then issuing bank validates expiry date, CVV2 and, available credit or balance on card and risk checks on the card.

5.

Once both legs are completed then the status is communicated to the acquiring bank, Payment Aggregator, the merchant, and customer. Also, the transaction is ‘captured’ by the bank and fund movement (settlement process) will commence.

Flavours of card transaction:

1.

On-Us and Off-Us If the acquiring bank and issuing bank are different then the transaction flow is ‘Off-Us’ (Above Diagram). (e.g., ICICI credit card processed by HDFC acquiring bank) If Acquiring bank and Issuing Bank are same, then the transaction flow is ‘On-Us’ (Skip Step 4 in the above flow). (e.g., HDFC Credit card processed by HDFC acquiring bank)

2.

Direct OTP: Transaction is done without redirection to ACS page of the issuing bank.

The transaction has two legs (a) Triggering OTP: Merchant (Via PA or acquiring bank) triggers API to ACS of issuing bank to generate OTP Customer receives the OTP on registered number Customer enters OTP on Aggregator’s website or App

merchant’s

or

Payment

(b) Validating OTP: Merchant triggers second API to validate the OTP Once the OTP is validated (Authentication) successfully then authorization leg is completed, and transaction status is communicated to Payment Aggregator, merchant, and customer. 3.

Pre-Authorization: In this flow only authentication and authorization are completed but transaction is not captured. Basically, money will start moving only when a transaction is captured. The transaction is kept on hold for a time frame (maximum 5 days), then merchant can take two actions: Capture: Funds will be debited Void: Transaction is nullified If the merchant doesn’t take any ‘action’ within the time frame, then the transaction is automatically nullified. This feature is limited to only Visa, MasterCard, and Amex cards only. And doesn’t work consistently for many issuers.

4.

EMI Transactions: Credit Cards allow the user to convert the amount to an EMI (Equated Monthly Instalments) and this can be done while doing the transaction. Before starting the card transaction, the user is

prompted to select the tenure (3 months, 6 months, 12 months etc.). Although the EMI transaction is done in real-time, the EMI conversation happens offline (usually in 2-3 days). 5.

Debit Card + ATM PIN: For Debit cards of selected banks, instead of OTP or 3DS password, customers can complete transactions with ATM PIN. This flow was supported only by FSS. Note: As per PA/PG guidelines of RBI, this flow will be stopped due to higher risks.

B. Net-Banking

Customer is redirected to the bank’s online net-banking page to authenticate herself and complete the transactions. Different banks have different ways of validating the user. Along with Customer Id and password, customers may be posed with challenge steps such as entering grid number that is on back of the debit card, entering OTP or security question.

Net-Banking TPV Flow

This is like a regular net-banking transaction with a unique process. In this flow, the customer’s bank account number is validated against the one registered with the merchant. TPV (Third Party Validation) flow is mandatory for regulated investment (MF, stocks) use cases.

Basic: Customer’s bank account number that is registered with the merchant during customer on-boarding: Step 1: Merchant to pass the customer’s a/c number as part of payload data. Step 2: Customer is redirected to bank’s page and customer to complete the transaction. Step 3: Account number passed in payload data checked against the one that is used for the transaction. If yes, then the transaction is successful else marked as failed. Only 30+ banks support this feature through Payment Aggregators. C.

Wallets

A customer is redirected to the wallet’s page where the customer validates the credentials and completes the transaction.

Wallets also provide link and pay flow, where users can link the wallet with a simple one-time validation and then wallet balance will be shown on the merchant’s page and the wallet can be debited with a single click.

D. Payment Containers

Containers (PhonePe, AmazonPay) are something which combine wallet, cards, UPI under one user account. Customers can select the preferred payment method to complete the transaction.

Payment containers also facilitate P2P (Person to Peron) transfers on UPI (Refer Chapter 4E). E. UPI

P2p payment flows are covered in Chapter 4.E. – UPI. This section covers the transaction flow from merchant or customer’s point of view. There are two main flows: a.

Collect Flow:

Positives •

Works on all platforms (Website and mobile Apps).

Negatives • •

•

b.

Intent Flow:

User needs to enter the VPA: User may not remember the VPA or mistake while typing. Broken Flow: User needs to enter the VPA on the website and then open the App on the mobile to complete next steps. Lack of visibility: Merchant will not have any idea whether collect notification is received by the user and steps she is taking.

Positives • •

c.

Works on Android (Although Google Pay and PhonePe offer an open intent on iOS, but integration is App specific)

Negatives • • •

•

No need to enter the VPA App-to-App switch: seamless user experience Merchant will know whether the customer has a UPI App on the device or not (so little less darkness with respect to user’s actions) Yields better success rate compared to collect flow.

Other UPI Flows: In App Flow: wherein the ‘common library’ is opened within the merchant’s App. Google Pay’s omni-channel flow: Google Pay creates a UPI ID in this template (thanos.titan@okicici) but it is difficult to remember. So instead, you enter a mobile number, and it resolves the UPI ID attached to that mobile number and then proceeds with the UPI transaction flow- Super Cool!

Transaction Status:

In the ‘transaction’ leg both customer and merchant will know whether the transaction is successful or failed. There is a possibility that the transaction doesn’t end with a definite status (Success or fail) and goes into ‘pending’ status. In such cases, the Payment Aggregator will update its system (pull the latest status from the bank) and then push to updated status to the merchant or merchant can pull the latest status. (Called ‘status reconciliation’). Instant Gratification:

A definite transaction status (in real time or near real time) is important as both merchant and customer can take appropriate actions based on the

status. There are cases where a definite status after the stipulated time-period is of no use. Example: Airline has to know that status is successful (to issue tickets) or failed (to release inventory back). Airline cannot wait a long time for the status. To manage such a scenario, merchants can always ignore status that comes after a stipulated time-period (if status is failed then good enough, if status is “success”, then trigger auto-refund). Closing Remarks

Transaction is the first and most important leg of payment flow. It is important that transaction flow should be simpler so that users can complete it seamlessly in a shorter time. Also, transaction flow will impact the sales as it dictates the success rate (or sales). In next Chapters, I will cover different ways of transaction routing and, also ways to measuring as well optimizing success rate. 8.D Transaction Routing Many merchants partner with multiple payment aggregators, acquiring banks, wallets, and other PSPs (payment service providers) to: Increase payment coverage (more payment methods or banks). Avail better commercials on payment methods from different payment providers. Avail offers such as cash backs and discounts to boost sales. Most importantly, merchants can reduce dependency on single payment providers.

As they say, “do not put all your eggs in ONE basket”. It is good strategy but integrating with multiple payment service providers brings additional challenges, such as: Payment Page Design Unified card vault strategy Managing transaction routing Additional operation effort We have covered the first two points, so let’s jump to ‘managing transaction routing’. How do you route the transactions?

Before you set any routing logic, decide on what is the objective you wish to achieve: Backup/failover mechanism Better conversion or higher success rate Optimise cost by routing transaction through cheapest payment service provider. Fulfilling volume commitment (given to avail preferential rates from payment companies) Some of the possible transaction routing logics:

a.

Business Line Based: Merchants can configure different Payment Aggregators for different internal business lines or product lines. Example: (a) All B2C transactions go through one Payment Aggregator and B2B transactions processed through another Payment Aggregator. (b) Vehicle & travel insurance is processed through

Payment Aggregator A and health insurance through Payment Aggregator B. b.

Channel Based: Merchants can have channel wise routing for websites, m-Sites, mobile App. Example: All website transactions routed to Payment Aggregator A and all mobile App transactions to Payment Aggregator B.

c.

Primary and Retry: Payment Aggregator A acts as primary for all transactions and backup Payment Aggregator B is called in only when the user of failed transactions retries to make another payment.

d.

Performance Based: Measure the performance of Payment Aggregators and acquiring banks that are integrated and route the transaction through the gateway to whichever is performing better. Example: Start with 50:50 volume and based on performance make it 90:10 (keep 10% volume so you can measure performance of Payment Aggregator B). If Payment Aggregator A’s performance drops then start routing volumes to B till 10:90 split.

e.

Payment Method Based: Merchants can use different Payment Aggregators to process different payment methods. It can be done at various levels (broad or granular): Send All cards to Payment Aggregator A and net-banking to Payment Aggregator B. With net-banking, do bank level routing. With Cards, do granular level routing at card type (Credit, debit), card scheme (Visa, MasterCard, RuPay) and issuer level.

Reason: Different Payment Aggregators + acquiring banks tend to provide better success rate for a particular payment mode. (E.g., Payment Aggregator A may be good in RuPay, but other Payment Aggregators process other cards better). So, set the routing accordingly and keep trying different combinations until the optimal success rate is achieved. f.

Commercials Based: It is possible that one Payment Aggregator may provide better commercials on few payment methods compared to others. Also, it is possible to get differential pricing for On-Us and Off-Us transactions from acquiring banks/Payment Aggregators.

Example 1: Let us say the merchant has good commercials on credit cards, debit cards and ICICI net-banking from Payment Aggregator A. But has good rates from Payment Aggregator B for other banks of net-banking. Then the merchant can route the transactions accordingly. Example 2: On-Us Off transaction: Payment Aggregator/acquiring banks can provide differential rates for On-US Off transaction so route card transaction accordingly. g.

Volume Based: Transaction count based: Volume is split among Payment Aggregators based on transaction count (assuming ticket size is same). Typically works well if there is a 50:50 split between two Payment Aggregators but not ideal for complicated volume split cases. Example: If I need to send 20% volume to A, 30% to B and 50% C then 2 transactions to A, next 3 to B and next 5 to C and then start over again. But it requires additional logic to remember the last Payment Aggregator used and its count. Timer based: Build a timer—based logic that can use the current timestamp. As this model is built on probabilities, it works better (i.e., split is more accurate) if transactions are continuous and not sporadic. E.g., Works better for Swiggy but might not for Urban Ladder. Example: 5% of volume to A, 25% to B and 70% to C. In that case, take the current timestamp and perform mod 100 and if that number is less than 5 then send to A, if the number is less than 30 then send to B and the rest will go through C. Payment method wise split: Merchant knows the volume across various payment methods and route the transactions of the

payment modes in a way to fulfil the volume commitment. Example: Visa Cards and net-banking constitute 50% of volume. So, if volume is to split 50:50 between Payment Aggregators then route all Visa Cards and net-banking through Payment Aggregator A and rest of the payment modes through Payment Aggregator B. Important Note: Irrespective of what routing logic you develop, make sure for every payment method you configure a primary and secondary Payment Aggregator/acquiring bank so that you have a fail-safe mechanism in place. Closing Remarks

Performance based logics are based on the hypothesis that as ‘n-1’ transaction was successful on Payment Aggregator A so transaction ’n’ will be successful. Think about it. Routing logic is not a sprint but a marathon, one has to keep fine tuning with various combinations until you achieve the objective and that too consistently. 8.E Understanding Success rate ‘Success Rate’ is the most important parameter that every merchant is interested in. During every sales pitch, the merchant asks questions on this, and every salesperson jumps in with the answer ‘we are the best in the industry’! There are various ways a success rate is measured. The numerator always remains the same (i.e., successful transactions) but the denominator can be, Total transactions initiated by the merchant. Total transactions received by Payment Aggregator.

In an ideal world, both these numbers will be the same, however, we don’t live in an ideal world. But for the sake of simplicity, we will go ahead with the assumption that both numbers are same. Some merchants may remove user related failures (e.g., user cancellations or user mistakes) from calculation. The logic is: why should a Payment Aggregator be held responsible for a user’s mistakes or lack of intent of proceeding with payment? Fair enough, but things become complicated when you are not sure whether a user dropped out because the user does not want to proceed further with payment (intent of payment) or the user is not able to proceed further (e.g., technical glitch - say, blank page). Also, more logical merchants remove the failures that a Payment Aggregator couldn’t fix. Example: If NPCI is down then it is not a problem of a Payment Aggregator or PSP. If SBI net-banking is down, then it doesn’t matter which Payment Aggregator is used for transaction processing. Measurement

It is important to set the formula and assumptions before starting to measure the success rates. Success rate can be measured on various levels and combinations: Channel (website, mobile App) Overall (across all payment modes) Payment group (card, net-banking) Card type (Credit Card, Debit Card) Card scheme (Visa, MasterCard, RuPay etc.),

Bank Level: Issuing bank (HDFC, ICICI), net-banking banks (SBI, Canara etc.),

Typically, a combination of all the levels is used to measure success rate (e.g., Visa debit cards of SBI on Android App) How much does success rate matter?

Example A: 100 users did transactions, but 20 transactions failed. So, what is the success rate? Straight forward, Success rate = 80%…. right? View 1: Vodafone ‘post-paid’ customer has to pay the bill before the due date. Let us say those 20 failed transaction customers paid the bill within a week. So, what is the success rate now… 80% or 100%? View 2: On Flipkart, out of those 20 failed transactions, 10 customers may not come back to buy or buy from another site. So, is the success rate 80% or 90%? Example B: A customer tried to make payment and failed 4 times but finally succeeded. So, what is the success rate here? 20% or 100%

Merchant didn’t lose ‘sale’ as the customer paid anyway. Also, it is possible that the first 4 times the transaction failed as the customer had entered the wrong expiry date. Remember two things:

What does success rate stand for your business: loss of revenue or just inconvenience? Whom do you hold responsible for the success rate (payment service provider, customer, or yourself i.e., merchant) Some cases that will give insights on success rate.

A.

High End Fashion Vs. Generic eCommerce: A high-end fashion apparel merchant might have a better success rate than generic eCommerce marketplace. High end fashion apparel merchants have an urban customer base with better data connectivity (Wi-fi), but the eCommerce marketplace’s customers are spread across tier 2, 3 & 4 towns where data strength can be weak. Learning: Demography and users’ environment counts.

B.

Food Vs Travel: A food ordering merchant will witness a better success rate than a travel portal. Because the intent of purchase is higher for food order, but a user might have opened 3 travel portals and must be checking discounts and finally buys in one place (drops in other two) or defers purchase. Learning: Watch out for user cancelled cases or intent of purchase.

C.

Insurance Vs. eCommerce: Success rate is not as important for Insurance merchants as much as for an eCommerce company. An insurance merchant knows that the customer will try again as she

wants to purchase the policy, but eCommerce merchants fear that customer will defer the purchase. Learning: Value of success rate varies from business to business. D. Confusion in checkout flow or offers: A major eCommerce merchant complained about the bad success rate on SBI net-banking. Upon analysis, we realised that the merchant was running an offer on SBI Cards, but users were confused with the offer, and they were clicking SBI net-banking page and then cancelling transactions. Learning: Checkout pages should handle promotions with better flows and messages. E.

Do not compare apples to oranges: A merchant referred to a dashboard of Payment Aggregator and complained that our success rate is 10% lower compared to our competition’s success rate. On detailed analysis, we realised that the competition was not including user aborted cases while calculating the success rate so obviously the success rate was looking better. Learning: Use the same formula for all payment service providers (do your calculation rather than relying on service provider’s dashboards).

F.

RuPay Vs. Visa or Canara Bank Vs. ICICI Bank: One of my merchants keeps coming back complaining that success rates on RuPay transactions are not great compared to Visa or MasterCard. It is a simple case that RuPay infrastructure is not as robust as Visa/MasterCard infrastructure so in general, RuPay success rates will be lower. Similarly, in net-banking the success rate of Canara Bank will be lower than ICICI bank.

Learning: Have right expectations from payment methods. G. When Issuing Bank is down: Once, the success rate on a particular issuing bank dropped. I received a call from a merchant that performance-based routing configured by us is not working but the merchant failed to see that if the issuing bank is down then it doesn’t matter which acquiring bank we use. If ICICI issuer is down, then it doesn’t matter whether you use BillDesk or IMSL. Similarly, if SBI net-banking is down then irrespective of the Payment Aggregator you use, transactions will fail Learning: Sometimes waiting is the only option or alternatively, you can proactively put a message about bank downtime so user can proceed with different payment instruments. H. Website Vs. Mobile: Success rate on websites varies from that on mobile. Reasons may include, the website may be for discovery, but payment happens on mobile or vice versa. Website transactions happen on Wi-Fi compared to mobile transactions that may have problems with data connectivity. Learning: Success rate will vary from channel to channel for various reasons. I.

Count… Counts: Out of 2 transactions, if 1 fails then the success rate will be 50%… too bad. But if you take 100 transactions and 10 fails then the success rate will be 90%. Learning: More the data pointers (‘statistically significant’), more accurate will be calculation.

Closing Remarks

I have come across merchants who have asked questions such as ‘can you guarantee a 90% success rate?’ or ‘can you improve the success rate of RuPay cards by 10%?’. Such questions don’t make sense but below is the answer: Payment ecosystem involves various entities and actors just like how a car has various moving parts. Whenever there are multiple moving parts, every part becomes a potential point of failure. Along with technology, bank and processor integrations, the intent of purchase, ease of payment, user base, user environment and checkout flows play vital roles in achieving a better success rate. The goal is to improve the success rate and both Payment Aggregators and merchants can take a few steps to improve the success rate. Refer next Chapter! 8.F How to improve Success Rate Success rate is important as the merchant wants every user to complete the transaction in the first attempt as it not only impacts the sales but also the user experience. Here are some of the things that a merchant and a Payment Aggregator can implement to improve conversion rate: A.

System Uptime: Basic expectation and goal should be 100% (or near 100%) system uptime for Payment Aggregator/payment service providers. It is easier said than done. No system in the world guarantees 100% uptime (including AWS, Google). So be practical! Payment Aggregators should have the ability to handle spikes of transactions (generally that happens during flash sales). Also, Payment Aggregators should have business continuity plan in place.

B.

Bank Integration: As a merchant, make sure the Payment Aggregator provides you with a better acquiring bank and payment gateway combination as it plays a crucial role in the success rate of cards. Note: Payment Aggregator has back-to-back costs with acquiring banks and will be able to enable the best acquiring bank provided the commercials with merchant permits.

C.

Performance Based Routing: A merchant can integrate two Payment Aggregators or acquiring banks and set-up performance-based routing. (As covered in earlier sub-chapter) Note: Sometimes the commercials with merchants won’t allow Payment Aggregator to provide two best performing acquiring banks.

D. Smart Routing: Implement clever routings such as On-Us, BIN based routing based on historic performance. Typically, the On-Us transaction provides a better success rate and some BIN/Banks/Scheme work better on a particular acquiring bank. Identify these patterns and set the routing logic accordingly. Note: Do not assume such routing works all the time. If ICICI issuer is not performing well then it doesn’t matter which acquiring bank or processor is used for the transaction. E.

Bank Alerts: There are two types of downtimes: Scheduled and unscheduled. Payment Aggregators should have mechanisms to alert/inform merchants about downtimes proactively. So, merchants can show the downtime alert in the checkout page and customers may use different payment methods to complete the transaction. At times, a particular payment mode or bank may not be performing optimally so identify the low performance and inform the merchant. If

the merchant can show it on the payment page, then the customer may opt to choose a different payment method to complete the transaction. Example: ICICI NB success rate is 70% but if you are observing a success rate of 50% then display the alert on the payment page that ‘bank is not performing at optimal level, either continue or change payment method’. F.

Retry Option: Show the retry page for failed transactions so that customers can change payment instruments to complete the transaction. Be Smart: Instead of a standard retry page, show the best alternative payment method to complete the transaction. Example: If the netbanking option is failed then show the UPI or debit card option or BNPL option.

G. Save Card: Success rate of transactions done using saved cards is higher than regular transactions. If you have the relevant business case then save the card with a PCI-DSS certified entity (merchant, Payment Aggregator, TSP, or bank). H. Alternate Transaction Flows: Direct OTP: Implement direct OTP flow on selected banks. Considering it has less/no redirections, the success rate is better than standard card flow. Intent Flow for UPI: Implement intent flow on Android where customer doesn’t have to enter VPA but on clicking UPI, all installed UPI PSP Apps are shown to the customer to complete the transaction. ‘Link and Pay’ for wallet: Wallets provide link and pay features where customers can link the wallet one-time (using wallet

credentials) and then wallet balance is shown to the customer. Based on balance either customer will continue to pay or add money to the wallet or change payment method. With this flow, user dropout related to low balance can be reduced drastically. CVV less flow: On CyberSource PG, CVV2 is checked if it is passed in payload data else it is not validated. So, you can build flow without CVV2, and this will boost success rate by a few basis points (bps). But the problem is users will expect that CVV2 to be validated but if someone observes that CVV2 is not getting validated then bug bounty hunters will keep bugging you. I would recommend you avoid it. I.

Optimise mobile transactions: Mobile transactions are tedious especially with respect to card transactions (entering OTP) and netbanking transactions (pages are not optimised for mobile screens). Integrate SDKs that auto-read OTP and optimise bank pages to enable seamless user experience and better success rate. Such SDKs are provided by Payment Aggregators as value added service and by TSPs such as Juspay and DreamPay.

J.

UPI Success Rate: UPI is one of the most popular payment instruments. Here are some steps/processes merchants, Payment Aggregators or acquiring banks can follow to improve the success rate. 1.

General: Use multiple acquiring banks to do smart/dynamic routing based on performance and availability. Be Proactive: If the issuer or switch is having issues (performance degradation or downtime) then display

appropriate warning messages so the customer can choose an alternate payment method. 2.

Collect Flow: Validate the UPI ID/VPA before initiating the payment (remove @google.com or @upi.com handles, spell check @okhfc — don’t allow user to press ‘PAY’ button until such obvious mistakes are corrected (like how you do BIN check or run Luhn’s algorithm on card number). On the website, include dynamic UPI QR code so the user doesn’t have to type VPA and just scan UPI QR Code. Save VPA/UPI ID of successful transactions (so customer doesn’t have to enter every time). Reduce typing requirement: Allow customer to select App first then based on App selection and user information (e.g.: Mobile number and mail id), populate the VPA (e.g., if customer selects PhonePe then populate VPA as 9192939495@ybl). Use G Pay’s mobile number-based flow (to avoid typing of VPA in case of G Pay). Show a timer expiry (how much time is left before the collect request expires) — Don’t we all work faster and efficiently when we are closer to the deadline… shoosh!!! Utilise the wait page to educate the customer (highlight next steps: you will receive notification on your XYZ App, open App, enter PIN etc…etc.)

3.

Intent Flow: Implement intent flow for mobile App (It has a higher success rate than collect.)

Show only better performing Apps (hide others). If you only want to show top 2–3 Apps, then have a placeholder to enter VPA so that the user who uses a nonpopular App can initiate ‘collect’ request. Implement intent flows offered by G Pay and PhonePe That sounds simple… Right?

No, it is not. To implement these measures, one has to consider cost, integration efforts, system limitations and operations efforts. In summary, there is effort and cost associated with improving success rate. So, unless you know the value of that number (success rate), you cannot put a price on it. And if you know the true value of that number (Success rate) then you won’t mind spending some extra money and effort to improve it! 8.G Integration Final notes We touched upon important aspects of the integration, so here is the summary: A.

Payment Page: We have already covered different types of payment pages (Chapter 8.A.) and pros & cons of those. So, depending on your use case, decide on the payment page - either the redirection page, iFrame or seamless. Think of an overall checkout experience that should be frictionless in terms of positioning of payment methods and shouldn’t confuse customers. If adding coupons, then make sure coupons are easily accessible as part of the flow.

B.

Payment Coverage: How many Payment Aggregators, acquiring banks, wallets do you need to have optimal coverage of payment methods? Do not add a payment method just because it is available in the market. Example: If you are an eCommerce merchant with smaller ticket size then you won’t need EMI on cards but if you are selling airline tickets then EMI will be a good sales booster.

C.

Flavours of Payment Flows: In Chapter 8.C - Transactions, we touched upon various flavours of card, wallet transactions. So, decide on payment flows needed For Cards: Standard card flow or direct OTP flow In case of wallets, standard re-direction flow or link & Pay flow For UPI: Intent flow if you have more transactions on mobile App Multiple flow means, you should be ready to do multiple integrations.

D. API Needed: Check on APIs required to be implemented that fits your payment page strategy: For ‘redirection page’, merchant has to implement minimal APIs For ‘seamless flow’ and ‘card vault’, merchant has to implement additional APIs such as Transaction with add card, transaction without adding card, transaction using stored card. APIs of different Payment Aggregators, payment providers have different parameters, some are mandatory, and some are optional (e.g., mobile number of the customer). Similarly, response codes and error codes also vary from PA to PA. So, the merchant should develop capabilities to handle all API calls uniformly. E.

Card Vault Strategy:

Do you want to save cards? Think about whether you have genuine use case to vault customer’s cards. If not, then avoid it as you may get locked-in with one Payment Aggregator. If you are vaulting card, then with whom? In Chapter 8.B – Save Cards or Card Vault, I have covered about various entities (merchant, Payment Aggregator, TSP) that can vault card and pros and cons of each model. But be mindful that card vaulting will be changed by end of Dec’21. So, plan your strategy based on present and future scenarios. F.

Routing Logics: Set your objective and define the routing logic accordingly. We have touched upon various types of routing logics in Chapter 8.D. Keep fine tuning the routing logic till you consistently achieve better results.

G. Operations: Settlement Reconciliation: Every new payment service provider will give you a new set of settlement files. So more the payment providers then more files. Your finance team will not be happy handling so many files. Think of automating settlement reconciliation. Refund and Chargeback Management: More payment providers and more complex routing means, you need the capability to remember through which payment provider transaction is done and you need to mark refunds against the same payment provider. As chargebacks are managed over mails so need system to manage chargebacks of multiple parties efficiently.

Dashboards: Every payment service provider will give a dashboard. So, if you have 5 payment service providers then you will end up looking at 5 dashboards. You will have to think of unifying the dashboard. Consider below points while changing your existing Payment Aggregator:

While you change your existing Payment Aggregator, do factor in ‘switching cost’. And switching cost can be direct (additional MDR) or indirect (Development effort required for the integration or on-going operational effort). Along with the above points, do factor in below mentioned points while switching: 1.

Card Vault: If you have vaulted your customer’s card with Payment Aggregator A then while switching to Payment Aggregator B, you need to migrate the vaulted cards as well. Because your customers will panic if they do not see their vaulted cards. Although PCI-DSS guidelines allow migration of cards from one PCI-DSS certified entity to another PCI-DSS certified entity, expect some resistance from your existing Payment Aggregator. But remember, the customer card vault is yours. Here are some options: Start afresh (check total vaulted cards, active users and expired cards and decide whether you want to migrate or start afresh). Use Payment Aggregator A to process already saved cards and save new cards to your own vault or TSP’s vault. (Bad move!)

2.

Refund Management: If Transaction is processed using Payment Aggregator A and you remove it later. You cannot mark refunds and even if you can mark refunds through the dashboard then the earlier

Payment Aggregator cannot process refunds as there are no settlements to adjust. Alternative: Transfer funds to Payment Aggregator’s nodal/escrow a/c for manual processing. 3.

Chargeback Management: If a chargeback is raised, then the merchant needs to respond on a timely basis. Just because a merchant has plugged off a Payment Aggregator doesn’t mean the merchant’s obligations are over. If Payment Aggregator loses money because of chargebacks, then they can very well send court notices to merchants. Alternative: Defend chargeback with valid proof or deposit funds to Payment Aggregator’s account for valid chargeback cases.

Closing Remarks

Every design and every flow contribute towards a seamless user journey and better performance as well as higher success rate. The best pages and flows (Swiggy, Flipkart or Amazon) are not implemented in a week or a month but took years to reach where they are today. So, you can start working on it right now, to achieve it over a period.

Chapter 9

Payment Aggregator – Operations

In the next few chapters, we will cover the operational aspects of the payments such as settlement, refunds, and chargeback. 9.A Settlement Time The main purpose of online payments is getting ‘money’ from customers. So ‘settlement’ is a crucial part of the payment cycle. Let’s assume the transaction was successful, so, when will the merchant get the money and how much? In this Chapter, let us touch upon settlement time followed by Payment Aggregators. Three factors affect settlement time 1.

Type of merchant

Just because a transaction is successful in real-time, doesn’t mean the Payment Aggregator will receive the funds immediately. Banks, wallets, or other payment service providers need different time durations to give settlement to the Payment Aggregator which in turn will take time to give settlement to the merchant. So standard settlement time can be T+1 or T+2 working days with exception of certain sectors such as Mutual Fund investment.

A risk averse Payment Aggregator will wait till it receives funds from its partners (banks, wallets etc.) and then do the settlement to the merchants. Reconciliation:

Imagine you and your friends go out for dinner. At the end, the bill comes to your table and one of your friends checks whether the bill amount is correct based on orders you placed. If both are matching, then ‘reconciliation’ is successful else you ‘call the manager’ for corrections. The exact same process is followed by a Payment Aggregator as well. A Payment Aggregator reconciles the amount that needs to be received for successful transactions Vs. total amount received by banks. And then total success transactions of merchants are checked, and corresponding amounts are settled. (After factoring adjustment for refunds). Considering a Payment Aggregator works with 45+ banks and lakhs of merchants, reconciliation is a time-consuming process. Fund Movement:

Issuing bank moves money to acquiring bank and acquiring bank will move the money to Payment Aggregator, only then Payment Aggregator can

settle to merchant. For net-banking & wallets: The bank or wallet company will move money to the Payment Aggregator. As Payment Aggregators work with multiple banks, funds start moving into the Payment Aggregator’s account at different times on T+1 day. Post that the Payment Aggregator will do reconciliation and then do settlement to merchants. 2.

T Count

In the ‘payments world’, days are always working days (as per RBI list). So that means there won’t be any settlement on 2nd & 4th Saturdays, Sundays, Bank holidays (as per RBI List). 3.

Transaction time

Different banks have different transaction cut off times. So, any transaction done after the cut-off will move to the next settlement batch. (Below example)

Illustration of Settlement Time:

Let us assume, the settlement time is T+2 days then this is how settlement cycle looks:

In the next chapter, I will cover how Payment Aggregators are reducing the settlement time. 9.B Early Settlement Standard settlement time can be T+1 or T+2 working days. But what if the merchant wants settlement earlier than that? Or maybe on a bank holiday? Before we get into merchant’s requirement, let’s answer important question: Why does a merchant wants an early settlement? Answer: For fulfilment of financial obligations — a hyperlocal merchant wants to make payments to its vendors; a gaming merchant wants to disburse winnings to its users while an NBFC will use those funds to issue loan to more customers. Sure, a merchant can use its own funds to complete these obligations, but a merchant may not have that kind of liquid funds and there is an opportunity cost for using own funds. How to address merchant’s early settlement requirement?

This seems like a deadlock — merchants want funds earlier, but banks won’t give it faster. In that case the solution is that the Payment Aggregator can settle the funds to the merchant in advance and then recover it from the merchant’s settlement amount later.

Below are the details related to early/instant/faster settlement: A.

Settlement Type: Merchants want early settlement, but that definition can vary a lot… It can be periodical (every 1 hour or once every 6 hour) or on-demand (only when needed - E.g., only on Sundays)

B.

Fund Source: The Payment Aggregator needs to pre-fund these early settlements. Payment Aggregator has two options: Use own funds — Technically cannot be done as Payment Aggregator is not a licensed lender. But yes, Payment Aggregator can do it, but such method is neither clean nor scalable. Borrow funds from an NBFC or Bank and repay it back (Clean and scalable model).

C.

Underwriting: As you realised, early settlement is nothing but unsecured lending. But who is the borrower in this model? Payment Aggregator or the merchant? Usually, the Payment Aggregator will be the borrower on the file — NBFC or Bank will issue the loan to the Payment Aggregator who in turn uses it for pre-funding for early settlement. Although a merchant is not the direct borrower, NBFC or Bank may put restrictions in terms of merchant categories (e.g., gaming not allowed) or put a limit on the amount Risk of lending in the early settlement model is low because Payment Aggregator is settling the funds for successful transactions. So anyway, the Payment Aggregator will receive funds from the bank/payment processor on next working day and amount can be recovered.

D. Commercial Model: The NBFC/Bank will have interest charges that may vary from 12–18% per year (or 0.032%-0.049% per day). The Payment Aggregator will recover it from the merchant and by adding some margin, the Payment Aggregator will make profit.

In the above example: Let’s say there were two transactions of Rs. 10,000 each done using credit card and debit card. PG charges for CC is 1.80% and DC is 0.90%. The merchant is availing early settlement at 0.10% charges. Payment Aggregator can make ‘good margin’ on early settlement. Let’s make it complex

Above calculation looks quite straight forward but it is not. Let’s assume a merchant is availing early settlement at 0.10% and the Payment Aggregator’s borrowing rate is 0.05%. Let’s also assume that the transaction is done on Friday and assume Saturday & Sunday are bank holidays. The merchant receives the settlement on Friday. But the Payment Aggregator can recover that amount only on Monday when banks do the settlement. In the above example, the Payment Aggregator will charge merchant Rs. 10 but NBFC will charge Payment Aggregator Rs. 15 for the same amount. So, the charges for such early settlement cannot be linear and at the same time, you cannot show complex calculations to the merchant. A simpler way to avoid any revenue leakage would be having differential pricing on working and non-working days. Let’s make it efficient

Why does the merchant want funds faster? It’s because the merchant has financial obligations to fulfil (e.g., paying to vendors or disbursing funds to the winners).

A merchant can simply connect the settlement to a payout account (source account for the payout/disbursement solution) and disburse the funds. Closing Remarks

I wrote about the Payment Aggregator’s revenue model in Chapter 8.C. These revenue models keep changing or evolving. Example: Reverse plough from banks is not available since January 2020 after GOI revised rates for RuPay debit cards and UPI. But there is a new revenue stream i.e., early settlement charges. Payment aggregation business is more or less a commodity. Payment Aggregators hardly make any profit (if they make at all). Additional services such as early settlement can improve the ‘top line’ and, also there is ample opportunity to make good margin on early settlement fees. In the above example, if you assume a standard borrowing rate of 15% per year (i.e., 0.04% per day) but early settlement fee is 0.10%. So, PA is making a profit of 0.06% (roughly). If you can lower the borrowing rate but charge a higher early settlement fee, then profits will go high.

Do not look at it from the lens of payments but from lending. In fact, it is a sort of embedded finance, a part of Banking as a Service. (Refer to Chapter 19 – BaaS). 9.C Settlement Amount In the earlier chapters, we covered ‘WHEN’ merchant will receive the money and, in this section, let’s talk about ‘HOW MUCH’ After ‘reconciliation’, Payment Aggregator settles funds to merchant’s account. Settlement amount depends on the commercial model the merchant is configured (Upfront deduction, Surcharge, and Invoicing - Refer Chapter 7.B - Commercial Models). Also, refund amount and chargeback amount are recovered from the merchant’s settlement amount. Example: Transaction Amount: Rs. 1000, MDR: 1%, GST: 18%, Refund Adjustment: Rs. 50 1.

Upfront Deduction Model: Settlement Amount = Transaction amount (-) PG Charges (-) GST Amount (-) Refund adjustment (-) Chargeback Amount Recovered Settlement Amount = Rs. 1000 (-) Rs. 10 (-) Rs. 1.80 (-) Rs. 50 = Rs. 938.2

2.

Surcharge Model: Settlement Amount = Transaction Amount (-) Refund adjustment (-) Chargeback Amount Recovered Settlement Amount = Rs. 1000 (-) Rs. 50 = Rs. 950 Note: PG charges + GST is borne by user so it’s not part of settlement calculation

3.

Invoicing Model: Settlement Amount = Transaction amount (-) Refund adjustment (-) Chargeback Amount Recovered Settlement Amount = Rs. 1000 (-) Rs. 50 = Rs. 950 Note: PG Charges + GST is invoiced to merchant so it’s not part of settlement calculation.

Settlement Reports: Payment Aggregators share settlement reports that cover settlements and refunds adjusted for a particular day. The file format will vary for different Payment Aggregators and reports can be delivered through mail or dashboard or APIs. UTR: UTR (Unique Transaction Reference) number generated for the settlement is shared with the merchant for easier reconciliation 9.D Settlement - Account In the earlier chapters, we covered settlement time and amount, now let’s talk about the settlement account. Merchants can receive the settlement to the Current, Nodal or Escrow account. The account details are shared during merchant on-boarding. 1.

Single Account Settlement: A Payment Aggregator can do settlement to any account that merchant holds in any bank (that has IFSC). The account is mapped to the merchant’s Live ID (MID).

2.

Multi-Account Settlement: What if merchant wants to settle funds to different accounts based on business models? Example: Car Company’s App allows customer to select the dealer and make payment towards the service provisioned by the dealer. The funds should be directly settled to selected dealer’s a/c.

This can be achieved in two ways Assign separate Live Id for each dealer. And pass the appropriate Live Id that is meant for the selected dealer. Funds will be settled to the account that is configured for that Live Id. Create special fields or scheme codes or split codes for each dealer and link to the dealer’s bank account. During transactions, pass the appropriate code and settlement will be done to the corresponding bank account.

Important point to consider: If you are enabling multi-account settlement with scheme/special field integration then make sure refunds are supported for that flow, else refunds of one scheme (business unit/dealer) will end up getting adjusted from settlement of different schemes (business unit/dealer).

3.

Split Settlement: In this scenario, the merchant wants to split the transaction amount and then would want settlement in different bank accounts depending on certain conditions. Example: An education institute is collecting 2 types of fees (Admin Fee and Course Fee) but would like the Payment Aggregator to settle funds into 2 different accounts.

For such use cases, split settlement solutions are ideal. Let the merchant pass various fee headers as part of payload data and then depending on fee headers, split the amount and do settlement to respective bank accounts.

Split settlement can be done for eCommerce marketplace models (settling funds to vendors after splitting marketplace’s commission) Like the multi-account settlement model, remember to provision for clean settlement (factor in refund processing from right header) for split settlement as well. 9.E Refunds Refunds are an essential part of online business. We cancel tickets or hotel bookings, we return products. I think refunds have played a great role in the growth of online commerce as they instilled confidence in users. Refunds can be marked only against successful transactions. Merchants can either mark full or partial refund. Full Refund: Entire transaction amount is refunded. (E.g., Rs. 1000 is transaction amount then entire amount is refunded). Partial Refund: Only part of the transaction amount is refunded. It is possible that merchant can mark multiple partial refunds against the same transaction. (E.g., Rs. 1000 is transaction amount then merchant can mark refund of Rs. 200 and Rs. 300 (so on) as long as sum of these partial refunds doesn’t not exceed Rs. 1000). Merchant can mark refund multiple ways:

Refund API (single refund or bulk refund-multiple refunds) Mark refund in admin module File upload (mark multiple refunds in one go) in admin module Refund Process

1.

Refunds should be marked for successful transactions.

2.

Refund amount or sum of partial refunds should not be more than transaction amount. Example: Transaction Amount = 1000 then 1st partial refund = 500, 2nd Partial Refund = 300 and if merchant marks another refund for 300 then 3rd refund should fail.

3.

Duplicate refund should not be processed. To achieve this every refund done should have unique id with status check.

4.

Merchant should have sufficient settlement amount to adjust the refund amount.

5.

In case refund is failed due to insufficient settlement amount (for adjustment) then retry for couple of days.

6.

Alternate provision to process refund in case of insufficient settlement amount (a) Mark negative entry in ledger and recover the refund amount later (b) allow merchant to transfer funds to Payment Aggregator’s nodal/escrow account to process pending refunds.

In general, refunds are cumbersome and costly. Read further to know more. A.

Refund Flow

During refund, the money traces back to its source through a series of identifiers that were created during the transaction leg and returned to the customer’s card/account/wallet. Once the merchant marks a refund then the Payment Aggregator processes it on the next working day. Note: Most of the Payment Aggregators do not support marking of refund through API/dashboard for the transaction that is older than 6 months. For such cases, merchants have to communicate with Payment Aggregators directly. Refund Status: Once Payment Aggregator processes the refunds then status will be ‘success’ or ‘failed’. But this status doesn’t indicate the money reached the customer’s account or card but simply conveys that refund process has commenced successfully. TAT (Turn Around Time): As the money hops across different accounts (of Payment Aggregator, of acquiring banks, issuing banks), it takes time to reach the customer’s card or account. Typically, it takes 1-5 days depending on payment mode. Tracking: An anxious customer wishes to know the status of the refund. For such cases, merchants can share ARN (for cards, that is generated when acquiring bank processes refunds successfully) or bank reference id (for NetBanking). These reference numbers can be used by customers to check the status of refund with their respective banks. B. So, refunds are cumbersome… but why costly?

Payment Aggregator doesn’t charge any fee to process refunds (in standard model) but still the merchant or the customer will lose money. Example 1: Merchant is in upfront deduction model (i.e.: MDR is deducted from settlement amount. Transaction Amount Rs. 100, PG Charge: 1% so Settlement Amount = Rs. 98.82 When a customer asks for a refund, the customer needs to get Rs. 100 but the merchant has received only Rs. 98.82 (Rs. 1.18 was taken away by the Payment Aggregator). So, the merchant needs to put Rs. 1.18 from its pocket. Example 2: Merchant is in invoicing model (Meaning: Merchant bears the MDR charges but invoiced on monthly basis). This works the same as the upfront model; merchants will lose money. Example 3: Merchant is in Surcharge Model (Meaning: MDR is passed on to the customer). Transaction Amount = 100, PG Charge 1% so total amount will be 101.18. But merchants can mark only Rs. 100 as refund (any amount higher will be more than transaction amount) so the customer receives only Rs. 100 and surcharge collected by the Payment Aggregator won’t be refunded. Customer loses money in this model. Auto-Refunds

These are not actual refunds but important to cover in this Chapter. These are the cases where merchants will ask Payment Aggregators to mark the refund if transaction status is not definite (Success or failed) within the stipulated time-period.

Example: Airline which wants to auto-refund configured post 15mins. Transaction status became successful after 30 mins and the Payment Aggregator marks it as ‘auto-refund’.

But from the acquiring bank’s point of view, the transaction was successful, and it will deduct charges. As there is no settlement so the Payment Aggregator cannot recover it from the merchant. In this case the Payment Aggregator loses money. (This happens because acquiring banks do netsettlement to Payment Aggregator). Can refunds be done faster?

IMPS, NEFT, Visa Direct and MasterCard Money Send rails can be used to push money to cards and/or bank accounts. To implement these methods, one would need a card number and account number (and IFSC). These solutions involve additional charges. But the biggest problem is these solutions leave room to raise chargeback as the forward journey is different from the refund journey. Such gaps can be exploited. So, the merchant has to make sure both the legs of fund flows are connected so can show it as proof during disputes. Closing Remarks

Refunds are important for many merchants (eCommerce, Travel, Insurance etc.). Although there are great improvements done on the transaction side, refunds still suffer from many inefficiencies. Alternative solutions are not completely fool proof, have limited coverage and add additional costs. Although, RBI has mandated certain fixed timelines for completing refunds, but it is not easy to implement as the entire ecosystem needs to be prepared to achieve such a model and we are not there yet! 9.F Curious Case of Chargebacks The interesting thing about chargeback is ‘nothing’. Chargebacks are kind of boring, merchants do not like them, Payment Aggregators despise them, but chargebacks are important as they safeguard the cardholders. Chargeback is a dispute raised by a cardholder with her issuing bank. A user can raise dispute under three circumstances: Service Related: Merchant fails to provide produce/service and refuses the refund. Technical: Amount was debited twice or over debited. Suspected fraudulent cases. Chargeback Process

Chargeback raised by the customer with her issuing bank reaches merchants through the Acquiring bank and then Payment Aggregator.

Handling Chargeback

Although the entire chargeback process can be for 21 days but post receiving the chargeback intimation, the merchant will have 4–5 days to respond to the chargeback. There are two possible responses for the chargeback: Accept: It is a valid chargeback, acquiring bank recovers funds from Payment Aggregator and Payment Aggregator will adjust the amount from the merchant’s next settlement. Customer receives the money. Reject: Merchant provides information (proofs) that service provisioning is done as per terms or refund is given to customer. If issuing bank accepts it as valid proof, then merchant won’t lose money and customer won’t get money. Important Points: If a merchant doesn’t reply within a stipulated time-period, then such chargeback is considered as valid chargeback. (Meaning: Customer receives the money) Merchant should not accept chargeback when the refund is already initiated.

Issuing bank won’t accept the information provided by the merchant blindly and if the bank thinks that ‘proof ’ is not sufficient then chargeback case will go into a second ‘presentment’ and the merchant will have to submit more proof to defend the chargeback. Importance of Chargeback

a.

For a merchant: Number of chargebacks raised against a merchant shows the health of that merchant’s business. It is important for merchants to keep chargebacks within specified limits. If chargebacks are higher than normal, then merchants will be on the radar of Acquiring Bank and card schemes. An acquiring bank may take a decision to revoke the MID (Merchant Id). So, merchant has to take a few steps to reduce chargebacks: Better service provisioning Keep logs of transaction and proof of service provisioning (for 13 months) Show clear Terms & Conditions, refund policies, cancellation policies on website/App Consult your Payment Aggregator/acquiring bank whether the processes, proofs and policies followed by you are adequate to defend chargebacks (no one will commit but they can advise you).

b.

For Payment Aggregator: If the merchant doesn’t reply or does not provide satisfactory proof, then the acquiring bank recovers the chargeback amount from the Payment Aggregator. If there are no settlements to adjust (e.g., merchant closed business and nonresponsive) then Payment Aggregators will have no avenue to recover that amount. This is crucial, as Payment Aggregators operate on thin (or no) margins and one such chargeback will impact its margin.

Example: PG Charge: 2%, back-to-back cost = 1.90% So, the Payment Aggregator has to process Rs. 10,00,000 value to make a profit of Rs. 1,000. And one mismanaged chargeback of Rs. 1000 will wipe out that entire profit. Payment Aggregator recovers chargeback amount from merchant’s future settlement. But what if there are no future settlements? Because of this financial risk, it is important for Payment Aggregator to on-board ‘good merchant’: Follow good underwriting process (collect & verify merchant’s credentials) Avoid risky merchants (job search, resume writing, online recharge etc.) Collect security deposit (to cover the chargeback related risks) Challenges in managing Chargeback

Chargeback information is exchanged over email and there is no central system to track chargebacks or map them against refunds. So, it is cumbersome to manage chargebacks in emails. Chargeback in ‘Surcharge Model’

Chargeback can be raised on full transaction amount, not partial amount. A merchant is configured in a surcharge model (Rs. 100 transaction, MDR: 1%, total transaction amount = Rs. 101.18). But the merchant receives only Rs. 100. In this case the chargeback will be raised for Rs. 101.18 and if chargeback is valid then the entire Rs. 101.18 is recovered from the merchant but the merchant has received only Rs. 100. So, the merchant loses Rs. 1.18. Hence,

surcharge merchants (such as the education sector) hate chargeback more than anyone. Closing Remarks

Chargeback processes are in place to protect the cardholder. No matter how boring and cumbersome to handle these chargebacks, they play an important role in the payment ecosystem. A Payment Aggregator should follow better merchant on-boarding policies to make sure the chargebacks are lesser, and a merchant should make sure to reduce chargeback with better service provisioning.

Chapter 10

Recurring Payment Solutions

We all have cases where we need to make periodic payments Monthly utility, mobile, broadband & DTH bills Mutual Fund Investments Insurance Premiums Loan Repayments including credit card bill Subscriptions (OTTs, news portals) Monthly donations to NGO We do not want to miss out on our periodic payments because in some cases it involves disruption of service and in others it may involve penalties or missing opportunities. So, won’t it be nice if such periodic payments are done on their own without much intervention from the users? That is when recurring payments come into picture, where merchants can pull the money from the customer’s payment instrument based on the mandate given by customer. Recurring payment solutions provide better control on collections for merchants and customers will not be worried about late payments or missed payments. Recurring Payments Use Cases:

Based on periodicity of payment and amount type, below are the use cases:

Fixed Amount & Fixed Cycle: Amount as well as periodicity of payment will remain the same. Periodicity can be monthly, quarterly, half yearly, yearly etc. Example: Monthly SIP (Systematic Investment Plan) or quarterly insurance premium. Fixed Amount & Variable Cycle: Here the amount is fixed but periodicity can be random. Example: A user wants to auto top-up the wallet by Rs. 1000 whenever wallet balance reaches Rs. 250. Here, the top up amount remains the same, but the periodicity is random as the wallet balance may reach the threshold at any time. Variable Amount & Fixed Cycle: Here the periodicity of payment remains same, but amount may vary for every debit. Example: My Vodafone post-paid bill amount varies every month depending on usage, but debit happens every month. Variable amount & Variable Cycle: Both periodicity of payment and amount varies.

Example: I can take Ola rides any time and my ride charge will vary every time. Requirements from Stakeholders: Next, let’s understand what the requirements from the merchant and the customer are.

In a nutshell, the perfect recurring solution should address all possible use cases and at the same time, must have high coverage, low cost, seamless user journey and be efficient in performance. That sounds simple, isn’t it? Recurring Payment Solutions:

In the offline world, recurring payments started with post-dated 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, then came online NACH and recently, UPI AutoPay

Note: Apart from these mainstream solutions, there are other recurring payment solutions such as Direct Debit (Offered by selected Payment Aggregators on a handful of banks) and on-demand/recurring debit on mobile wallets. Basics of Recurring Payments:

Irrespective of their format or channel, recurring payment solutions have a similar life cycle: (1) Mandate Filling (2) Mandate Registration (3) Mandate Debit (4) Mandate Modification (5) Mandate Pause (6) Mandate Cancellation (7) Mandate Expiry.

1.

Mandate Form Filling: Customers will fill mandate parameters that define boundaries for debit or merchants can show pre-filled ‘mandate form’ that can be approved by the customer. Mandate parameters are:

Duration: Start and End date or until cancelled: Some mandates are time bound (E.g., EMI payment towards loan for a duration of 5 years) and some mandates can run till perpetuity (E.g., Mutual Fund SIP) until the user stops them. Maximum Amount per Debit: The maximum debit amount per debit is enforced by the regulator or solution governing bodies. (E.g., eNACH: 10 lakh per debit, SI on Cards and UPI AutoPay: Rs. 5000). Also, the customer can set a limit on the maximum amount per debit (e.g., I have set Rs. 2000 per debit for my postpaid connection). As long as the debit amount is lower than maximum amount per debit set by the user, the mandate will be executed. Fixed or Variable Amount: There are certain cases where the debit amount will be variable (e.g., monthly post-paid bill amount). But the loan repayment amount will remain the same. So, depending on the amount type, this parameter needs to be chosen. But it is always good to select ‘variable amount’ so any ad-hoc cases can be included. Cycle/Periodicity/Frequency: It can be of any periodicity (weekly, monthly, half yearly, yearly) or ‘as and when presented’ and the merchant will stage the debit as per the periodicity. The most interesting one is ‘as and when presented’ - this periodicity allows merchants to debit the mandate any time and this turns out to be quite useful when a merchant wants to retry the debit or for ad-hoc debit cases. 2.

Mandate Registration: The mandate needs to be validated or the customer’s credentials needs to be verified.

Standing Instruction: Customer to complete a successful card transaction. NACH (Paper): Mandate to be validated by customer’s bank. eNACH: Customer to complete successful transaction using netbanking or debit card. UPI Autopay: Customer to approve the mandate on her UPI App. 3.

Mandate Debit: Once the mandate is successfully registered then merchants can debit the customer’s account or card within the boundaries of the mandate parameter. Once the amount is debited, merchants will receive settlement as per standard process followed by respective solutions.

4.

Mandate Modification: A few solutions allow users to modify certain mandate parameters. But many solutions do not allow changes to existing mandates but need to create new mandate.

5.

Mandate Pause: None of the solutions (except UPI AutoPay) have provision for pausing the mandate but merchants and PAs have built this feature. Basically, if a user pauses the mandate, then the mandate debit request is not staged until the mandate is ‘un-paused’ by the user.

6.

Mandate Cancellation: Certain solutions can allow users to cancel the mandate any time. But such freedom to cancel needs to be handled carefully as there are certain cases (e.g., loan repayment) where such cancellation facility may jeopardise merchant’s interests.

7.

Mandate Expiry: Mandate works in the boundary of time frame (except ‘until cancelled’ cases) so post the expiry of mandate duration period, the mandate should be made inactive. It is important that users check this parameter while filling the mandate.

Comparison of various recurring payment solutions:

There is no silver bullet solution for recurring payment problems in India. Each solution has some advantages and some limitations. In next chapters, I will cover 4 popular recurring payment solutions: 1.

NACH (paper)

2.

eNACH

3.

Standing Instruction on Cards

4.

UPI AutoPay

10.A NACH Offline (paper based) recurring payment solutions have evolved over a period. A decade ago, post-dated cheques were a popular method for merchants to debit customer’s accounts. If I had taken a bike loan for a 6month tenure, I was supposed to give 6 post-dated cheques. Post-dated cheque model was not scalable so came the era of paper-based mandates with ECS (Electronic Clearing Service). ECS was governed by RBI (Reserve Bank of India) wherein RBI along with few selected Public

Sector banks acted as clearing houses. ECS fulfilled both Credit and Debit requirements of a merchant. But ECS had major problems: Wear & Tear: ECS mandate was printed on an A4 size sheet of paper. Operation Heavy: Collecting and couriering mandates. Longer TAT: 21+ days for mandate validation (For some banks, mandates were validated centrally but for many banks, mandates had to reach the customer’s branch for validation). Higher failure rates in mandate registration and debit. To overcome these inefficiencies, ECS was discontinued and NPCI (National Payment Corporation of India) launched NACH (National Automated Clearing House) where NPCI acted as the clearing house. NACH (National Automated Clearing House):

Although NACH is a paper-based mandate, the scanned images are used for processing, so the time taken for validation/registration is shorter, provides better conversion and lesser wear & tear. Participants in NACH Process: Customer: Provides duly signed mandate form to merchant. Merchant: Entity that wishes to debit customers’ bank accounts (E.g.: Utility company, NBFC, Mutual Fund aggregator, Insurance provider etc.). Merchants can avail NACH service from a bank or Payment Aggregator. Sponsor Bank: Banks that are permitted by NPCI to originate transactions in the NACH system (a Payment Aggregator who wishes to be part of NACH would need a sponsor bank).

Destination Bank: Customer’s bank and the bank needs to be part of the NACH system. Clearing House: NPCI is the clearing house which provides the central system for processing NACH mandates. Payment Aggregator: It on-boards the merchant and works with Sponsor Bank (s) for managing mandate life cycle and charge fees for services. Mandate Lifecycle

A.

Mandate Form: Typically, a merchant provides a pre-filled mandate form which has basic details such as a Sponsor Bank Code, Utility Code, Merchant details.

Customer to fill, Account details (beneficiary name, bank name, account number, IFSC/MICR), and mandate attributes - Frequency (Periodicity), duration (period) and debit amount. B.

Mandate Validation (Registration):

UMRN (Unique Mandate Reference Number) is created for all mandates that are created in the NPCI system. UMRN is used for debit, modification, and cancellation of mandate. Destination banks validate mandate and provide status (Accepted or Rejected) within 5 working days. Banks provide reason for rejection. Mandates that are not validated before 5 working days are considered as Deemed Cancelled. Aggregator/bank can re-lodge Deemed Cancelled and Rejected mandates (if rejection reasons are not critical such signature mismatch or wrong account details etc.). C.

Mandate Debit: Once the mandate is validated successfully, merchants can debit the mandate by following the standard process.

Merchant to send the file to the Payment Aggregator/Sponsor Bank at least 1 working day before the actual debit date. Post successful processing of debit, merchants will receive the funds in the merchant’s account. D. Mandate Modification: Typically, the mandate cannot be modified because of its paper form. So, merchants make sure periodicity (frequency), debit amount and period are such that they cover present and future cases. If you need to modify critical information (change in bank account) then the user has to cancel the previous mandate and provide a new mandate. E.

Mandate Pause: I have monthly SIP and due to financial reasons, I want to pause the mandate for 6 months. So, is it possible to pause the mandate? No, there is no automated process for pausing the mandate. But we know the debit will happen only if the merchant stages the debit file with the Payment Aggregator or Sponsor Bank. So, if the merchant doesn’t trigger my mandate for a debit for 6 months, then it is as good as the mandate is on ‘pause’.

F.

Mandate Cancellation: A customer can request the merchant to cancel the mandate and the merchant can remove the mandate from its system and won’t initiate future debits. Also, customers can request the destination bank to cancel the mandate.

Operations:

Merchant Settlement: Settlement time is T+1 working day. Merchant will receive either gross settlement (if charges are invoiced) or Net-Settlement (if charges are in upfront deduction model).

Refund: NACH doesn’t support refunds. That means, merchant has to find an alternate way to refund the amount. (Pay-out directly to customer’s account using NEFT/IMPS) Commercials:

Mandate registration fee: Flat Fee for successful registration. The fee is passed on to the merchant and, also the destination bank may pass on the charges to the customer. Mandate Debit Fee: Flat Fee per successful debit. NPCI Charges: Levied on both sponsor bank and destination bank. Usually passed on to merchants through the sponsor bank/Payment Aggregator. Destination bank charges may be passed to customers. All charges attract GST @ 18% Safeguarding Merchant:

An NBFC merchant has given a loan to a customer and the customer has set-up a NACH mandate for monthly repayment. Let’s say the mandate debit fails due to insufficient funds. In another scenario, the customer cancelled the mandate by contacting his bank. In both cases, customers do not respond to merchant’s calls/mails/visits. So, what should the merchant do? NACH is covered under Section 138 of Negotiable Instruments Act (1881) and Section 25 of Payments and Settlements Act (2007). Under these acts the frequent dishonour of instructions (NACH) due to insufficient funds attract punishment (like bouncing of cheque). Note: If there is a case where a customer has willingness to pay but doesn’t have funds on that day then the merchant can re-run the mandate (if

periodicity of the mandate is ‘as and when presented’ or collect payment online (website, payment link etc.) Benefits of NACH • • • •

• •

Efficient than ECS and cheques Flat Fee structure is economical for merchants Can handle large ticket sizes (Up to 1Cr) Scalable solution due to electronic image of mandate is used for processing No restriction on type of merchant that can be on-boarded Covered under Negotiable Payments Act, so merchants’ interests are safeguarded

Drawbacks of NACH • • • •

Overhead cost in terms of collection of mandate, scanning mandates 5-day delay in mandate validation File based debit (although companies are moving to APIs) Failure rate is still high because of signature mismatch

Although NACH is paper based, the advantages of NACH outweigh the drawbacks so it is an ideal solution for the Mutual Fund, Insurance, NBFC and B2B industry. Although NPCI has a digital variant of NACH (eNACH), I feel NACH will continue to thrive for the next few years. 10.B eNACH (e-Mandate) This is online variant of a paper based NACH where mandate form filling, mandate registration and debit is done online. eNACH can be extended to any type of use cases and maximum amount of Rs. 10,00,000 can be deducted per debit. There are two main variants of the solution. a.

Based on Aadhar OTP (e-Sign): This was an inefficient model and, also stopped after the Supreme Court’s order on usage of Aadhar. So,

let’s skip this model. b.

Based on net-banking or Debit Card: In this variant, users can set a mandate on their bank account. User has to validate the mandate by completing transaction via net-banking or debit card flow.

Mandate Lifecycle

1.

Mandate Form: The Merchant can capture the mandate parameters such as frequency, mandate duration, maximum debit amount. There is one more important parameter i.e., Account Number and IFSC. Merchant can either pre-fill mandate parameters for customer’s approval or allow customers to enter the details.

2.

Mandate Registration:

Customer can validate using net-banking or debit card In case of net-banking, user is redirected to bank’s page to complete successful transaction and in case of debit card, user will be redirected to NPCI page to complete successful transaction.

If the transaction is successful, then the mandate is registered (for few banks it happens in real time and for others it will be done on T+1 day). 3.

Mandate Debit: A merchant to stage the mandate on T-2 days (via Payment Aggregator) or T-1 day (via Sponsor Bank) before actual debit date (T). Customer’s bank account will be debited on T day and debit confirmation is shared on T+1 day (debit is done in batch processing). Refunds: No APIs for refunds so merchants have to manage refunds offline.

4.

Mandate Update: There is no provision to update the mandate parameters such as periodicity, max amount, or mandate duration. Alternative is to cancel the earlier mandate and register a new mandate.

5.

Mandate Pause: There is no specific API for pausing a mandate. If a merchant is providing ‘pause’ feature to the customer, then the merchant simply shouldn’t stage the mandate for debit during the ‘pause duration’.

6.

Mandate Cancellation: Only merchants can cancel the mandate. So, the user has to inform the merchant and the merchant can remove that mandate. Customer can reach out her bank (destination bank) to cancel the mandate (cumbersome process).

7.

Mandate Expiry: Mandate expires after the mandate duration is over. If the mandate is registered for ‘until cancelled’ then such mandates will not expire until customer requests merchant or her bank (Destination bank) to cancel the mandate.

Commercials

Banks and Payment Aggregators charge two types of fees: Flat fee for registration (one time) (e.g., Rs. 7 for registration) Flat fee per debit (E.g., Rs. 5 for each debit) Positives • • •

Online solution Flat fee model Any type of merchant can be onboarded

Negatives • • •

Delayed status update (registration & debit) Not a seamless experience for user Doesn’t cover all banks

eNACH solution is ‘work in progress’ until all banks are added to the platform. Solution started with only a few banks and only net-banking validation but now it has more than 30+ banks and along with net-banking, Debit Card validation is also included. I am sure NPCI will address the inefficiencies (delays in registration and debit status) in coming days. This is one of the more promising solutions to replace the paper based NACH solution. 10.C Standing Instruction (SI) on Cards So far, we have covered recurring payment solutions on bank accounts. In this Chapter I will walk you through one of the earliest and efficient recurring payment solutions that works on cards. Customers will set ‘Standing Instruction’ on credit cards (Visa, MasterCard) and merchant can debit the card as per given Standing Instruction (mandate). RBI has released detailed guidelines for SI on Cards in August 2019 and the deadline for adherence is set on 31-Sept-2021. Past and Present

Before we jump to the latest SI on Cards solution, let me quickly touch upon the present variant of Standing Instruction on cards SI mandate parameters will be same as any recurring payment solution It is mandatory that first transaction should go through 2FA. Merchant or PA triggers debit instruction on registered card; card is debited without 2FA Merchant receives settlement on T+2 days (standard) Problems with existing solution: Customer doesn’t receive pre-debit notification (exception: few merchants send) No easy process to remove the card mandate (few merchants provide but others do not) Issuer banks do not have way to identify the transaction is for SI on card. So, the issuing bank will send a debit SMS saying the card is debited without 2FA (that might alarm the user) At one point, few banks added SI for Debit Cards and then later pulled back. So, solution was inconsistent. To address those problems, RBI revised the guidelines for SI on Cards: Coverage: All types of cards (Credit, Debit, Prepaid), Scheme (Visa, MC, RuPay, Amex etc.). Debit limit: Maximum amount of Rs. 5000 per debit. First transaction (during registration) should adhere to 2FA (2nd Factor Authentication)/AFA (Additional Factor Authentication).

Pre-debit Notification: Issuing banks should send pre-debit notification to the cardholder at least 24 hours before debit. Issuing banks should provide an option for the customer to opt out of that debit. Post-debit notification: Issuing Bank should send post-debit notification to the cardholder. Cancellation: Issuing Bank to provide an online facility for the cardholder to cancel the mandate (Customers can either opt only out of a particular debit or can opt entirely out of the mandate. Cancellation of mandate should follow AFA/2FA. Dispute Management: Set-up separate dispute management process for recurring payments Payment Aggregators and Acquiring banks should not add new customers to existing SI on Cards model from 1- April-2021 but can service already registered mandates (users). Most of the payment aggregators either ignored or missed this important guideline and no one (except BillDesk) was ready with a solution on the earlier deadline of 31-March-2021. So, RBI has to set new deadline of 31Sept- 2021. SI Hub (by BillDesk)

BillDesk in partnership with Visa has built SI Hub which is designed as per RBI guidelines. I am sure this model will be the benchmark for building SI on cards platform. So, let’s cover it. Architecture: On one hand, issuing banks will be on-boarded to the platform and on the other hand, SI Hub will have various acquiring banks and Payment Aggregators who in turn on-board merchants. BillDesk will decide to whom they offer this platform.

1.

Mandate Form: Mandate form is the place that captures the mandate parameters such as mandate start/end date (or duration of mandate), periodicity (monthly, quarterly, yearly, ‘as and when presented’). Merchant or Payment Aggregator can build this page. Customer can fill the form or merchant can show pre-filled form for customer’s approval.

2.

Mandate Registration: SI Hub generates a unique SI Hub ID (Step 7), and the same ID will be used during the authorisation stage (so the issuing bank will know that the transaction is for recurring mandate).

SI Hub ID will be used throughout the mandate life cycle for notification, debit, cancellation etc. 3.

Mandate Debit: Mandate debit has two stages - Pre-debit notification and debit a.

Pre-debit Notification: This leg has to be done 24 hours before the debit. Either merchant or PA can initiate the pre-debit notification trigger. If the mandate is valid (based on SI Hub Id),

SI Hub will intimate the issuing bank to send the pre-debit notification to the cardholder.

b.

Debit: Merchant or Payment Aggregator will initiate the debit. Before proceeding with the authorisation leg, SI Hub will verify the status of the mandate as the cardholder might have cancel the mandate post receiving pre-debit notification. If the mandate is active, the authorisation is done (considering it is a recurring payment, the authentication leg is skipped i.e., no 2FA/OTP step).

4.

Mandate Modification: Any change in mandate (amount, periodicity, and tenure) requires 2FA (it is like setting a new mandate)

5.

Mandate Pause: There is no specific API for pausing the mandate. If the merchant is providing a facility for the user to pause the mandate, then the merchant should not initiate the mandate debit for the ‘pause period’.

6.

Mandate Expiry: Mandate will be removed post expiry date and card cannot be debited.

7.

Mandate Cancellation: According to RBI’s guidelines, even cancelling a mandate would require 2FA/AFA. So, when cancelling a subscription, customer would be asked for an OTP sent by issuing bank and only then mandate will be revoked.

Other Important Points:

1.

Settlement: Fund Settlement will happen like normal card transactions. Issuing bank to acquiring bank (to Payment Aggregator) to merchant. Settlement time would be T+1 or T+2 working days.

2.

Refund: Standard refund cycle will be followed.

3.

Chargeback: Standard chargeback process will apply but only difference would be issuer bank has to identify these chargebacks differently than regular chargebacks.

4.

Commercials: Commercials/MDR will be dictated by acquiring banks (as Payment Aggregators will use them to process). BillDesk (or any other such platform provider) will levy charges to PA or Acquiring Bank. PA or Acquiring banks can bake them into commercials and offer them to the merchant.

5.

Success Rate: Mandate registration leg will have the same success rate as regular transaction, but the mandate debit will be near 100% unless

the customer has cancelled mandate or card balance is insufficient or card is hot listed by the bank. 6.

Lock-in: If you have registered a mandate with ‘Payment Aggregator A’ then subsequent debits will have to be done through ‘Payment Aggregator A’ only.

Limitation of SI on Cards:

Issuers: SI Hub keeps adding issuing banks as well as card schemes until all banks are on the platform. It will take time to cover all types of cards, and card schemes. Amount Limit: Limit of Rs. 5000 per debit is a challenge for sectors where the debit amount can be higher (e.g., Insurance). In such cases, Option 1: Nudge users to eNACH (which has upper limit of Rs. 10,00,000) Option 2: Initiate two/multiple debit requests (e.g., If debit amount is Rs. 9K then two debits need to be of Rs. 5K and Rs. 4K). Tedious method - so do not even think of implementing it. Use cases: Pre-debit notification limits the number of use cases only to transactions that will happen periodically but there are use cases that may happen randomly (e.g., auto top-up of a wallet). Such cases cannot be covered under this solution. Sector Limit: The merchant on-boarding decision would still be with the acquiring bank, and banks won’t become liberal (e.g., only billers are allowed but not e-commerce merchants) Positives and Negatives of the solutions:

Benefits • •

•

Online process is easy and efficient. Cardholders are familiar with card transactions so better acceptance. Near real-time status for registration and debits so merchant can take actions without delay.

Drawbacks •

• • •

Limited coverage (for now) and will take time to include all types of cards, card schemes and banks. Charges are in percentage (%) of transaction value so not economical. Not useful for larger ticket sizes (e.g., B2B transactions or insurance sector). Depends on acquiring banks approval so cannot cover all use cases (or merchants).

Like any other solution, even Standing Instruction has its advantages and disadvantages. As a merchant, if you see there are more advantages than disadvantages then go ahead with solution. 10.D UPI AutoPay This is the last solution to arrive at the ‘Recurring Payments’ landscape. Considering the growth of UPI, most of us in the Payments domain were waiting for recurring payments on UPI. But when in 2017, NPCI announced UPI 2.0, it was disappointing as it had only a one-time mandate on UPI. As expected, the one-time mandate on UPI has very limited use cases. It works beautifully for IPO subscription or collecting refundable security deposits but beyond that the feature has not much value in the real world. Then in August 2020, NPCI announced the launch of AutoPay on the first day of the Global FinTech Festival. Entities/Actors Involved in UPI AutoPay:

Customer: The one who is setting the mandate. Merchant: Entity which is initiating the mandate (e.g., NBFC).

Acquiring PSP/Bank: Merchant would need an acquiring bank (payment aggregator - who in turn uses acquiring bank) to manage the mandate. UPI App on which users will approve the mandate (E.g., PhonePe, Google Pay, PayTM, BHIM). Customer’s bank on which the mandate is registered. NPCI clearing house and switch. Mandate Lifecycle:

Like other recurring solutions, UPI AutoPay also has a similar mandate life cycle. 1.

Mandate Form: Like any recurring payment solution, even AutoPay 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’.

2.

Mandate Registration: Merchant can initiate the mandate registration and the customer will approve it on her UPI App.

Also, users can set a mandate on their UPI Apps for either P2M (e.g., mandate for Vodafone) or P2P (e.g., 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. Also, due to risk factors, acquiring banks will avoid approving P2P cases (for now). 3.

Mandate Debit: Merchant should send a debit notification to the 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 process 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 will be prompted to enter the mPIN for the first debit for the merchant unless the debit is happening within 1 minute of mandate registration.

4.

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 registered for the combination of Acquiring PSP, UPI App, and underlying bank account. If you wish to change any of these then it is as good as a new mandate so new registration. Mandate can be modified by the

customer (if mandate is customer initiated) or merchant (for merchant-initiated mandate). 5.

Mandate Cancellation: Mandate can be cancelled by a customer at any point of time via the UPI App where it is set (Google Pay, PhonePe, PayTM etc.). A merchant can also cancel the mandate.

6.

Mandate Pause: A merchant can pause the mandate and so can the customer. In case the user pauses or cancels the mandate, then the merchant’s acquiring PSP will intimate the merchant about these actions by the user.

7.

Mandate Expiry: Mandate will be removed, and no further debits are allowed once the mandate expires.

Commercial Structure

Pricing structure for the UPI AutoPay will evolve over a period 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)

Note: Banks/Payment Aggregators may simplify this structure and may offer only mandate registration & Mandate debit fee. Limitations (or Scope for future enhancements)

The present form of UPI AutoPay also suffers from many limitations Transaction limit: Up to Rs. 5000 and if the amount is above Rs. 5000 then the flow would be standard collect flow (user will be prompted to enter the mPIN).

Notifications: For some use cases, it is not practical to send notification 24 hours in advance (e.g., Food order or wallet top up or cab rides, as debit can happen at random times). User power (too much): AutoPay 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 payments, but all transactions should be done from a registered bank account only (i.e., TPV - Third Party Validation). Although UPI has this feature, UPI AutoPay is providing this feature (for now). So, the FinTechs/Aggregators/banks need to build TPV feature separately. Commercial Model: Present cost structure is complex (3 types of fees and slab structure) and, also on the higher side compared to eNACH. When UPI is meant to simplify payments, the pricing should also follow the same philosophy (i.e., simple). Closing Remarks

UPI is an amazing ecosystem with multiple stakeholders (users, merchants, acquiring banks, UPI Apps, banks, NPCI). UPI is a great success story because every piece of the ecosystem worked like a well-oiled machine plus the Government of India and RBI pushed its growth by lowering commercials (i.e., 0 since Jan 2020). But the UPI AutoPay ecosystem is not ready yet. It’s been almost a year since the official announcement, but major UPI App (G Pay, PhonePe) are

yet to include the mandate management part in their Apps and, also many banks are yet to implement it. Good things take time! Considering the growing use cases and volume of recurring payments volumes, a fully efficient ecosystem will be ready in coming years.

Chapter 11

Virtual Account Number and Virtual VPA

Let’s say a few of your friends go out for dinner (aah… Such a pre-2020 thing!). Let’s say you paid the bill and each one owes you Rs. 800. If two people do a bank transfer without adding any remarks, how will you know who transferred the amount? Let’s move the same problem to the business world (not the dinner party but bank transfer). Imagine, you are collecting funds from multiple parties and if everyone does bank transfer, then how will you reconcile (who paid and how much). Of course, they will inform you offline and then you will have to reconcile the transfers one by one. To solve this problem, we have a Virtual Account Number (VAN) concept.

Step 1: Creating Virtual Account numbers (and IFSC) for each customer (or businesses) and communicating it to customers (through App or mail). Step 2: Customer to add this virtual account to her bank account as beneficiary. Step 3: Transfer money to the beneficiary account from netbanking either by IMPS or NEFT or RTGS or Fund Transfer. Note: It is possible to enforce remitter lock i.e., few banks (e.g., Yes Bank and IDFC) pass the name of the customer sending money to the virtual account, with string match logic PAs/Banks can accept the funds only from whitelisted accounts. With this feature, merchants can emulate the TPV (Third party Validation) feature which is an important feature for the regulated investment (MF, Stocks) sector. Settlement to Merchant:

Although some of these rails work in real time (IMPS) or with 30mins delay (NEFT) and, also 24x7, that doesn’t mean the merchant will receive funds immediately. Usually, Payment Aggregators or the bank do settlement to the merchants a few times on a working day. Refund:

There is nothing called ‘refunds’ for this solution. In case, merchant has to refund then simply do a pay-out to the customer’s bank account via IMPS, NEFT rails. Remember: Payment Aggregator/Bank will charge for these pay-outs. Commercials:

Come to think of it, there are no real commercials for anyone involved. Customer used her bank account to transfer funds to the beneficiary via rails which are very much free. “There are no free lunches”, so banks or PAs charge the merchant for the service. Ideally the commercials will be flat rate (e.g., Rs. 1) or can be more creative and offer a differential flat rate based on the transaction amount (e.g., Rs. 1 up to Rs. 10,000 and Rs. 3 for above Rs. 10,000) Benefits:

Unlike net-banking which is limited to 45+ banks, Auto collect can be used by customers of smaller banks, thereby has wider coverage of supported banks Lower commercials Limitations:

Just because there is a solution which is economical, that doesn’t mean a merchant should offer it to customers. Especially considering below listed limitations: Adding Beneficiary: Customer has to add the virtual a/c as a beneficiary. Most of the customers will do it if they have a need to transfer funds regularly (will you do it if you need to transfer funds one-time?). Broken Flow: PG transaction starts and ends in a single flow meaning when the customer clicks ‘pay’ then the merchant knows that something is going to happen. But in Virtual Account based solution, the merchant is clueless when the transfer will be done. Open Flow: Also, when a customer transfers funds, the merchant gets to know the fund is received and from whom but won’t get to know for what purpose? In the case of Payment Gateway, a unique order ID ties a payment to an order but there is no order ID here. So, the customer will have to add the ‘remarks’ during the fund transfer. Use cases:

There are some really good use cases where the solution works flawlessly: 1.

Investment: Customers can transfer funds to the wallet of an investment firm/brokerage and use those funds for investment. This is quite prevalent in Mutual Fund/Stock brokerages and even crypto exchanges or gold harvest type investments.

2.

B2B Payments: Transferring funds towards pending invoice.

3.

Loan repayment: Repaying monthly instalment (why use Payment Gateway, just transfer funds by logging into your bank account).

4.

Education Institutes: One of the traditional models for fee payment is challans. A student/parent will get challan and they will have to deposit money in the bank against that Challan. Instead, Virtual Account Number can be printed on those challans and parent/student will deposit or transfer against that a/c. Easier to reconcile than challans.

Virtual VPA (UPI ID)

How can we not talk about the prodigal daughter of India’s payments ecosystem… UPI! Yes, a similar solution can be built on UPI where a merchant will create a virtual UPI ID for each customer (users or stores) and the customer can make a payment to that UPI ID. UPI QR code can be generated for this virtual UPI ID and the same can be pasted all over the places (E.g., KiranaTech companies or offline QR payments companies use this solution).

How it is different than standard VPA:

Standard UPI ID: Merchant@bank Virtual UPI ID: KiranaTech.merchantA@bank

Hope you noticed the difference between these two UPI IDs To create standard UPI ID or static QR, merchants would need to have an account and provide KYC (as needed by the acquiring bank). This can be a time-consuming process. But Virtual UPI ID is created based on a FinTech (e.g., KiranaTech or LendingTech or NBFC) company’s KYC and account. So, it is easy to create thousands of Virtual VPAs within no time and scale the roll out. Commercials for this solution are zero (as per GOI guidelines) but banks/PAs charge nominal charges for the APIs, infrastructure, reconciliation, and support efforts. The fee structure can be VPA creation fee and transaction fee. Transaction fee can be flat or percentage or it is possible to have even an amount-based slab wise flat fee or percentage + flat rate combinations Closing Remarks

VAN or Virtual UPI ID is a simpler and economical collections solution that is useful in many use cases. With a little bit of customization and a little bit of innovation this can become an important solution.

Chapter 12

Pay-out or Disbursement Solutions

Like two sides of a coin, ‘payment’ also has two sides — collection and disbursement. Collections are important for merchants as they are visible to the user and have a direct impact on sales or revenue. Disbursements or Pay-outs work behind the scenes and generally, do not get the attention they deserve. But Pay-outs are important solutions in the payment ecosystem. In the next sub-chapters, we will cover the pay-out use cases, solutions, integration models and operations. 12.A Pay-out cases Below are some of the pay-out cases for different sectors:

All Pay-out use cases are not the same as they vary in terms of: a.

Periodicity: Few pay-outs are periodic (e.g., delivery person’s incentives that are paid on a weekly basis) and few are random (e.g., winnings of a rummy game). Few pay-outs are uniform across the time-period (e.g.: Travel operator’s pay-out) but few are skewed (e.g., insurance agent incentives) and few are simply random (e.g., COD refunds of an eCommerce merchant).

b.

Number of Pay-outs in a time frame: Few pay-outs are of smaller volume (E.g., incentive pay-out of insurance agents) but few cases have large volumes (e.g., Winning disbursement of Fantasy game merchants post an IPL match).

c.

Value of pay-outs: Few pay-outs are small tickets (e.g., doctor appointment fee) and few are large ticket ones (e.g., insurance claim settlement).

d.

Criticality: Few pay-out cases are not time sensitive (e.g., refund of an insurance policy cancellation) but few cases are highly time sensitive (e.g., partner truck driver’s commission pay-out.).

e.

Who is disbursing the funds?: In most of the pay-out use cases, a merchant does the disbursement (E.g.: Swiggy doing pay-out to restaurants) and in few cases, 3rd parties will do disbursement on behalf of the merchant (e.g., TPA initiating pay-out on behalf of an insurance company).

f.

Cost: Few pay-out modes are cheaper, and few are expensive. Although all types of pay-out solutions work on flat rate model still cost does play an important role in selecting pay-out solutions.

Importance of pay-out solutions:

Although not directly, disbursement will impact the business of merchants. If your delivery person doesn’t get an incentive on time, then he will go to another company. If your lorry partner doesn’t receive funds, then he won’t move the lorry and you will lose that order (or may be that customer). In today’s super competitive world, these things matter. 12.B Pay-out Solutions To make the disbursement (pay-out), a merchant would need:

a.

Source account (where funds are parked): It can be a merchant’s own account, or a merchant needs to park the funds in the payment aggregator’s account.

b.

Payment instrument details (to which funds are pushed): It will depend on the payment instrument.

c.

Rails to push the funds: Depending on the payment instrument, you would need a rail to push the funds (refer below illustration).

Here is the combination of payment instruments and supported rails:

1.

RTGS (Real Time Gross Settlement): Inter-bank transfer platform managed by RBI (Reserve Bank of India) for facilitating large ticket transfers. RBI acts as a clearing house to square off incoming and outgoing funds of inter-bank transfers. Transfer amount: Rs. 2,00,000 and above (unless your bank enforces a cap) Working hours: 24x7 (since Dec’2020) Transfer Type: Real-time

Beneficiary details needed: Account Number, IFSC

RTGS works in the Gross settlement model — That means every transfer will be done separately. 2.

NEFT (National Electronic Fund Transfer): Inter-bank transfer platform managed by RBI where RBI acts as clearing house. Transfer Amount: Rs. 1 to any amount (unless your bank enforces a capping). Working Hours: 24x7 (Since Dec’19). Transfer Type: Batch processing of 30mins. Beneficiary details needed: Account number and IFSC.

NEFT works in ‘net’ settlement: It means that, if Bank A has to move a total of Rs. 15,000 (Rs. 10,000 to Bank X and Rs. 5,000 to Bank Y). Bank Y has to transfer Rs. 3,000 to Bank A. So, during clearing of transfers, Bank A will transfer Rs. 10,000 to Bank X but will transfer only Rs. 2,000 to Bank Y. (i.e., Rs. 3,000 is net-adjusted). 3.

IMPS (Immediate Payment System): This real time inter-bank transfer solution managed by NPCI (i.e., NPCI is the clearing house). Transfer amount: Rs. 1 to Rs. 2,00,000 Working hours: 24x7 Transfer Type: Real-time Beneficiary details needed: Account Number and IFSC (Only first 4 digits of IFSC are checked for majority of banks)

Note: In IMPS, the fund transfer between remitter and beneficiary is done in real-time but the banks do the net-settlement in batches (3 batches per day). 4.

UPI (Unified Payments Interface): UPI is a real-time transfer mechanism that works 24x7 and is managed by NPCI. As UPI rides on IMPS rails, it inherits all the traits of IMPS: Transfer Amount: Rs. 1 to Rs. 1,00,000 (your bank may put a cap on the upper amount) Working Hours: 24x7 Transfer Type: Real-time Beneficiary details needed: VPA/UPI ID or Account Number and IFSC UPI pay-out can be done either by push (where remitter pushes funds to VPA for beneficiary) or Pull (where beneficiary can request for funds from remitter). Covered in Chapter 4.E.

5.

Visa Direct and Master Money Send: These disbursement solutions are managed by Visa and MasterCard via bank. These solutions allow a merchant to disburse funds directly to a card.

Transfer Amount: Rs. 1 to any amount (As allowed by the card/bank) Working: Varies from near real time to T+1 Day 6.

Wallets: Some of the wallets allow pay-outs to those wallets directly (e.g., PayTM and AmazonPay). These pay-outs work in real time and have dependency on KYC compliance and wallet limit.

7.

Fund Transfer (FT): This is intra-bank transfer (both beneficiary and remitter are using the same bank). In this case, only ledgers are adjusted. So, the bank doesn’t route transfers through any of the rails or clearing houses.

Note on 24x7 NEFT and RTGS: Banks need to keep funds with RBI to square off the transfers. Considering they do not want to lock-in their funds with the clearing house, they will enforce limits (e.g., allowed only for retail users). But if the bank has enough funds to park, then they can easily offer 24x7 to everyone and to all use cases. Although 24x7 NEFT & RTGS is available, but banks do not offer it readily for corporate disbursements. Even if they offer, they enforce certain limitations. That pretty much covers the main transfer rails, next one would be about type of Transfers. Pay-out platforms/Integration Types:

These are mainly of two types: P2P (person to person) or B2B transfer (one business to another business). P2P transfers are typically done at branch or online channels of the bank on NEFT, IMPS and RTGS.

UPI transfers can be done by any PSP App of a bank or thirdparty PSPs (G Pay, PhonePe etc.). Business to customers/businesses (One business to multiple parties). Business to customers (or other businesses) is more interesting as various factors such as performance, stability, processing capacity and commercials play a role. Ways to Integrate a Pay-out Solution

1. Payment Aggregator (PA) Model: A payment aggregator will bring multiple banks on a single platform to provide a bank agnostic platform. A merchant will park the funds with the PA and initiate the pay-out (either via dashboard, file upload or API). Advantages •

Bank agnostic platform; no dependency on a single bank, higher uptime, processing capacity, and higher success rate.

Disadvantages • •

Merchant must park funds with the PA and keep replenishing it. Customer’s bank account narration will have the PA’s name and not merchant’s name (can be confusing to user).

Advantages •

2.

Disadvantages

Adding of beneficiaries in real-time; facility of bulk addition of beneficiaries.

Bank-Connected Model: A payment aggregator can offer this model where the merchant will park the funds with a designated bank, but the transfers are initiated via Payment Aggregator’s APIs/dashboard. Advantages

• • • •

3.

Disadvantages

No need to move funds to PA’s account Bank Account belongs to the merchant. Narration will be in merchant’s name. Aggregators may provide better support w.r.t. integration, post-live support.

• •

Bank Model: A bank can offer its pay-out solution to the merchant where the merchant can initiate pay-out via API/Dashboard. There is no other third-party or Payment Aggregator involved. Advantages

• • •

4.

Paying extra to the payment aggregator. Dependency on a single bank: if that bank is down then the payout will stop.

No need to move funds as the account belongs to the merchant Narration will be in merchant’s name Better commercials

Disadvantages •

Dependency on a single bank: if the bank is down then the pay-out will stop

TSP Model: As TSP’s are different than Payment Aggregators so listing it here. Otherwise, this is like Bank-Connected model (point 2), but instead of a Payment Aggregator, a TSP will be integrated with bank and a merchant will initiate pay-outs via TSP.

Commercials:

P2P or B2B transfers: Except for IMPS, banks don’t charge for NEFT, RTGS or UPI. B2Cs or B2Bs transfers: Yes, there will be some API charges. NEFT and RTGS will be on a single flat rate even though most of the banks offer these rails to merchants and aggregators at nil (zero) cost. IMPS and UPI will be on a slab wise flat rate. (Up to Rs. 1000, Rs. 1001 to Rs. 25K and above Rs. 25,000). Few banks may give the pay-out solution for free or may charge a one-time nominal fee as banks love ‘the float’ (amount in bank account). Note: Payment Aggregators and Banks can be creative in pricing. They can offer flat fee, change pay-out slabs, offer hybrid fees (Flat + percentage) or monthly minimum fee etc. Charges are deducted in three ways:

Example: A merchant wants to disburse Rs. 1000, the pay-out charge is Rs. 10, GST is 18% a.

Upfront deduction from beneficiary: Working: Charges (+GST amount) are deducted from the beneficiary of the pay-out. Merchant’s balance is debited for: Rs. 1000 Beneficiary will receive Rs. 988.20 (Rs. 1000 - Rs. 10 - Rs. 1.80)

b.

Upfront Deduction from merchant: Working: Charges (+GST amount) are deducted from the merchant when the pay-out is done.

Merchant’s balance is debited for: Rs. 1011.80 (Rs. 1000+ Rs. 10+ Rs. 1.80) Beneficiary will receive Rs. 1000 c.

Invoicing: Working: Charges (+GST amount) are invoiced to the merchant. Merchant’s balance is debited for Rs. 1000 Beneficiary will receive Rs. 1000 Merchant is invoiced Rs. 11.80 (Raised on monthly basis)

Efficiency of Pay-out Systems:

Pay-out is dependent on multiple entities (merchant, Payment Aggregator, triggering bank, destination bank, RBI/NPCI etc.) and each entity is a potential failure point. Below are some of the points that need to be considered when we talk about the ‘efficiency’ of a pay-out system. 1.

Availability: Payments (whether collection or pay-out) should work each time and all the time. If pay-outs are critical, then availability becomes super crucial. If any of the entities involved goes offline, then pay-outs are stalled. Solution: Do integration with multiple banks or use a Payment Aggregator who has pre-integrated with multiple banks. But there is no alternative if the clearing house (NPCI or RBI) or destination bank is down. In such cases, just queue the pay-outs and wait!

2.

Load Capacity: Every entity has its own load processing capacity and depends on infrastructure and also, liquidity with clearing houses. Load handling capacity is crucial as there is a huge difference between processing 10,000 pay-outs in a day Vs. in an hour.

Solution: Build a highly scalable solution. Each bank has limited processing capacity so add multiple banks to process pay-outs. 3.

Reconciliation: There will be reversals and pending cases and it is important for the service provider (bank or PA) to reconcile those cases so merchants can take appropriate actions. Solution: Run recon on files received from sponsor bank, switch (NPCI/RBI) to identify any reversals or drops.

4.

Success Rate: Like PG, even in pay-out, success rate is an important performance indicator. There are few steps that can be taken to improve the success rate: Adding more banks to do pay-out, so dependency on a single bank is lowered. Retrying and queuing of pay-out instructions. Validating beneficiary’s instrument details (e.g., validating bank account, beneficiary name and UPI ID/VPA) before initiating payout to those instruments.

Beneficiary Validation:

To reduce the failure rates, merchants should validate the beneficiary’s payment instrument. For Bank Account validation, the merchant can drop Rs. 1 to the account by passing account number and IFSC. If the account number is correct, then the beneficiary’s name is returned. Two things happened with this: (1) Confirmed that account number is correct and account status is live (2) Got the account holder’s name (which merchant can validate)

Only problem is many banks won’t send complete name (truncate the name) or append beneficiary names with Shri or Mr. etc. For UPI validation, penny drop is not done. Basically, Validate VPA API is called which validates with NPCI whether the VPA is active and returns VPA holders name as registered with the UPI App (such as PhonePe, Google Pay). In theory, UPI can be used to check beneficiary name of any bank account without penny drop as UPI works on IMPS rails. To do this type of validation, send request in format: @.ifsc.npci (Note: It may not work for all the banks). Connecting Collection and Pay-out:

Many merchants will have use cases for both collections and disbursements. Funds are collected from Payment Gateway, Recurring payment, or Virtual account solutions. And later disbursed using IMPS, NEFT or UPI rails. So, a merchant can connect both collection and disbursement legs and manage the financial supply chain more efficiently.

Credit Card Repayment:

Interestingly, IMPS and NEFT also can be used to push the funds to Credit Cards. Credit Card is nothing, but the account number and every credit card issuer has a single IFSC (e.g., IFSC for HDFC Credit Cards is HDFC0000128 and ICIC0000103 is for ICICI Credit Cards). So, you can push funds to a credit card if you have the 16 digits of the card and issuing bank’s IFSC. Based on this simple working, many companies are building credit card repayment-based businesses. CRED reached Unicorn state with a great idea that is triggered by a simple pay-out mechanism. Closing Remarks

With more & more Pay-out use cases coming up and merchants wanting to achieve higher efficiency & scalability, ‘Pay-out Solutions’ will become as important as the ‘PG solutions ‘.

Chapter 13

International Payments

Those who have read Dan Brown’s ‘Da Vinci Code’ or watched the movie with the same name starring Tom Hanks, would be familiar with Knights Templar — a holy military order with the purpose of protecting Jerusalem during Crusades. Here is a little-known fact about Knights Templars — they developed the first cross border payment/banking system. There was always risk (theft, loss) in carrying money/gold on a pilgrimage to Jerusalem. A pilgrim could simply deposit the funds in one of the Templar Churches in London and get a receipt which can be shown in a Templar Church in Jerusalem and collect the funds. Today’s world is very different from the one in medieval ages, as the crossborder trade and travel increased, the cross-border payments also evolved. Today, we do trillions of cross-border payments. And in this Chapter, I will talk about international payments or cross-border remittances with India as the focal point. Jargons:

Here are a few of the important jargons related to cross border payments: Nostro Account: A foreign currency account maintained in a bank in a foreign country. When Party A (in the U.S.) remits to Party B (in India), the funds flow through a Nostro A/c or an intermediary account or a correspondent bank.

E.g., ICICI Bank holding an account with JP Morgan in the USA is called a Nostro Account. Vostro Account: When a bank maintains a local or home currency account of a foreign bank or branch in its own country it is called a Vostro account E.g., JP Morgan holding an account with ICICI in India would be a Vostro A/C. SWIFT (Society for Worldwide Interbank Financial Telecommunication) is an organization founded in 1973 with the purpose to standardize messaging and processing for global transactions. The SWIFT network doesn’t transfer funds but instead, it sends payment orders between institutions’ accounts, using SWIFT codes. SWIFT standardised IBAN (International Bank Account Numbers) and BIC (Bank Identifier Codes) formats. FIRC (Foreign Inward Remittance Certificate) is issued by a merchant’s beneficiary bank for every inward remittance that is received. Apart from working as a legal proof for international payments, FIRC is required to claim export incentives and GST waiver on products sold overseas. Forex (or Foreign Exchange Rate) means how much of a currency of another country (E.g., US $) I can buy using a different currency (E.g., INRs). For various macroeconomic reasons this rate varies/changes unless a country has pegged it to a currency. FATF (Financial Action Task Force) is the global money laundering & terrorist financing watchdog who set the international standards to avoid any illegal activities.

Sanctioned Country: Sanctioned countries are subject to restrictions on certain types of activities. E.g., Iran has a restriction on imports, exports, or financial transactions. OFAC (The Office of Foreign Assets Control) is a part of the US Treasury that regulates trade sanctions on countries or individuals who are involved in or promote illegal activities. Money Conversion: As you know, in cross-border payments, the currencies are getting converted. In India, only RBI authorised entities, Authorized Money Changers (AMCs), are allowed to conduct exchange or conversion. Different categories for AMCs: Full Fledged Money Changer (FFMC) is a money changer authorised to purchase foreign exchange from non-residents visiting India and residents, and to sell foreign exchange for private and business travel purposes only. (E.g., Department of Post) Authorised Dealer (AD) Category-II Banks are entities who deal in foreign exchange for specified purposes (E.g., Upgraded FFMCs, Select Regional Rural Banks (RRBs), Select Urban Cooperative Banks (UCBs)). Authorised Dealer (AD) Category-I Banks are authorised dealers of foreign exchange & securities (E.g., Banks). Use Cases:

There are various use cases of cross-border payments. A migrant worker in Dubai sending funds to India, a craftsman based out of Channapatna receiving proceeds for products sold on Amazon USA, a vendor based out of Singapore wants to receive funds for items sold on Flipkart or an IT professional based in USA ordering furniture for her parents in India on

PepperFry.com or you are investing in Tesla shares in USA via an intermediary. Three Main Solutions:

I will write about three main solutions which covers almost all use cases 1.

Outward Remittance: Funds that needs to move outside India (e.g., Pay-out to a seller based out of Singapore who sold product on eCommerce marketplace in India).

2.

Inward Remittance: Funds that needs to move to India from other countries against the sales proceeds.

3.

International Payment Gateway (PG): Customer is outside India and paying on Indian merchant’s website/app using her non-INR credit card.

Note: Although the third one is nothing but inward remittance but decided to keep it separate as it is one of the most common payment options used by the merchants. 13.A Outward & Inward Remittance Because of the similarities in compliance, I will be covering these two solutions in this sub-chapter. A.

Outward Remittance: Simply put, it means funds will move outside India. Below is simple fund flow (from an aggregator’s standpoint).

RBI has defined a separate remittance scheme under which funds can move out of the country There are 16 categories which have again multiple sub-categories: Capital Account

Exports (of Goods)

Transportation

Travel

Communication Service

Construction Service

Insurance Service

Financial Services

Computer & Information Services

Royalties & License Fees

Other Business Services

Personal, Cultural & Recreational Services

Transfers

Government, not included elsewhere (G.n.i.e)

Income

Others

Refer to the complete list https://www.rbi.org.in/upload/notification/pdfs/52220.pdf

here:

Here are a few examples for outward remittance types, use cases along with a few payment providers who provide these solutions. (Below)

B.

Inward Remittance: Inward Remittance means funds will move to India from outside. Below is a simple fund flow (from an aggregator’s standpoint).

There are 3 remittance channels through which funds can be accepted from international sources and few of the payment companies that provide those services. (Below)

For RDA (Rupee Drawing Arrangement), the entity should be licensed as an exchange house in the sending country. These entities (non- Indian) enter a partnership with AD Category I Banks for a Vostro A/C (or INR A/C) from which pay-outs are made to the receivers. The funds should be received from licenced and regulated entities in the sending country for

sourcing the funds from the remitters (established exchange houses) (E.g., TransferWise). For MTSS (Money Transfer Service Scheme), money transfer companies abroad (operating as Overseas Principals) should be licensed in the sending country and should get necessary approvals from DPSS (Department of Payment and Settlement Systems) of RBI. Funds are sent to an Indian Agent (licensed FFMC - Full Fledged Money Changer) (E.g., Western Union). Compliance & Commercials

As compliance and commercials models are almost the same for both inward and outward remittance so I am clubbing those here. 1.

Compliance & Limitations: PART A: While on boarding a recipient (foreign vendor), it is essential to ensure that the recipient does not belong to Non-FATF Compliant geographies/Sanctioned Countries. OFAC rules prohibit transactions with certain foreign countries or their nationals and hence are to be complied with. India abides by the OFAC regulations because: The US dollar is the most traded currency globally. Most correspondent banks are based out of the US or associated with the US. Cross-border payments could directly or indirectly involve US banks. PART B: Transaction Limits to be in line with the existing regulations.

E.g., The OPGSP Import guideline defines a USD 2,000 cap on every purchase. LRS transactions have a cap of USD 2,50,000 annually at a user-level. PART C: When funds are being moved cross border, it is essential to establish an end-to-end transaction trail. To do so, the below information is to be gathered: Buyer Information — Name, Email, Mobile No. Seller Information — Name, Address, Bank Account Details Invoice Specific Details — Invoice No., Invoice Date, Invoice Amount, Description AWB (Airway Bill) — where physical goods are moved Remittance Scheme Declarations e.g., LRS declaration Purpose Code specifying purpose of transaction (Purpose Code specifies the reason for fund movement). Capital Account

Other Business Services

Communication Service

Transportation

Construction Service

Royalties & License Fees

Travel

Insurance Service

Computer & Information Services

Transfers

Financial Services

Personal, Cultural & Recreational Services

Income

Exports (of Goods)

Government, not included elsewhere (G.n.i.e)

Others

 

 

Compliance is relatively easier when it comes to inward remittances since forex is coming into the country. However, the checks remain constant as above.

2.

Commercial Model: Commercial models (line items) remain same for both inward and outward remittance: 1.

GST on Currency Conversion

2.

SWIFT Cost (borne by sender)

3.

Correspondent Bank Charges (can be borne either by sender or receiver)

4.

FX Margin — Calculations will vary as funds are converted from INR to USD in case of outward remittance and USD to INR in case of inward remittance.

Sample Calculations for Outward & Inward Remittance

Closing Remarks

India receives 15% of global inbound remittances — $83B in 2019 and $27.4B in 1st half of 2020. No need to say but surely COVID has dampened 2020 numbers. RBI very well knows the problems of existing cross-border payments and wants to bring in more efficiency.

As the first step, ‘cross-border payments’ is the theme for RBI’s 2nd cohort under regulatory sandboxes with the aim ‘to spur innovations capable of recasting the cross-border payments landscape by leveraging new technologies to meet the needs of a low cost, secure, convenient and transparent system in a faster manner’. Looks like cross-border is one of the most exciting parts of the payments landscape. Keep an eye on this space as a lot of new developments/innovations will happen. 13.B International Payment Gateway Here is the use case: An eCommerce merchant based in India wants customers based outside India to make payment on its website. This is quite a common requirement for eCommerce (daughter living in Singapore order furniture for her parents in India), travel (NRI who is coming to India wants to book flight for her domestic journey), education (parents who are in Dubai want to pay their kid’s college fees) and IT Service/SaaS sectors (a US based entity pays small monthly fees to Indian website development company). Solution for this requirement: the Indian merchant enables international PG from any of the Payment Aggregators or acquiring banks. Coverage of this solution: (a) Non-INR Visa and MasterCard credit/debit cards (b) Amex — With direct integration. Working Models:

1.

Dynamic Currency Convertor (DCC): Merchant shows the amount in INR Customer will make the payment in base currency of the card (e.g., US $)

Settlement will be done to merchant in India in INR 2.

Multi-Currency Convertor (MCC) Merchant shows the amount in base currency (e.g., US $) Customer will make the payment in base currency of the card (e.g., US $) Merchant will get the settlement in India in INR.

Commercials

International PG is more expensive than domestic PG. Typically in the range of 2.50%-2.75% (+GST). There is no sector wise pricing (all sectors, be it eCommerce or education, will have same pricing) Typically, the settlement time is T+2 days and for every transaction, the merchant has to get FIRC from its acquiring bank (or payment aggregator) and that is a manual process. Major Problems with International PG:

2FA (2nd Factor Authentication) is not-mandatory outside India except for high-risk transactions (sort of step-up authentication leg). So, when the customer is posed with 2FA (OTP), then they may simply drop off and thus the success rate will tank. Additional Charges: as the base currency and transaction currency are different, a cross-currency mark-up fee (in the range of 3.50%) will be applied. As customers may not be aware of this, they will assume that the merchant has over deducted the card and raise a dispute or chargeback. Refunds: Exchange rate may change from the time of transaction and when the refund is marked. So, it is possible that when a

refund amount will be lesser than the transaction amount. Enabling International PG:

The acquiring banks consider International PG as high risk. So, the approval is not that simple, and bank(s) will have various limitations & conditions for enabling this PG: Sector restrictions (easy to get approval for eCommerce but not for gaming or NGOs). Merchant restriction based on vintage and reputation (a good brand eCommerce can get approval, but a new unknown eCommerce merchant may not). Bank may ask for additional documents such as audited financial reports. Bank may ask for security deposit to cover chargeback risk. Closing Remarks

International PG is the simplest solution for the merchants to receive international payments. Although there are other options such as using services of PayPal or Payoneer like companies, international PG is still the most economical way for international payment collections.

Chapter 14

BBPS – Bharat Bill Payment System

We all pay different types of bills regularly: electricity, mobile, DTH, insurance premiums, credit card bills etc. To give flexibility (choice of channel and payment mode) to customers, a biller enables multiple channels for bill payment. Example: BESCOM (electricity distribution) has various channels to collect bill payments: BESCOM website BESCOM collection counters Bangalore-One counters Third party Apps/website: PhonePe, Google Pay, BillDesk website etc. Registering BESCOM as a biller in your bank account

Of the mentioned channels, the last 3 channels are of our interest as it is interesting to know how a user can pay a utility company’s bill on an App of a third-party service provider or through a bank account. This is where BBPS (Bharat Bill Payment System) comes into picture. Before we jump into BBPS, let us understand its evolution:

More than two decades ago, BillDesk and BillJunction (TechProcess) developed a bill payment platform called EBPP (Electronic Bill Presentment and Payment) platform. On one side, billers (utility companies, Telco, insurance, MF, card companies) are integrated to the platform and on the other side agents (e.g., third party Apps, banks etc.) are on-boarded. By integrating with the EBPP platform, agents can extend bill payment services to its customers. Participants of EBPP:

a.

EBPP Provider: Companies (BillDesk/TechProcess) that provide bill payment platforms.

b.

Agents: Entities that integrate with the EBPP platform and bring customers to the platform for bill payment. Example: PhonePe, Google Pay, HDFC Bank or Bangalore One. These agents enable bill payment through online payment gateway, wallet, UPI, bank account or cash.

c.

Billers: Entity that intends to collect payments from users. A biller can be a Telecom (e.g., Airtel), utility company (e.g., BESCOM), Insurer (e.g., LIC) or Credit Card issuer (e.g., Amex). There are two types of billers: Biller with validation: These billers would require the customer to do one time validation of bill credentials. With registration, agents can fetch the bill and show it to customers (This is how every month you see your BESCOM bill in your HDFC net-banking account). Such billers may have few conditions with respect to bill payment such as: (i) do not allow payment after due date (ii) late payment charges (iii) do not allow partial payment. Biller without validation: Such billers allow bill payment without validation (E.g., Vodafone). Such billers do not have conditions with respect to due date, penalty, or partial payments.

Note: Some billers work in both validation as well as without validation model. EBPP Process:

Stage 1: Transaction Flow of EBPP

Customer selects the bill on the Agent’s website/App and makes payment with her preferred mode (card, Net-banking, UPI, or wallet). EBPP provider then does payment posting to the biller and returns the status of bill payment is communicated to the customer via Agent. Stage 2: Fund Movement of EBPP

EBPP provider shares payment report with the agent on T+1 day and the agent has to transfer the amount to EBPP provider’s nodal account and EBPP provider will deposit funds to billers’ account on T+1 day Commercial/Revenue Model:

1.

EBPP provider (aggregator): For every bill collected through the platform, EBPP provider receives a fixed fee (Rs. 0 — Rs. 5) from the biller. This arrangement is finalised when the biller is on-boarded (typically through RFP process).

2.

Agents: EBPP Provider shares part of the revenue earned from biller (say 50% or 60% of revenue). But agents bear the collection cost. If it is cash, then cash management charges (if any) and in case of payment gateway it will be transaction charges (or MDR). Agents cannot charge additional fees from users (billers do not allow surcharging). Agents may not get lower transaction rates (or MDR) as agents themselves are not utility companies (Utility companies have lower MDR compared to other merchants). Agents also bear customer acquisition costs and any promotional costs.

If EBPP was working fine for decades, then why replace it?

EBPP was not an efficient model and below are some of the limitations: A biller on-boarded with BillDesk will be available only for agents of BillDesk. If a biller is exclusively available with TechProcess then the agent has to do integration with TechProcess’ EBPP platform. Over a period, BillDesk and TechProcess created a monopoly in the bill payment space so many late entrants couldn’t access this sector. There is not much incentive for agents who bring the customers (because of meagre revenue potential) BBPS (Bharat Bill Payment Systems)

To address these limitations and to provide a level playing field, NPCI launched BBPS.

Participants of BBPS Platform:

Billers: Entities that intend to collect bill payments. These may be utility companies, Telecom, DTH, Insurance companies etc. BBPCU: Bharat Bill Payment Control Unit i.e., NPCI provides the BBPS platform and facilitates off-us transactions and acts as clearing house. BBPOU: Bharat Bill Payment Operating Unit, these are licensed entities and can be bank and non-bank (payment service providers). Operating Units (OUs) that are focused on adding billers are called BOU (Biller Operating Unit) and Operating Units that are focused on adding agents (customers) are licensed as COU (Customer Operating Units). Agents: Entities that work with COUs to access BBPS systems. Agents are the ones who bring the customers (users) to the platform through their App, website, or collection counters. Advantages BBPS:

With off-us flow, agents of BBPOU A can access billers of BBPOU B without doing multiple integrations.

Aggregators who couldn’t get billers of their own can now access all billers and can focus on adding more agents. Standard APIs for biller on-boarding and agent integrations. Transaction Flow of BBPS:

On-Us transaction: Cases where the biller and agent belong to the same BBPOU. Here BBPOU confirms the payment status and moves the funds from agent to biller. Off-Us transaction: Cases where biller and agent are with different BBPOU. Here BBPCU facilitates the bill payment and acts as clearing house to move money from agent to the relevant BBPOU (who in turn will settle funds with biller). Commercial Model:

BBPCU: Rs. 0.20 per bill paid through BBPS (for the utility sector). This rate varies for different sectors. COU: Entities that are registered as COU receive Rs. 2.50 for every bill paid (online) and Rs. 5 to Rs. 25 per bill (if paid offline,

cash). BOU: Flat fee per bill paid (typically agreed during biller onboarding). If you do simple maths, then BOU should charge the biller anything above Rs. 2.70 to make profit (but generally this won’t happen). Agents: COU will have a revenue sharing arrangement with agents (50:50, 60:40 etc.). Agents bear the cost of collection (e.g., cash management fees or PG charges). Success of BBPS:

The idea is to bring all major sectors/verticals under the BBPS platform. At present, Utility companies (electricity, water, gas), telecom, DTH, Insurance, Mutual Funds, College Fees are under BBPS. Just recently, prepaid mobile recharges are included. Eventually, even e-commerce will come under BBPS. BBPS transactions are increasing multiple folds every month so should we conclude that BBPS model was successful? One of the purposes of BBPS was to create a level playing field for all BBPOUs but considering BillDesk is still a dominant player, I wonder whether BBPS was successful on that count. In 2020, NPCI floated a new subsidiary, NPCI Bharat BillPay limited (NBBL) to promote BBPS. It will be interesting to watch what this new subsidiary will do and shape the bill payments space.

Chapter 15

Wrapper/TSP (Technical Service Provider)

Let me bring back one of my favourite toys — Russian Nesting Dolls. Why they are my favourite? Because they are perfect analogy for India’s payment ecosystem. I have referred to this analogy multiple times throughout this book. I am bringing that here again as we will be talking about outer most doll of India’s Payments nesting doll – A Wrapper or TSP. In this chapter, I will cover the wrappers/TSP/API providers. Such entities are mushrooming across various areas in the payment ecosystem such as online payments, pay-out, BBPS as well as API Banking (Banking as a Service). Let’s start the ‘unwrapping’. Basic Principle:

These entities aggregate service providers at one end and extend it to the merchants (corporates, online commerce, neo-banks, Lending Techs etc.).

There are various types of TSPs, and they are focused on a particular area. These TSPs specialized in payment aggregators (E.g., Juspay and DreamPay), Bharat Bill Payment System (Setu.co), Banking APIs (E.g., Decentro) and Credit Card issuance (E.g., Hyperface.co). Value of TSPs:

For consumption side entities (merchants, Corporate, neo banks): Access multiple payment service providers on a single platform - Lesser integration effort (Build Vs. Buy call). Provider side entities (Banks, issuers etc.): Another low-cost distribution channel to promote their products and services. Drawbacks & Limitation of TSPs:

All eggs in one basket: A wrapper/TSP can become a single point of failure for the merchant. Operations: A wrapper may take care of integration (APIs) but if a merchant adds more service providers that will increase their operation efforts or costs. Extra cost: Along with payment service providers charges, merchant will have to bear additional charges of the TSP.

Commercial Model:

A typical wrapper will have its own charges apart from underlying service (e.g., Juspay charges on top of the charges of Payment Aggregators, acquiring banks etc.). These companies can be creative in terms of pricing (like SaaS companies): Percentage (%) of the transaction value (e.g., 0.10% of successful payments) Fixed fee per transaction (e.g., Rs. 1 per pay-out) Monthly fixed fee Feature wise charges (e.g., Additional charges of card vault etc.) In majority cases, TSPs work in invoicing models (if TSP is not involved in money movement) but they can also work in upfront deduction models (if TSP is involved in money movement). TSP Models based on Payment Platforms:

A.

Payment Gateway: As you know, larger merchants do integration with multiple Payment Aggregators, acquiring banks and wallets to reduce dependency on single service providers, increase payment coverage, command better pricing etc. But such a strategy will bring in additional challenges such as increase in integration effort, management effort related to transaction routing, reconciliation & operations, uniform payment page, and unified card vault. A TSP provides platform to solve these challenges (almost): PCI-DSS Compliant card vault (so no lock-in with any PAs). Management of Payment Service Providers (adding, removing easily).

Routing engine to divert and split traffic across multiple PA/PGs based on Merchant’s preference to optimize success rate, performance, and commercials. Unified dashboard to view performance & success rate of all payment providers.

Players: Juspay and DreamPay: These two are neutral TSPs - meaning they do not have their own payment aggregation business. Pine Labs, RazorPay, Ingenico, PayU, PayTM — These Payment Aggregators also have some sort of wrapper with limited number of Payment Aggregators/Service Providers. As these companies have their Payment Aggregation business, so they are not completely neutral. B.

Others (BBPS, Banking API, Card as a Service): There are TSPs in different areas of the payments’ ecosystem. Some of the notable areas are:

Entire open banking concept is based on wrappers where one entity is offering services of multiple banks without being banks. Neo-banks, FinTechs, Lending Tech companies are either building things on their own or using TSPs such as Decentro, Setu or Hyperface. Payouts: As covered in Chapter 12, a connected integration with the bank for payout is nothing but a wrapper/TSP model. Many Payment Aggregators are morphed into TSPs in that case. Even Juspay, DreamPay and Recko are also providing pay-out wrappers. BBPS (Bharat Bill Payment System): For decades, BillDesk has been acting as a TSP/wrapper for banks to enable EBPP and then later BBPS. But the scope was limited to one bank at a time. But Setu.co pushed the concept further by becoming a super wrapper (with settlement capabilities) for BBPS with multiple banks. UPI: Google Pay is a UPI App (to a customer or to merchant) but, Google Pay is TSP of UPI. G Pay has partnered with multiple UPI acquiring banks and those banks process transaction and do settlement. G Pay is not involved in money movement (unlike PhonePe, which is involved in money movement) Considerations:

All said and done, a merchant (corporate, neo bank, FinTech etc.) must think whether it needs a TSP/wrapper. So as a merchant, I would consider the below arguments: Need: Do I really need to integrate with every service provider because I have options? Maybe not. If you don’t need many service providers, then you may not need TSP Build Vs Buy: If I really need to add many service providers/products and have shorter GTM then I will buy (go for

TSP) and may be build it later. Cost Optimization: I will surely factor the additional cost of TSP on top of core costs of payment service providers. But if I really need to take service from a TSP then limit the scope to optimize the cost. (E.g., Juspay or DreamPay TSPs have great value for card vault but what is the value when it comes to net-banking? So why route net-banking and incur extra cost?) All Eggs in one basket: As wrapper/TSP becomes single point of failure. So, I would still need a back-up (hope for the best and plan for the worst). Closing Points:

There is no silver bullet (single solution) for solving a merchant’s payment requirements. And as long as there are gaps, one or the other company will try to come up with a solution. Thus, keep adding more layers/dolls to our Payments Nesting dolls.

Chapter 16

Offline Payment Solutions

India’s payments story will be incomplete if we do not talk about the instore payments. In this chapter, I will briefly cover POS (Point of Sales), ePOS/Soft POS and QR Codes. 16.A POS (Point of Sales) These are the machines provided by acquiring banks (E.g., HDFC, SBI, Axis etc.) or payment aggregators (e.g., Pine Labs, World Line) for processing of cards at stores.

a.

Acceptance: POS predominantly works on cards - Credit cards, debit cards and open loop prepaid cards. Usually, Visa, MasterCard, Maestro, RuPay cards are accepted on POS. POS machine needs to have additional capabilities to process Amex or Sodexo cards.

Entities Involved: POS Aggregator: Entities that have ability to configure different acquiring banks (Worldline, Pine Labs, Innoviti etc.) and install POS machines at stores. Acquiring Bank: Bank that installs the POS machine and processes transactions POS OEM: Companies that manufacture the POS machines (Ingenico and Verifone). Issuing Bank: The bank that has issued the card (E.g., ICICI, HDFC) Card scheme: Card network (Visa, MasterCard, RuPay) Merchant: Entity that is collecting the funds (e.g., stores). Cardholder: Person who is using the card. b.

Transaction: Transaction processing works almost the same as online payments with a major exception. Even POS transactions need to adhere to 2FA (2nd Factor Authentication) but instead of OTP (of online payments), card holder to enter the PIN (Personal Identification Number - Usually 4 digit) In a nutshell, POS transactions have three steps: Authentication: PIN is verified post machine reads the card successfully. Authorization: Transaction is approved by the issuer bank after completing risk checks. Capture: The funds start moving. In online payments, capture is done automatically (Except in case of Pre-Authorization flow) but in case of POS the storekeeper will have to press a button on the machine to capture the transactions.

c.

Transaction Types: There are three different ways POS machine reads the card: Swipe: Card’s magnetic stripe is swiped in the machine and card is recognized Insert: Card’s EMV chip is inserted in the slot of the machine for card recognition Contactless: Card is tapped on the machine and card is recognized with NFC (Near Field Communication) Technology.

d.

PIN Validation: As per RBI guidelines, 2FA is mandatory (since May 2012) and PIN prompt is done on POS machines. RBI has relaxed rules on the amount required for 2FA. As per the guideline update, an amount below Rs. 2000 doesn’t require 2FA. The amount has changed to Rs. 5000 for contactless (NFC) payments. But again, a user can set the limit on the card (up to Rs. 5000).

e.

Commercials: POS transactions are called CP - Card Present (user is present at payment point) whereas online transactions are called CNP - Card Not present (user is remote). CP transactions are less risky (as the user is present at point of sales) so the POS transactions have lower commercials compared to CNP (online) transactions. (E.g., MDR for eCommerce merchants: 1.80% whereas the MDR for in-store POS will be 1.40% - Remember, MDR is risk adjusted). Merchants not only bear the MDR but also, they may be charged onetime instalment fees and monthly maintenance fees.

f.

UPI QR on POS: POS are predominantly designed for card acceptance. Demonetization (Nov 2008) triggered massive demand for POS (As cash was not available so even smaller stores installed POS). But the same demonetization triggered another big phenomenon, i.e.,

popularity of UPI. Within a couple of years, UPI QRs. started mushrooming all over the place. Fearing the reduction in card transactions, even POS providers started integration with UPI. Basically, they would show dynamic UPI QR Code on the POS screen. Now, the user can either swipe a card or pay using UPI App. But this UPI QR strategy hasn’t worked much for these POS players. g.

mPOS: These are lightweight POS machines that can be carried in the pocket. Although the working of mPOS is same as regular POS but due to cost and convenience (of carrying) these are popular among eCommerce delivery and smaller stores. EzeTap, mSwipe are big players in this space.

h.

Wear and Pay: This is the new payment channels. Instead of cards, the card details are encoded (tokenized) into a device (key chain, wristwatch etc.). Customer can simply tap it on the POS to do a NFC based contactless payment of amount up to Rs. 5000. Few of the entities that have already launched such programs: Axis bank and SBI + Titan

16.B Soft POS (ePOS) As the name suggests, these are hardware less POS solutions (or at least can be claimed as that). Instead of the hardware, a mobile SDK is used, and this SDK can be integrated into a mobile App (of delivery person or stores) for the acceptance of the payments. ePOS is a good solution for converting Cash on Delivery (COD) to Payment on Delivery. Let’s say, you have ordered something on COD. The delivery person will reach home and then you can make payment in Cash. But what if delivery person gives you the option to make payment using card, net-banking, or UPI?

A typical ePOS product does few things: 1.

Sending payment link: Delivery person can send a link to customer’s mobile. Once a customer clicks on the link, a payment page will open where the customer can select cards, net-banking, UPI, or wallet and do a regular online transaction.

2.

Generate Dynamic UPI QR: Generate dynamic UPI QR (amount is embedded in that) and customer can scan & pay using her UPI App (e.g., G Pay or PhonePe).

3.

Tap and Pay: The new development in this area is embedding ePOS SDK with NFC capabilities so the user can simply tap the card on the delivery person’s app.

Note: All other processes such as refunds, and chargebacks remain as online payments. (We have covered those in earlier topics). 16.C UPI QR Code How to convert COD to online payment? Solution: QR Code! How to facilitate agent collection? Solution: QR Code! Are people scared to touch ATM buttons? Solution: QR Code!

QR Code is like the ‘Yoga’ of the payment world, for any problem, it is “the solution” If you are in India then you wouldn’t have missed these QR codes which are pasted in almost every store by companies like PayTM, PhonePe, AmazonPay, BharatPe and a few banks. There are three types of QRs Own network: You can scan & pay if you are using the QR issuers App (E.g., PayTM wallet QR code that can be scanned only by PayTM App) UPI QR: You can scan & pay using any UPI App (e.g., Google Pay, PhonePe, AmazonPay, PayTM or Banks’ BHIM UPI Apps) Bharat QR: The QR will have acceptance for Visa, MasterCard and RuPay cards as well. Still yet to see much action on Bharat QR

Closing Remarks

Payments from QR code are growing and will continue to grow. So, the RBI wants to look at it and fix potential problems. What does that mean? RBI wants to define a framework, bring in standardisation and maybe, regulate it. RBI has invited suggestions and recommendations from the

stakeholders - let’s wait and watch what happens next. For now, things are looking bright. A QR code and UPI is an amazing combination to digitise India’s millions of stores and various use cases.

Chapter 17

Sectors – Industries

Every sector has different working models and so are the payments in those sectors. Also, as there are minor changes from merchant to merchant within the sector, but fund flows typically will be the same. As a sales leader, identifying sectors, understanding requirements for each sector, and then mapping the solution has been my basic job as the execution was dependent on that. For my ease of working, I classified merchants into 15 sectors and each sector had multiple sub-sectors. This is not an industry standard but just my style of working. I hope my readers will find this useful.

In the next few sub-chapters, I will cover a few of the prominent sectors, payment related requirements, and solutions. 17.A eCommerce eCommerce — one of the most visible sectors with small, medium, big, and gigantic merchants with different types, flavours and business models. Today, without stepping outside the house, I can buy things that I need, things that I don’t need and things that no one needs - all thanks to eCommerce! There are various types of eCommerce companies: Own Inventory Vs. Market Place (merchant sells inventory of other vendors).

Horizontal (sell all types of products e.g., Flipkart) Vs. Vertical (sell specialized product e.g., Pepperfry.com that sells home décor items). Again, these companies can be B2C (e.g., Amazon) or B2B (e.g., ShopX.com) Each of these models are complex and fascinating when it comes to their inventory models, sellers, logistics, returns etc. We are not here to talk about those things or their profitability model (if they have one!!!) but to talk about our area of interest - how the money is moved.

The eCommerce sector has both pay-in and pay-out use cases. Pay-in: To purchase products or wallet top up or membership fees Pay-out: Vendor payout, delivery personnel payout 1.

Channels: eCommerce merchants sell on all channels (website, mobile Apps).

If the mobile is the most dominant channel, then the merchants would expect the Payment Aggregators to provide SDKs for Android and iOS. Merchants would expect mobile friendly payment features such as optimizing bank pages, auto-reading OTP, Intent flow on UPI, save card feature etc. 2.

Payment Modes: Literally, most of the merchants follow the rule ‘more the merrier’. All payment modes are welcome to the party (CC, DC, NB, UPI, pay later products, EMIs, wallets etc.). And if the payment provider is ready to give cash back or discount then it is like a ‘cherry on top’. Only the practicality (fitment, conflict, commercials, integration & operation effort) dictates whether payment mode is enabled or not. E.g.: Furniture merchants will not need wallets but would require more EMI products. On the other hand, mobile accessory sellers would need a wallet or UPI but not EMI on cards. To increase the payment coverage and to avail good commercials, merchants work with multiple payment players (Banks, Payment Aggregators, wallets etc.).

3.

Payment flow & Integration: Customer acquisition cost is high and once the customer has decided to purchase, the payment flow should not create any hindrance/hassle for her to complete the transaction. So, the checkout page, position of payment modes, save card option, placeholder for coupons etc. - all these things matter. Merchant expects the payment provider to support flows as per their requirement. eCommerce platform plugins (e.g., Shopify, WooCommerce).

Considering mobile is an important channel so they would require mobile SDKs. 4.

Performance: Availability: payment systems should work every time and all the time. Scalability: payment systems should handle the transaction spikes (transactions tend to spike when merchants run promotional sales campaigns).

5.

Success Rate: It is super crucial as a failed transaction can be considered as loss of revenue since the user may defer the purchase or might purchase from another merchant (unless you are selling something exclusive). Refer ‘Chapter 8.F. - How to improve Success Rate’ for more details on Success Rate. Note: Before jumping into analysing the success rate, merchants need to factor-in their customer demography as well as intent of purchase as these factors also can impact the success rate, not just payment service providers involved in processing of the transactions. Also, the failures can be attributable to merchants’ own systems and payment flows.

6.

Instant Gratification: Although PG is designed to work in real time, there is a possibility that some transactions go into pending state. So, the merchant would want to know the status (Success or failed) to take appropriate action. (If success - initiate shipment, if failed - then no action required). A merchant who has the liberty to ship later can wait till the status changes from pending to success or failure. But in case of quick commerce, where delivery is done within hours then it is important to know the final status immediately.

So typically, merchants can implement an auto-refund feature where they can set a timer (5 mins or 15mins) and if the transaction doesn’t reach a finite state (success/failed) then they can initiate auto-refund and nudge users to make another payment. If a transaction becomes successful after the timer expires then that transaction will be refunded. 7.

Commercials: For B2C merchants, charges will be in percentage of transaction value (higher than what merchants of insurance, education or utility sector get). B2B merchants can enjoy flat fees on net-banking. Note: Refer Chapter 7A (for more details) Commercial model: In almost all cases, the charges will be deducted upfront from the transaction amount. Few B2B merchants may pass the charges to the buyer as surcharge or convenience fee.

8.

Settlement: In case of upfront deduction model, settlement amount = transaction amount — PG charges — GST amount — Refund (adjustment) — Chargeback (Recovered). Typically, a standard settlement cycle of T+2 will do but expectation would be ‘early settlement’. Payment Aggregator can provide early settlement to the merchant for additional charges. Note: In marketplace models, funds are settled to a nodal account and then paid to various vendors and commission amount will be moved to the marketplace operator’s account. Big merchants have built such platform, but smaller merchants can start with off-the-shelf marketplace settlement solutions offered by Payment Aggregators.

9.

Refund Management: Refunds are an important reason for the growth of eCommerce. A user can confidently buy if she knows that product can be returned easily. But refunds are a big hassle and expensive. Expensive: E.g., @1.80% MDR, merchant would bear Rs. 21.24 PG charges for products worth Rs. 1000. When refund is done then merchant not only loses Rs. 1000 worth sale but will also have to lose INR 21.24 extra as customer would want the entire Rs. 1000 back (plus reverse logistic costs). Hassle: Refunds do not have a clear TAT (Turn Around Time) as it may vary from 1 day to 7 days or more. Also, in the standard refund process, PAs won’t get to know whether the refund is credited to the payment instrument (Card or Bank Account) and at the same time, merchants need to handle customer queries about status of refund money. An alternative to standard refund is Instant refunds that can be done by processing refunds via Visa Direct, MasterCard Money Send, UPI, IMPS and NEFT rails. One simpler way is creating a closed loop wallet and a refund amount is added to the wallet. It is much faster and, also customers will be ‘forced’ to utilize that money on the same website.

10. Cash on Delivery & Refund: All said and done about online payments, still cash (on delivery) is the king. COD helped eCommerce companies grow in India. Consumers prefer cash for various reasons (lack of knowledge, comfort, lack of trust, security concern etc). That is the reason, more than 50% of the transactions still go through COD (in some sectors such as e-Pharmacy it can be as high as 70%). Handling cash is difficult and, also refunding is more complex:

Merchants try to convert COD (Cash on Delivery) transactions to POD (Payment on Delivery) by sending payment links, ePOS, mPOS or static QR or dynamic QR solutions. Refunding COD transactions is more problematic as merchants can’t send a person to return the money to the customer. Usually, the merchant will have to collect the customer’s a/c details or UPI id and then transfer the money using NEFT, IMPS or UPI rails. 11. Pay-outs: Apart from employee salaries, there are 2-3 different types of pay-outs. (1) COD Refunds (2) Seller Vendor payout (3) Delivery person incentive payout. A merchant uses payout solutions from banks or Payment Aggregators to do these disbursements. Closing Remarks

Indian eCommerce is an amazing story. It all started with Indiaplaza in 1999 (Yes, 1999) and today we have eCommerce companies of all types and sizes and with complex models which involve inventory & fund movement within and across borders. We witnessed a consolidation in this sector with 2-3 industry leaders and others operating in a niche. And still eCommerce market share is in the single digit of overall commerce in India. So, there is a growth opportunity for all types of players provided they bring some value to the table. 17.B Travel Mankind invented the wheel in 3500 B.C. and since then that wheel has been revolving. Today we have various modes of travel and when they say, ‘the world has become smaller’, it is quite true.

Once my family travelled from Walldorf (Germany) to Venice (Italy) in a cab, bus, train, flight, and boat in a single day, yes, in a single day. Thanks to multiple transportation modes and online booking facilities. There are various types of travel merchants: Operators: Companies that run the vehicles and it can be bus (e.g., VRL) or Flight (e.g., SpiceJet) or Train (Indian Railway). OTAs (Online Travel Agents/Aggregators): Companies that sell tickets of these operators (e.g., RedBus — where I can buy VRL bus tickets or MakeMyTrip — where I can book flight tickets for SpiceJet). ERPs: Platform companies who provide booking software for the operators (e.g., BitlaSoft). Travel merchants sell tickets through various channels Website/mobile App: Where users can visit and buy tickets. Agents: Who buy ticket inventory from operators or OTAs and then sell to customers (individuals or companies). Let’s talk about payments:

Payment requirements are almost the same as that of the eCommerce sector. So, refer to the earlier chapter (17.A.) for details. Here is a brief snapshot: Payment modes: Cards, Net banking, UPI, Wallets, pay later products, EMI Products etc. Seamless payment flows (checkout experience) Performance: maximum uptime and scalability

Success rate: Critical Refund management: Important especially when ticket sizes are larger Charges: Typically, same as eCommerce rates. Flat rate on Netbanking for B2B transactions i.e., when agents or companies buy inventory. Settlement: Early settlement will come in handy in case OTA or Agent has to pay to the operator to buy the inventory. Unique Requirements:

Here, I will talk about the uniqueness of travel merchants. 1.

No COD: Unlike eCommerce merchants, travel merchants do not have a COD (cash on delivery) scenario (Except for physical agent model)

2.

Instant Gratification: This requirement is super important for travel merchants.

Here is the bus that is scheduled to travel from Bangalore to Mumbai on 15th August and the bus has 20 seats. Here are the things that need to be considered

Inventory (seats on the bus) is limited (as there are only 20 seats) Inventory has an expiry date (bus is leaving on 15the August) Can’t sell the same seat to two customers (The fight it may trigger in the bus over the seat will be entertaining at some level but let’s not do it!) To maximise the sales of seats, the seats are distributed to and sold by various entities such as the bus operator (on its own website/app), OTAs and agents of operator & OTAs. So, one entity cannot block the seat for longer without receiving the payment for it. Let’s say you are booking the highlighted seat (above illustration). If the transaction is successful, then the merchant issues the ticket and if the transaction fails then the seat is released back to inventory. What will the merchant do if the transaction goes into ‘pending’ state? The transaction can’t be in limbo for long. So, the merchant will have to act. One of the ways is to wait for 15–20 mins and try to fetch latest transaction state (if transaction is successful then issue the ticket) but if transaction is still in pending state, then release the inventory and mark the transaction for auto-refund (if transaction becomes successful eventually, then it is refunded). 3.

Block and Release (Pre-Authorization): Let’s say the booking system needs to interact with an operator (E.g., IRCTC) to issue the ticket and the operator’s system failed to respond back then what will the merchant do? Merchant either waits indefinitely or initiates a refund for the customer so that the customer can book another ticket. But as you know, refunds are cumbersome and expensive. In such cases, Pre-Authorisation can be a useful feature where the amount is blocked temporarily and debited or voided depending on the

status of the operator. With this feature, merchants can avoid all refund related hassles, save on MDR (no charges for void transaction) and give a better user experience. Example: Rs. 1000 is ticket amount. MDR: 1.8% and GST: 18%

This is not a flawless solution as the solution works only on selected instruments (Credit & debit cards of Visa and MasterCard) and all issuers do not respond correctly all the time. Closing Remarks

Travel is an important and high growth sector. Although the pandemic virtually wiped-out travel business, but things will bounce back when we go back to normal as travel is an essential part of our lives. 17.C Gaming The gaming industry is way more interesting and cutthroat than people care to notice. So are the payment solutions for this industry. Let’s address the elephant in the room first - Aren’t online rummy and fantasy sports equivalent to gambling?

No - Online rummy and fantasy sports are ‘skill-based games’ as per Supreme Court and other Courts’ rulings. These types of games are exempted from Public Gambling Act (1867). ‘Gambling is betting and wagering on ‘games of chance’ but in ‘game of skill’, success depends on superior knowledge, training, attention, experience of the player but not just chance’. As per Supreme Court, ‘game of skills’ is legal, but few States have banned such games (E.g., Telangana, Sikkim, Assam, Nagaland, Orissa, Andhra etc.). Online Rummy:

Most of us have played card games with cousins during summer vacation, while travelling in trains or in our hostel rooms. The same rummy game is online where you play without money for fun or play with money to win some more money. Gaming platforms are not simple. They are designed to make sure cheating or collusion is not allowed so that everyone has an equal chance to win. Example: If I create 2 different user ids and join the game then I can see two sets of cards and have the upper hand. Such things are detected and addressed with technology and processes. Few big merchants: Rummy Culture, Rummy Circle, Junglee Games, Ace2Three Fantasy Sports:

In fantasy Sports games user will select players (cricket, football matches) and get rewarded based on the team’s performance. Scoring is done with complex logics and algorithms.

Fantasy Sports are quite big in Western Countries. Only a few years back Fantasy Sports entered India. As a ‘sports watching nation’, Fantasy Sports has seen great growth in India. Few big merchants: Dream11, MyTeam11, MPL Gaming, FanFight, MyCircle 11 Requirements for Gaming Merchants:

There are two main uses of payments:

Pay-in: User wants to deposit money to participate in the game. Pay-out: User will withdraw the winnings. Although mobile is the main channel of payments, these merchants do not put their Apps in the Play Store or App Store. As these are money-based games so Google and Apple charge 30% (or more) commission for loading of money. So, these merchants keep dummy App (non-money) on these platforms but distribute the Apps from merchants’ websites. Below are some of the requirements:

1.

Payment Modes: Merchants are ready to accept all types of payment modes. These merchants usually stay away from BNPL, cardless EMI products. Note: Although skill-based gaming is legal, still a few banks (e.g., HDFC, Axis) do not issue MID for these merchants as per their internal risk or compliance policies.

2.

Charges: Similar lines of eCommerce rates (listed in Refer Chapter 7.A) Charges are configured in an upfront deduction where merchant bears the charges.

3.

Settlement: Standard settlement time of T+2 or T+1 Days with net-settlement to merchants. Quite possible to get early settlement from Payment Aggregators.

4.

Performance & Success Rate: Both are super crucial, and these merchants are super demanding. Rummy: User wants to play at that moment (has a gut feeling that he will win). So, the transaction will have to be successful. Fantasy Sports: Users make a payment to participate in the tournament before the game starts. As it is a time-bound activity, success rate becomes crucial. Users typically start paying closer to the deadline (as human tendency is to do things at the last moment) so merchants need a robust ‘payment service provider’

who can deliver better success rates and handle the spikes in transaction volume. 5.

Refunds: Typically, not required as the user is loading the wallet and merchants expect users to play so they do not allow refunds. There is a possibility of auto-refunds in fantasy sports. If the transaction is in pending state before the game deadline, then merchants would prefer auto refunding that transaction.

6.

Chargeback: As service is consumed online so the gaming industry is prone to chargeback. So, merchants need to put in more stringent processes and clearer Terms & Conditions to defend chargeback.

7.

Withdrawal of Winnings: Users would need a mechanism to withdraw winnings or prize money. Merchant keeps the winning amount in a separate account than a deposit account. User is required to provide PAN card for withdrawal (without PAN card, TDS will be higher - Merchant gives TDS certificate that user can submit while filing Income Tax Returns). Winning amount can be withdrawn to a bank account or UPI or even wallet (PayTM or AmazonPay).

A merchant can do integration with banks or Payment Aggregator to facilitate pay-out using IMPS, NEFT, UPI or wallet rails. As mentioned earlier, few of the states have banned online gaming (including skill based). Merchant can block user based on location (not fool proof method) but, merchant can block user during withdrawal of winnings by doing the below things:

Limit pay out to only bank account of scheduled banks and allow accounts whose IFSC doesn’t belong to banned states Do not allow withdrawal to payment banks (e.g., PayTM payments bank or Indian Post) as all bank accounts have single IFSC so it will be difficult to identify the State. Do not allow pay out UPI ID or wallets (As not possible to identify the user’s State). But most merchants allow all instruments for pay-out as this industry is self-regulated. Rarely anyone will audit or complain about these. Schematic of deposits and withdrawals

Account Set-up: Merchant maintains two escrow accounts; one for deposits and one for withdrawals. Deposit: When a user makes a Rs. 1000 transaction, the payment processor will deposit Rs. 976.40 to the merchant’s escrow a/c after deducting MDR (assuming 2%) and GST amount.

Bridge the fund gap: User deposited Rs. 1000 and expects to see Rs. 1000 in wallet balance. But considering PA/PSP has deducted its fees, the merchant has to bridge the gap of Rs. 23.60 by transferring funds from its current a/c to escrow a/c. Playing: When a user participates in the game, the wallet balance will be reduced, and the amount will be moved to the merchant’s current a/c. Winnings: If a user wins the game, then the prize money is credited to ‘winning a/c’. And users can withdraw funds from this account. Merchants usually have conditions for withdrawals (e.g., few times a day or minimum threshold amount for withdrawal) You can see the complexity in the money movement and reconciliation for one transaction. Now imagine millions of users depositing, playing & winning, and withdrawing money. On top, different PGs charge different rates on different payment instruments, and may have different settlement time. That is ‘complex’! Closing Remarks

Gaming is a booming industry and pandemic catapulted the sector. Although fantasy sports took some hit as there are no real games/matches happening, but card-based games are growing. In fact, Ludo (Yes, the board game, Ludo) has become extremely popular. At present, sector enjoys the status of ‘skill-based game’ but still the industry is on thin ice. If one merchant breaks a rule, the whole industry will be criticised. So, the industry follows many steps to self-regulate and follow fair play practices. Consortiums (E.g., IFSG by Fantasy Sports merchants and All India Gaming Federation) formed by the leading gaming merchants

sets an example for best practices and engage with policy makers, sports fraternity, and society. While speaking to the Senior Executive of a gaming merchant about the importance of self-regulation and leading by example, I remembered the scene from the movie ‘A Beautiful Mind’ where John Nash said, “The Best results come when everyone in the group is doing what is best for themselves AND for the group”. 17.D Utility, Telco/DTH Because of common requirements and solutions, I am clubbing both Utilities (e.g., electricity, water board) with Telecom and DTH sectors. Utility: Electricity, Water, Gas connection e.g., BESCOM Telecom: Post-paid bills E.g., Vodafone DTH Service e.g., Tata Sky Broadband e.g., Hathaway Payments in this sector are versatile as users use various channels and various payment solutions. Below are some of the requirements:

1.

Types of Payments: Active payments: Users will make payment on the merchant’s website or App. Recurring Payments: Considering these are periodic payments, users may set-up a mandate for recurring payments on bank accounts (NACH) or cards (SI on Cards) or UPI (AutoPay). Reminder Payments: Merchants can send reminders for payments via SMS/WhatsApp or in-App notification so users can make payments.

2.

Channels: Merchant’s website or App: By integrating with Payment Aggregators or banks. 3rd Parties: Apps (PhonePe, Google Pay), physical counters (Bangalore One, Suvidha) by integrating the BBPS platform.

Here are some examples:

Samples: a.

Vodafone (Earlier site): Payment gateway (Top) and Standing Instruction (Bottom)

b.

Payment on BBPS through Google Pay (UPI)

3.

Payment Modes: All payment modes: CC, DC, NB, UPI, containers, wallets, BNPL etc. Practicality dictates which payment mode is to be enabled. E.g., Considering small ticket size, EMI on cards may not be useful.

4.

Charges: Utility sector has lower charges (Refer Chapter 7.A) Telecom, DTH and Broadband merchants technically do not fall under the Utility category but due to their size and bargaining power banks may extend them Utility sector rates. Government utility merchants are configured in the Surcharge model where MDR is passed on to the customer, but MDR is

absorbed by Telco, DTH, Broadband merchants 5.

Settlement: Standard settlement of T+2/T+1 days (again, possible to get early settlement). For the BBPS platform, settlement will be done on T+1 day. Settlement amount will be gross (in case of surcharge) or net (in case of upfront deduction).

6.

Refunds: Refunds are not frequent. Any additional amount paid to a utility merchant can be adjusted in the next billing cycle. If refund is necessary, then standard refund cycle will be followed. Utility sector works in a surcharge model. So, when the refund is marked (just in case) then the customer will not get a surcharge (+GST) amount back.

7.

Business Payments: Just like individuals, even companies subscribe to utility, telecom, broadband services (Example: Your company pays the BESCOM bill every month). So B2B payments constitute a big chunk of transactions (in value). Apart from online payment gateway, NACH (paper based as well as online), Bank Transfer (via BBPS) solutions play an important role in facilitating these payments.

8.

Multi-Account Settlement: Telecom companies operate in circles E.g., Karnataka Circle, Mumbai Circle etc. If such a model is followed, then each circle may have different settlement accounts. To enable such a model, a separate Live ID can be configured for each circle as each LID can have its own settlement bank a/c. Alternatively, enable multi-

account solution where circle wise settlement is done to respective accounts. 9.

Success Rate: How critical is the success rate for these types of merchants? Have you ever heard of someone switching from Vodafone to Airtel because a transaction failed? These are mandatory payments so the intent of payment is very high and even if a transaction fails, the customer will attempt again. Considering, a failed transaction affects the customer’s experience, so a better success rate is ‘good to have’ but not critical.

10. BBPS (Bharat Bill Payment System): BBPS is one of the important platforms for bill payment (Refer Chapter 14). Thanks to BBPS, customers can pay BESCOM, Vodafone or Tata Sky bills on third party Apps (PayTM, PhonePe, Google Pay or internet banking). 11. Pre-Paid Recharges: Most of the mobile users are on prepaid model. As name suggest, a user needs to recharge and then utilize the allotted airtime, data, and tenure. Recharges can be done directly on Telecom company’s website, nearby stores as well as on 3rd party Apps (PhonePe, G Pay etc.). Only recently, recharge is added to BBPS platform but prior that Euronet was biggest player who provided platform for 3rd party Apps. Closing Remarks

Utility (including Telco, DTH) is one of the biggest and evergreen industry verticals and payments will continue to grow. Utility merchants have multiple channels for collections — Merchant’s website/App, Agent’s website/app, and collection centres. I think, collection is not a big problem for these companies as these are mandatory services,

but a bigger challenge will be reconciliation of payments collected through various channels! 17.E Education Education is a diverse sector with various types of entities, types of payment use cases and multiple payment channels. Entities that collect fees

Institutes: Schools, colleges, Universities Coaching Centres: Allen, Aakash etc. Competitive/entrance exam boards: NEET exam, UPSC Exam EdTech Companies that deliver online courses such as Byju’s, UpGrad etc. Private Coaching classes: Unorganized and fragmented segment Integration Types:

There are few major ways, these entities do payment collections: a.

Education ERPs: ERPs are software companies that help education institutes to manage student data (information, courses, fee etc.). ERPs provide payments as value added service to the institutes. ERPs partner with Payment Aggregators, Banks, and other PSPs (wallets) on a revenue sharing model to facilitate payments.

b.

Direct Integrations: The entities (e.g., institutes) do direct integration with Payment Aggregator(s) and/or Bank (s) to facilitate online fee collection. A few of the Payment Aggregators and Banks provide lite-ERP to institutes (e.g., HDFC SmartHub and Ingenico’s Fees Junction).

c.

Bank Deposits: This is the oldest and dominant (pre-covid) channel of payments. A student/parent can collect challan from the institute and make a deposit against that in the bank. Challan is used for reconciliation (who paid and what amount).

d.

3rd Party Apps: Mobile wallets Apps (e.g., PayTM) list education institutes on their App so users can make fee payment on those Apps. These 3rd party apps can either do direct integration with institutes or use BBPS platform where BBPOU will add institutes to the platform.

e.

Cash/UPI/Bank Transfers: Private tutorial is a highly fragmented segment. Usually, private tutors collect fees in cash or bank transfers and UPI. A combination of these solutions/platforms enable education entities to collect various types of fees (admission fee, course fee, examination fee etc.) that can be one time or periodic.

Basic payment requirements for the Education sector.

1.

Payment Modes:

Credit card, debit card, net-banking, UPI, Wallets, Payment Containers, EMI on Cards, BNPL etc. — basically all are welcome! Practicality dictates which payment mode will be enabled (If ticket size is large then wallets are useless but EMI on cards can be useful). 2.

Payment Channels: Online: Parent/student pay online on website or App. Offline: Bank branches located in Institute’s premises accept cash and DD (Demand Draft) over the counter. For such offline or over the counter fee payments can be moved to online with Virtual Account solution. [Refer Chapter - 11]

3.

Charges: Education sector has a lower MDR compared to e-Commerce sector (Refer Chapter 7.A) Most of the institutes pass the MDR to the parent/student (surcharge model). EdTech companies absorb charges (upfront deduction model).

4.

Settlement: Standard settlement time of T+2/T+1 days (early settlement doesn’t have much value). Settlement amount will be Gross if charges are configured in surcharge model and Net-Settlement is done if charges are in upfront deduction model.

5.

Split Settlement: An institute may collect different types of fees (Admission fee, hostel fee etc.) and would want different fees to go to different settlement accounts. In such a case, split payment solution is ideal

Also, it is possible that an educational institute may have multiple locations (e.g., VIT - Chennai, VIT - Delhi etc.). Either institute can get a separate MID for each institute or use multi-account settlement solution. 6.

Performance & Success Rate: The importance of these two metrics depends on the fee type. Let’s say you are paying a semester fee and the transaction failed then you will retry and even if there is a delay college won’t send you home. But let’s say you are paying a competitive examination fee on the last day and the first transaction fails. Definitely, you will do a second transaction but think of your mental status when that first transaction failed. Right?? So, the importance of success rate will vary from moderate to super critical.

7.

Challans: Payment over the bank counter using cash and DD is quote prominent. For easier reconciliation, the Institute gives a challan (has unique number, student details, amount etc.) and Cash & DD are paid at the bank counter against that challan. A few of the Payment Aggregators and ERPs provide features to generate challans and the same can be used during payment across the counter. Also, Virtual Account solution (Chapter-11) can be a good replacement for challan payments.

8.

Recurring Payment: Although some of the fees (e.g., semester fee) are periodic, very rarely a parent will set-up mandates for these recurring payments. Even institutes are not that keen on pulling money from parent’s accounts on time because education is not a business (to some extent it is not true but let’s not say it loudly).

9.

Refund & Chargeback Problem: Surcharge model is quite common in the education sector i.e., parent/student bears PG charges + GST amount. Reiterating issues of surcharge model during refunds and chargeback.

Refunds can be marked for transaction amounts, not entire amount. So, when a parent asks for a refund, they won’t get the entire amount as surcharge amount is not returned. On the other hand, chargeback can be raised for entire amount (including surcharge fees). So, if a chargeback is valid then the entire amount is debited/adjusted from the institute so the institute will end up losing. More Problems with Refunds: Most payment cases in the education sector are seasonal. Example: Admission fee is paid in May-July but then no transactions till next year. If a refund is marked post the fee cycle, then the merchant doesn’t have on-going settlements to adjust the refunds. So, these merchants should define a clear refund process (whether refunds are allowed or not). Anyway, for such outlier cases, Payment Aggregators give provision of transferring funds to PA’s a/c and then mark refund. On the positive side, there are very less refunds for education institutes and even chargebacks are less. That is why this sector is considered as less risky. 10. Pay-out: Not a major use case except for EdTech companies where EdTech company needs to disburse incentives to tutors. Important Payment Solutions in Education Sector

a. Education Institute

Integration Ways: An Institute might be running multiple institutions (branches) and can have various types of fees. Below are the ways for integration with different service providers. Payment Aggregator: Integrate directly or use lite-ERP provided by PA ERP vendor: Provides an integrated payment gateway solution as well Banks: Provide lite-ERP solution, direct integration, and cash/DD collection at branches. Integration Options: Institute can have one MID to collect all types of fees. Implement split payment and multi-account settlement solutions to manage fee collection for multiple branches, bifurcation of different types of fees etc. b.

ERP Vendors: ERP vendors play an important role in the Education sector as these entities provide solutions to institutes to manage

student data, fee types, fee cycles etc. Such ERP vendors integrate with Payment Aggregator(s) and bank(s) to enable online payments.

PG Charges: ERP vendors are not educational institutes but software companies, so they do not qualify for the PG rate (MDR) that is given to the education sector. To avail such lower rates, ERP vendor needs to prove that PG is used on-behalf of institution (undertaking letter from the institution) or, Let institutions procure MID from Payment Aggregator or bank and configure that in their ERP system. Integration Type: ERP vendor needs to support different types of payment flows depending on institutions requirements. Example: Single MID, multiple-account settlement, split payment etc. Settlement:

Direct: Settlement is done directly to the Institute’s account (most popular method). Escrow A/C: ERP vendor gets the settlement into its escrow a/c (or nodal a/c) and then disburses it to institute after deducting its commission. Revenue Model: ERP vendor makes revenue from online payment services (over and above core ERP revenue). There are different revenue models: Surcharge model: Add small mark-up fee above PG charges (+ GST) and mark-up amount is credited to ERP provider (Call it convenience fee). Invoice to Institute: Instead of adding mark-up, ERP vendors will raise invoice to institute. Partnership model: ERP Vendor can strike revenue sharing arrangement with Payment Aggregator or banks. c.

EdTech Companies: New-Gen companies that are democratising education by delivering content to users over the internet. They offer tutorials for Class-X students (E.g., Byju’s) till courses in Artificial Intelligence (E.g., UpGrad). Either they create the content or run courses on behalf of the institution. Integration: Standard online Payment gateway integration through Payment Aggregator(s) and direct bank(s) on various channels (website and App). And all types of payment instruments are allowed. If there are periodic transactions, they prefer using recurring payment solutions (E.g., Standing Instruction on Cards).

MDR: Although these are no education institutes, they get MDR of the education sector. It is not a straightforward case but considering their volume, Payment Aggregators and banks may relax their rules. Typically, they do not work in a surcharge model but absorb the MDR. d.

Examination Boards: Competitive exams are conducted by Education Boards. Example: NEET, Nursing Exam or CBSE. Integration: Directly integrate with Payment Aggregators or banks. Few Payment Aggregators give a simple form that can be used to capture applicant’s details along with various payment options (e.g., BillDesk). Examination platforms: These companies provide solutions to conduct examinations along with integrated payment solutions (E.g., Merittrac, Manipal Technologies). Such companies conduct various examinations on its platform so either they use a single MID with different scheme codes per examination or procure individual MID for each examination, depending on time and effort.

Closing Remarks

With 250 million school going students and 36million students enrolled for higher education, the education sector is worth $100Billion value. Apart from the institutes, professional certification, MOOC (Massive Open Online Courses), coaching, test preparation etc. are rising. The Pandemic affected this sector very differently. Teaching & learning is moved online and so are the payments. Surely, one day kids will go back to physical school and youngsters hang around the college campus, but the

question is whether the payments continue to be digital or move back to offline. 17.F Insurance Two Scottish men, Robert Wallace, and Alexander Webster came up with the idea of Insurance in the 18th Century. The idea was simple: Build a fund by collecting small periodic amounts (‘premiums’) from policyholders and give a one-time settlement to the policy holder’s widow (in-case of death). Invest collected funds for good returns so that claim amount is settled from returns on the investment while keeping fund corpus intact. Over the centuries the assessment of risk, investment methods, things that can be insured have evolved but the concept remains the same. I pay Rs. 20,000 per year for health insurance for Rs. 5,00,000 coverage. I may pay this premium for decades but may never claim any amount and it is also possible that I may claim the cover amount within 4 years of premium payment. To be in business, insurance companies need to make sure outflow is lower than inflow. To reduce risk of outflow, insurance companies decide on whom to give insurance (e.g., health insurance to octogenarian) or qualify the person (e.g., medical check-up to issue term policy) or add preconditions to the policy (e.g., pre-existing diseases are not covered) or increase the premium amount to compensate for risk (E.g., a smoker pays more premium than a non-smoker or 40-year person pays more premium than a 25-year-old). Common trait between ‘Insurance’ and ‘Payments’

Why a utility company has lower MDR than eCommerce company or why POS merchants enjoy lower MDR than online ticketing merchants is exactly, the same reason why non-smoker pays less premium than a smoker or why old person pays more premium than young person.

In summary, MDR (of payments) and premium amount (of insurance) are ‘risk adjusted’. In India, the Insurance sector is governed by IRDA (Insurance Regulatory and Development Authority). There are two main types of insurance: (1) Life and (ii) Non-Life (General). General Insurance can be for health, vehicle, property, travel etc. There are three types of entities: Insurers, the companies that underwrite the risk or in common language the companies that give you insurance (E.g., LIC, HDFC Life, Acko). Web-Aggregators, companies that sell insurance policies of Insurers online (E.g., Coverfox) Brokers: Specialist in insurance who sell insurance both online and offline (branches) (e.g., Mahindra Insurance Brokers) Below are the requirements related to Payments:

1.

Use Cases: Pay-in: There are two main cases for payments: (i) Policy purchase (ii) Policy renewal (periodic)

Payout: Disbursement of claim amount and incentive payout to agents Insurance is an ideal sector for, Active Payment: User actively pays (Solution: Payment Gateway) Passive Payment: Customer sets a recurring mandate for periodic policy renewal (Solutions: NACH, SI on Cards) Reminder Payment: Merchant can send payment link to user via SMS/WhatsApp/mail for policy premium payment.

But think before opting for these solutions. For example: If the periodicity of payment is once a year then will a customer set a recurring mandate? Maybe not. 2.

Channels: Insurance companies deploy multiple channels for policy purchase and renewal: website, app, web-aggregators, and agents. Even web-aggregators and insurance brokers have their own Apps, website, or agents. Payment solutions should cover these channels. Both online and offline payment solutions are deployed for these channels to cover first time and recurring payment use cases.

Agents collect cheque. Agents also have App to facilitate payments on premise Think of it, mobile Apps are not an important channel considering the customer needs to fill in a lot of details during policy purchase, so a desktop/laptop is a better channel. Also, you pay a premium either once or twice a year so why will you install an App that has very less utility. 3rd party Apps: Insurance premiums can be paid through Third party Apps such as PhonePe, PayTM etc. Insurers are on-boarded on the BBPS platform by BBPOU, and customers can make premium payment on these 3rd Party Apps. Transaction charges (PG charges/MDR) will be borne by the 3rd party Apps and Insurance company will give a flat fee per transaction to BBPOU. Considering, agents are keen on driving transaction counts irrespective of cost, so it is a promising payment channel for Insurers. 3.

Payment Modes: Cards, EMI on Cards, Net-banking, UPI, wallets, cardless credit products are allowed. Decision to enable a payment mode is dictated by practicality. Example: If ticket size is small then EMI on Cards is not useful but wallets are useful, but if ticket size is big then wallets are useless but EMI on cards will be useful.

4.

Saving Card/Vaulting Card: ‘Card Vault’ is a useful feature for periodic transactions. Although the insurance sector has periodic transactions, if the periodicity is longer (e.g., once a year) then ‘vaulting card’ has not much use.

5.

Charges:

Lower rates on credit cards and flat fee on net-banking (refer Chapter 7-A) PG charges are either passed on to customers as surcharge (E.g., LIC, till recent times) or absorbed by merchants (E.g., HDFC life) or hybrid model (e.g., credit card charges are passed to customer as surcharge and merchant will absorb net-banking charges). 6.

Settlements: Standard settlement time of T+1 or T+2 days is followed Settlement amount is either gross (for surcharge model) or Net (for upfront deduction model). Insurance companies may want product wise settlement. Example: Vehicle policy should go to a different bank account than health policy. This can be achieved either with multi-account settlement or by simply, configuring different Live ID for each type of insurance.

7.

Refunds: Insurers allow cancellation of policy by customer within a specified period, or it is possible that the insurer may not issue the policy to customer (if pre-conditions are not met e.g., health check-up for term policy). And considering ticket size is big, refunds need to be efficient. Pay out solutions using NEFT, IMPS, UPI, Visa Direct and Master Money Send can be used to initiate faster refunds.

8.

Performance & Success Rate: To buy a policy, the user needs to fill lot of details and after completing all formalities if the transaction fails then you have an angry customer who may defer buying.

Large number of policyholders do not renew policies so if any user intends to renew her policy, then payment shouldn’t fail. But policies are purchased or renewed based on other criteria (insurance company, coverage, claim settlement ratio etc.) so even if a transaction fails a customer will not switch immediately to different insurer as intent of purchase is high. Overall, success rate is important but not critical. 9.

Pay-out Use Cases: Agent incentive: Agents are important sales channels for insurers and brokers. These agents receive sales incentives. Payout solutions offered by banks or Payment Aggregator can be used to disburse such incentives efficiently. Claim Settlement: Policy holders may receive interim bonuses or coverage amount is paid or maturity amount is given to the customer. These disbursements can be done using pay-out solutions of bank or Payment Aggregators. Many times, claim settlement is done by insurer’s TPA (Third Party Administrator) and not by the insurer directly.

Closing Remarks

Is insurance a seasonal business? Yes, in a way it is seasonal business. Insurer’s sell maximum number of insurances (especially, life or term insurance) during Jan-Feb-March ( JFM) months. Reason: Insurance premium is exempted for tax deduction. So many people buy insurance to save tax. And as humans, we like to do things just before deadline.

India is one of the under-insured countries in the world. This means there is a huge scope for growth. The sector suffers issues such as high customer acquisition costs and lower policy renewals. Government of India has rolled out various insurance schemes for its citizens as well as agriculture produce. Vehicle insurance is also mandatory document. Covid-19 triggered panic made many people to buy health insurance. My friend who used to sell 50 odd insurances in a year sold more than 1000 policies in few months. As the sector is moving towards ‘digital’ with paperless on-boarding (including KYC verification) till claim settlement, online payments will play a crucial role in this sector. 17.G NBFC NBFCs (Non-Banking Financial Company) are licensed entities and regulated by the RBI that give different types of loans to consumers and companies. There are thousands of NBFCs that give different types of loans. There are mainly two types of loans: Secured, that is backed by collateral (e.g., gold loans) or unsecured, without collateral (e.g., personal loans). Plus, there are FinTechs who are into lending without being NBFC. Basically, they ride on their partner NBFC’s license. Onus of customer acquisition, loan disbursement, support and collection belong to FinTech. Two things happen when you take a loan - you will bear interest charges and you need to repay the original loan amount either in instalments or one time. So NBFCs also need effective mechanisms to collect these instalments. Requirements for NBFC Sector

A customer’s engagement with NBFC starts with customer on-boarding, then disbursement of loan and then collection. 1.

Disbursement Cases: The first leg is customer on-boarding, where the customer is approved for loan by checking certain criteria (e.g., CIBIL score) and KYC documents. Once the loan is approved then disbursement is done to the customer’s bank account. There are two solutions: Beneficiary name validation: Do penny drop (using IMPS, NEFT) to check whether customer’s name as per bank records is same as per KYC documents. Loan Disbursement: Use IMPS, NEFT to disburse loan amount to the customer.

2.

Collection Cases: As these are periodic payments so recurring payment solutions are important. A mandate can be registered during customer on-boarding: NACH (Paper based): In case there is a physical touch point with the customer.

eNACH (online) and UPI AutoPay: for digital on-boarding. Note: SI on cards is not an ideal solution as credit cards are not allowed to repay the loan amount. In case of delinquencies or late payments, the provision to pay through online Payment gateway or across collection counters of NBFC should be available.

Loan repayments are obligations, so it is important for NBFCs to have control on collections. ‘Section 25 of Payments and Settlement Act’ safeguards merchants in case of dishonour of NACH mandate. In short, NBFC can file court cases against customers under section 138 of The Negotiable Instruments Act (1881) in case of mandate debit fails due to insufficient funds. This is like a cheque bounce offence. NACH debit failure in case of Mutual Fund SIP or insurance premium is acceptable as these are voluntary payments, but loan repayment is an obligation. As said earlier, it is important for an NBFC to have control on collections so recurring payments are the primary solution and PG is the secondary. So, PG is used (a) Delay is mandate registration (2) Mandate debit failed due to insufficient balance, but customer is okay to pay using another account.

Virtual accounts [Chapter 11] can be a good solution to do the repayment. 3.

Channels: Physical: It can be an NBFCs office or agents. Considering the customer touch point is strong as the customer needs to submit other details (fill form, submit KYC documents), NBFC can sign up for a paper based NACH mandate. Online: Considering NBFCs are moving digital (online customer on-boarding) but still the customer touch point is strong so eNACH can be registered during on-boarding.

4.

Payment Modes for Collection: Only debit cards, net-banking and UPI are allowed for repayment. Payment Solutions based on bank accounts such as NACH, eNACH, UPI, and PG are deployed. Credit Cards are not allowed as you can’t pay one loan with another loan (directly). Wallets are not allowed as a source of wallet balance can be credit cards.

5.

Charges: For Debit Cards, RBI Standard rate, or flat fee (by few banks), for Net-banking is flat rate and UPI & RuPay DC are free (used to be flat rate earlier). (Refer Chapter 7.A) Charges are typically passed on to the customer (surcharge) but there are cases where merchants may bear the charges or opt for hybrid models (e.g., debit card charges are passed on to customer as surcharge and net-banking charges are absorbed by the merchant).

Charges on recurring payment solutions (NACH, e-Mandate, UPI AutoPay) will be a flat fee that can be either passed on to the user or invoiced to the merchant. Charges of pay-out solutions will be flat rate (NEFT, RTGS) or slab wise flat rate (IMPS) 6.

Settlement: Merchants may receive gross-settlement (for surcharge model) or net-settlement (for upfront deduction model). Settlement time is standard T+2/T+1 days. Few Payments Aggregators may offer early or instant settlement for an additional fee. Note: Early settlement can be useful for NBFCs/Lending companies as they can disburse more loans from collected amount.

7.

Refunds: Not much of a use as extra payment paid (by any chance) by a customer will be adjusted either in principal amount or in the next instalment. Also, there are offline processes for returning money through pay-out.

8.

Success Rate: Intent of payment is high as customers may face bad credit score, penalties or even Court Cases. In case of recurring payment solutions, the merchant has control to re-run the mandate if it fails the first time. And in the case of online PG, customers will retry if the transaction fails. If collateral is involved against the loan, then the NBFC is anyway safeguarded against risk of default (assuming value of collateral is

higher than outstanding amount). So, you can say that the success rate is not that critical for this sector. 9.

Compliance for Disbursement: NBFCs’ cannot simply disburse the money from any account. They will have to disburse it from a dedicated account and, also collection (repayment) should be settled to a dedicated account.

In the FinTech lending model, a FinTech will lend the money using NBFC (they ride NBFCs license). So, the funds need to be disbursed from the account of NBFC that is opened for this arrangement and collection should be settled to the account that is earmarked for the arrangement. Closing Remarks

India is an underserved country when it comes to credit. Banks still remain the main entities for lending (that is why banks are always referred to as ‘lenders’). NBFCs are doing some good work in this area. The third players are new-gen FinTechs. Lending is a profitable business (that is why loans are called ‘assets’). Giving money is easier (as people need it) but collecting is not. So, banks/NBFCs use different strategies to firstly reduce such cases by on-boarding ‘right customer’ and give ‘right amount’. And then use different tactics to collect money. Opportunities in the lending sector are quite evident, and we are already witnessing different types of lending models. Lending is one of important products in BaaS (Banking as a Service) offerings. I am sure, we would be witnessing boom in interesting busines models and as the sector grows so do the payments for the sector to facilitate disbursement as well as collections.

17.H Mutual Fund Mutual Funds (MF) collect funds from investors and invest in equity and/or debt. MFs are interesting and complex investment vehicles as there are different flavours (Equity, Debt, Hybrid), various types of entities (AMC-Asset Management Companies, Mutual Fund-Aggregators), and different types of investments (regular or direct). Overall, an interesting sector. If you are interested in knowing more about MF, then start here: www.amfiindia.com All regulated investments (MFs, equity markets) are governed by SEBI (The Securities and Exchanges Board of India) Payment Use Cases in MF:

An investor can invest in an AMC directly by opening an account with the AMC (Aditya Birla, Mirae Assets etc.) or invest in AMCs through MFAggregator (Zerodha, FundsIndia etc). So, AMC and MF-Aggregator need a payment mechanism to facilitate investments. Key requirements of MF Industry

1.

Payment Use cases a.

SIP (Systematic Investment Plan): Users can pay a fixed amount on a periodic basis. This fixed amount can be increased or decreased. Both eNACH and NACH recurring payment solutions can be implemented.

b.

Ad-hoc Purchase: Investors can invest in a MF on an ad-hoc basis. Online PG offered by Payment Aggregator or Bank can be used to facilitate transactions. Also, recurring payment solutions (with periodicity ‘as and when presented’) can be used to debit existing mandates. Note: Virtual Account Solution [Chapter 11] can also be a good solution for MF merchants who have a business model where users can load their MF-wallet

c.

Tertiary Use Cases: Payments towards user registration or advisory services fees can be paid using standard online PG with all modes (CC, DC, NB, Wallet, UPI etc.).

Use Cases and Solution Mapping:

2.

Payment Modes: Payment instruments that are based on bank account are allowed i.e., net-Banking, UPI, and Debit Cards. Credit cards, wallets and other alternate credit card products are not allowed. Note: At one point SEBI was deliberating to allow MF purchase using wallets provided the source of wallet funding is bank account or debit card (complicated to implement and useless).

3.

Third Party Validation: As per SEBI guidelines, the investors should purchase the MF or Shares only with the account that is registered with AMC or MF aggregators.

TPV feature is supported for net-banking (30+ banks) via few PAs. UPI TPV is same as regular UPI transaction (collect or intent) but once the amount is debited then account check is done. If registered account is different than transacted account, then amount is credited back. This is check is done by acquiring bank or Payment Aggregator. TPV is not possible on Debit Cards - So most of the investment merchants do not allow debit cards. Merchants who allow Debit Cards are expecting investors to comply with guidelines (use the debit card of the registered bank account) and pass the liability/penalty (if any) to investors. In recurring payment solutions (NACH, e-NACH) the account validation can be done during mandate registration. 4.

Settlement Time & Types: AMC/MF-Aggregator can pool the amount to nodal account and then credit the relevant AMC’s account — Single settlement account will work.

To settle funds directly to AMC’s account, bank/PAs need to support split payment. From time-to-time SEBI defines cut-off times, ideally the AMCs/MF Merchants expect settlement accordingly. Settlement time may vary from the same day to T+1. 5.

Commercials: As per the guidelines, the entire amount should go towards investment. So, merchants have two options: Option 1: Merchant will bear the charges. But as charges cannot be deducted upfront from investment amount so charges will be invoiced to the merchant, Option 2: Surcharge the customer wherein the customer will bear the charges. For the MF sector the charges will be Flat Fee (Refer Chapter 7.A.)

6.

Refunds: There are no refunds - Refund is as good as withdrawal of MF but that is a different process.

7.

Performance & Success Rate: In the case of MF merchants, the intent of purchase is high (meaning: If transaction fails then customer will retry again). Success rate is important as proceeds go towards investment and a delay can change the value of investment.

8.

One Time Mandate: IPO (Initial Public Offerings) are important events for investors. Investor will apply for an IPO (bundle of shares) and pay the required amount. If shares are allotted, then it is fine else the paid amount is refunded.

UPI 2.0 provided a one-time mandate where the amount is blocked and then released. This solution is ideal for IPO subscriptions. Only problem is the maximum transaction amount for UPI is Rs. 1,00,000 (again, which can be lower for few banks). 9.

Pay-out Solutions in MF Withdrawal: When investor triggers Mutual Fund withdrawal or when AMC needs to distribute dividend then AMC pushes funds to customer’s accounts: NACH-Credit solution allows merchant to push money to investor’s account. Alternatively, merchant uses IMPS/NEFT/RTGS to push money to investor’s registered A/C.

Closing Remarks:

Many companies are interested in tapping into the regulated investment sector. Apart from traditional distributors and AMCs, there are more than 100 FinTech companies that are working in this space. MF is one of the largest and growing industries. Industry doesn’t rely on cash-back or discounts to attract customers and, also customer stickiness is higher. Couple of years back, one of the leading Payment Container company’s alliance heads rejected my views on the MF industry and now the same Company has launched MF buy/sell on its App. Maybe it took time for companies to realise that there is a sector that can be captured without burning investor’s money. Like I said earlier, investments (Mutual Funds and Stocks) are interesting and complex and so are the payments in this sector.

Chapter 18

BaaS (Banking as a Service)

Do you know that the price of a Big Mac burger can be used to calculate the Purchasing Power Parity (PPP) and thus, determine whether a currency is undervalued or overvalued when compared to the USD? It is called ‘Big Mac Index’, an interesting concept, not accurate, but still an interesting concept. Talking of burgers, I am craving for a McSpicy Chicken Burger, and I have three options: (1) Go to the nearest McD outlet (2) Order on the McD App (3) order on a food delivery App. Each of these models have their own pros and cons (Refer below):

The model that we are more interested in is the third one. The burger is from McD (quality, quantity is controlled by McD) but the distribution and customer acquisition belong to the food delivery App (remember this point!).

Let’s start with the BaaS that we are interested in talking about — ‘Banking as a Service’. The fundamentals of BaaS are the same as the burger model — there are products that need to reach customers via distribution channels. We will eventually get to BaaS but before that, let’s touch upon a few basics. Banking Products and Services:

Below are some of the standard banking products and services that we are familiar with.

Bank’s Distribution Channels:

Branches: For long, branches have been the main touch points. Branches are the place for sales, customer engagement, cross-sell and everything related to customers. Branches drive linear growth — so to increase growth, a bank needs to add more branches. That means additional costs related to real estate, operations, and resources. (Same as the McDonald’s outlets) Digital Channels (Website/App) With penetration of the internet, even banks adopted ‘Digital Strategy’ wherein Banks’ websites/App allowed consumers to engage with the banks. (Same as McDonald’s App). The above two models are very straightforward but is it possible to replicate a third model, where third parties can sell banking products? Yes, that is what BaaS is about, where banking products are sold to customers via third parties who can manage customer acquisition and

distribution, but the bank controls the product and its attributes including governance, compliance. Who are these Third Parties?

Any entity that is interested in extending a bank’s products or services to its customers (SMBs, corporate or retail), partners (delivery personnel) or vendors (e.g., seller or restaurants). Some of the usual suspects are: Payment Aggregators Neo banks and FinTechs Merchants and Corporates API platforms/Technology Service Providers (TSPs) I will talk about each of these entities in detail in the next section. For now, let’s move on to the next point. How do they achieve this?

APIs - Yes, “APIs”, one of the overused and over pitched words of FinTech/Payments’ world only next “Reduce the commercials”. Every sales deck of every Payments company will have pitches such as ‘Powerful APIs’, ‘Simple APIs’, ‘deep integration APIs’. API (Application Programming Interface) allows one system to communicate with another system. Through APIs data can be exchanged. APIs are simple to understand, implement and manage. Note: Check Reference chapter for useful links about APIs BaaS will work in two steps:

Step 1: Banks develop APIs for its product or services and externalise them so third-party partners can use those APIs. Through APIs, banks will govern the product. (E.g., Bank’s UPI APIs to a payment aggregator won’t have the check account balance API but banks offer it to UPI Apps). Note: Do not expect all banks to have ready-made APIs, although a few banks have made substantial investments in developing APIs for third parties but few of them have not. Plus, a few banks are flexible but quite a few are rigid for any customisation. Step 2: Third parties can consume the APIs and launch banking products. As usual, there are multiple ways one can go about it. A merchant can integrate with the bank API directly, but efforts will increase if the merchant wants to add multiple banks. Alternatively, a merchant can use a Payment Aggregator or TSP’s API who in turn would have integrated with multiple banks. (As I always say… think of Russian Nesting Dolls whenever you think of FinTech or Payments). A bunch of APIs and Processes should work together to launch a single product. Let’s take example of a savings account:

The idea is to give you an understanding that banking products are not simple. For years, we have been using our bank accounts and do not think about how things work in the background. When you start thinking of lending products, the process becomes more complex as more financial aspects (cost of capital, underwriting) and collection aspects kick in apart from customer qualification (credit check). Governance and Compliance:

As we are talking about banking products here that follow high governance and guidelines by the regulator, every bank has its own risk & compliance frameworks; banks make sure the APIs are exposed as per the compliance framework and third parties follow the processes. Third Parties

As mentioned in earlier section, these entities are interested in extending banking products to their customers, partners, and vendors. Usual suspects are: A.

Payment Aggregator (PA)

PAs have built their businesses on the bank’s collection (Payment gateway, recurring payment, UPI etc.) and disbursement services. PG is a two-decade old story and pay-out has been out there for quite a few years. So, BaaS is not new to them. But PAs definitely want to use BaaS to extend their portfolio of services and offer banking products to their merchants.

In a regular Payment Aggregation model, a PA will facilitate collections from customers and do settlements to merchants. But in the BaaS model, a PA can provide additional banking products (refer above illustration) to merchants. These offerings can be explicit or implicit. Explicit Offering:

Opening current account for the merchant during sign up for payments solution Issue corporate credit card to the merchants Implicit Offering:

A PA can bake these banking products in their core offering) Early Settlement offered by PAs is nothing but credit to the merchant and recovered from the next settlement. Overdraft facility to do vendor payout and adjust amount from next settlement.

As a Payment Aggregator knows its merchants better (Vintage of the business, business types, risks, chargebacks, settlement cycles, settlement amount etc.), they can position the products as per the merchant’s business & requirements. B. Neo Banks

These FinTechs offer banking products/services without being a bank or having branches like a traditional bank. As we know, there is no silver bullet for all the problems and for everyone. So, the Neo-banks target specific demographics or cohorts such as couples, families, teens, women, freelancers, blue collared workers, SMBs etc. Neo-banks take standard products from the bank(s) and then stitch features that address problems of their customer base and add value to their customers. Many neo-banks are mushrooming these days. I recommend you check their websites to understand how they are different. How they have built their products and positioning products to their target customers. Few of the visible neo-banks: open.money, Jupiter.money, Fi.money, FamPay etc. Note: These are not real banks, and they can’t call themselves ‘banks’ as restricted by Section 7 of the RBI’s Banking Regulation Act of 1949 C.

Merchants/Corporates

Anyone who has a captive user base or vendors or service partners, can offer banking services to them. These entities can be Lending Techs, WealthTech, FoodTech, KiranaTech, Travel OTAs, eCommerce marketplaces, Auto makers or even Corporates. Let’s take example of an eCommerce marketplace.

In standard model, marketplace is collecting money from customers and then doing pay-out to vendors and delivery persons. Refer top diagram in illustration below) But in BaaS model, an eCommerce marketplace can sell various banking products (e.g., co-branded credit card to customers, lending product to vendors, an insurance to delivery person etc.) (Bottom diagram in the illustration below)

A merchant/corporate knows (have data pointers) its customers, vendors, and partners better than anyone. So, they can do a better job at selling banking products to them. I am sure every company had scope to introduce banking products in its ecosystem. Let me rephrase the statement — any merchant, company or corporate can become FinTech but the road to achieve this may vary. Here is a simple chart to show it.

The transition is simple for Digital ‘heavy’ companies, but it may take longer time for traditional & non-finance companies, but it is very much possible if they have intent to head in that direction. This trend has already started with examples such as: MoneyTap (a digital lending company) transitioned to Freo.money (Neo bank) Flipkart’s own Buy Now Pay Later (BNPL) product Groww (Investment platform) offering Fixed Deposit A merchant or Corporate can directly work with the banks or use Payment Aggregator’s services to offer banks’ products or use API provider/TSP to enable the services. D. API Providers/TSP

These entities unify APIs of bank(s) and then offer to third parties (Payment Aggregators, FinTech or merchants). They help the third parties with faster GTM (basically, ‘build Vs. buy’).

Illustration above shows that a TSP can offer all types of services (in theory, yes) but that is not the case. TSPs are not one stop shops — Some are generic who offer array of products from multiple banks, but few are super specialised in what they offer. You can also refer Chapter 15 to know more about different types of TSPs. What do these third parties know or do which a bank cannot?

“That is a very good question” (pat on your back). Banks have been around for centuries. I am sure they know how to sell their products, and, over decades, they would have learnt a thing or two about their customers. Let us not make the mistake of assuming that banks are monoliths and slow entities. Remember banks are the one who are building APIs that are backbone of BaaS. Before we answer above question, let me list strengths of these third parties: 1.

Technology: These companies will invest in technology that is aimed to deliver better user journeys, custom features, dashboards, and analytics.

2.

Accessibility: Some of these entities (Merchants and payment aggregators) already have existing users, so distribution is simple (i.e., customer acquisition cost is lower).

3.

Data: Merchants/PAs are sitting on a lot of customer, vendor, and merchant data. This data can be leveraged to make decisions when it comes to customising product features, lending decisions etc.

4.

Brave: These third parties have an appetite to take risks which a bank may not have. These entities are ready to challenge norms, ready to invest big bucks (thanks to funding) and capture the market faster.

Now, the answer to the above question is Banks want to leverage capabilities of third parties to fuel their own growth. Just like how McD doesn’t mind using food delivery Apps to sell ‘more’ burgers. Plus, banks also keep doing what they do best, and they won’t shut down their own distribution network (branches and App). Great… but why do it?

There is a market which is underserved (in terms of distribution, product, experience, pricing etc.) — so there are definite growth opportunities. Someone has more data/info than the other — so work together to increase the size of the pie. E.g., a bank has money to lend but a marketplace knows its sellers better. Thus, this data can help banks to underwrite better). I have saved the best one for the last - Money Banks share revenue (revenue sharing models, referral model etc.) with the third parties. So, these parties can create a substantial revenue stream from these services. For some entities this is the main revenue (e.g., Neo banks)

but for few it can be an additional revenue channel (e.g., eCommerce merchants). Interesting… how much money?

This is where it becomes tricky. Revenue share depends on various factors: Responsibilities of parties (distribution, customer on-boarding, support) Risk (who is underwriting — in case of lending) Bargaining power of the parties Payments, banking or FinTech is a game of ‘scale’, the more the active customers, the more the volume if more the volume, more revenue. And companies can bring down costs to increase the profit (if the idea of a company is to ‘generate profit’). Embedded Finance

I am sure you might have heard this jargon. Without getting too much into details, in simple words, embedded finance is about offering (or embedding) financial products (e.g., UPI, insurance, credit line) in the user journey. Examples: While booking international tickets, enable users to buy travel insurance. While sending an invoice to your buyer, create a virtual account for the buyer so they can pay against it (for easier reconciliation). On-board user on BNPL (Buy Now Pay Later) product while doing the purchase.

What is new about it?

Mostly, nothing. This has been done for years but as a part of cross-selling. But in embedded finance, you offer them as part of the integrated user flow. So ‘the new’ part is reimagining the product, process and user journeys while taking care of compliance and risk. It is more complicated than I made it look like as there are a set of processes that need to be embedded without distorting the user’s original journey. Otherwise, users will neither book a ticket nor buy your insurance. Closing Remarks

Market size, smartphones, internet penetration, data, AI/ML, and custom requirements of customers everything is coming together but most importantly, finally we have come to realise that while banks are a bit boring, they make money (most of the time). So, everyone wants to look like a bank and sell banks’ products and services to make money. But still, they have a mammoth task of bringing customers to the platforms and the next

‘bigger mammoth’ task is retaining customers. This is not as easy as it sounds as it involves changing customers’ behaviour. Still, a word of caution, there is one thing banks fear is compliance and risk. So, it is the responsibility of these third parties (FinTechs, merchants, TSPs) not to deviate (cut corners) for the sake of growth as one’s mistake may cost others or the entire ecosystem. BaaS, neo-banks, embedded finance, and invisible finance - All these names sound fancy and interesting. But will they succeed in this uber competitive and highly regulated environment and on top, satisfy customers with unpredictable user behaviour/requirements who are extremely price sensitive. But as they say, “the proof is in the pudding”. So instead of getting impressed by funding stories, we should wait and watch whether these companies really make a difference in user’s banking experience or just end up creating lot of confusing banking products. I feel this space is exciting, exhausting, boring and interesting - all at the same time!

Final Chapter

It would be unfair to say that I planned to be in the payments domain as I somehow knew that it would be an exciting and growth driven sector. No. It just happened! But I made the best of what I got. I was lucky that I found amazing mentors, wonderful colleagues and friends in banks, merchants, and even at competition companies. Similarly, when I started to blog about payments, I didn’t know that it would be appreciated by wonderful people such as yourselves. Your support motivated me to publish the book. Converting the blog articles into a book is an amazing experience - but now I am at the last chapter, I do not know how to end it. A predictable way would be, to write about the growth of payments in recent years, how the future of payments will be, and add some reports and fancy graphs. I bet those are available on the internet. Just like life, even the payments domain is unpredictable at times. So based on the theme of ‘unpredictability’, I am ending this book in an unexpected way. A quiz - yes, a mini quiz on the Payments domain. Hope you will enjoy it. 1.

A successful transaction is done on 7-Feb-2019 on Credit Card. Transaction amount = Rs. 1600, Credit Card rate = 1.80%. Merchant is configured in the ‘upfront deduction’ model. What will be the

settlement amount? Also, when will the settlement be done to the merchant if settlement time is T+2 days? Rs. 1566.02, 11-Feb-2019 Rs. 1571.20, 11-Feb-2019 Rs. 1571.20, 9-Feb-2019 Rs. 1566.02, 9-Feb-2019 2.

Which of these statements is NOT CORRECT about card transactions? CyberSource PG can process card without validating CVV2 Only card number, expiry date and CVV are stored during ‘card vault’ 2FA is not mandatory for contactless payments up to Rs. 5000 CVV1 is validated at POS, CVV2 is validated during online transaction

3.

Which of these statements is NOT CORRECT about merchant sectors? As per RBI regulation, Education Institutes have lower MDR on credit cards compared to eCommerce merchants. Various courts have exempted Online Rummy sector from Public Gambling Act of 1881. Credit Cards are not allowed for Mutual Fund and NBFC merchants. Utility companies are less risky, so the MDR is lower compared to travel merchants.

4.

Which of these statements is NOT CORRECT about BBPS? My Vodafone post-paid bill is shown on G Pay because of BBPS.

BBPS is evolved from EBPP platform that was developed in year 2000-2001. BBPS can be used by physical bill collection agents such as Bangalore One or Suvidha BBPS is only for utility companies and Telecoms but not for Education institutes. 5.

Which of these statements is NOT CORRECT about the ‘success rate’? Customers’ intent of purchase does influence success rate. Features such as UPI intent and card vault do improve the success rate. There is one universally accepted formula to calculate success rate. Importance of success rate varies for different sectors.

6.

Which of these statements is NOT CORRECT about UPI? One user can create multiple UPI IDs on different UPI Apps. UPI operates on IMPS rails. NPCI does direct settlement to merchants (As UPI is operated by NPCI). UPI allows a person to transfer money to beneficiary’s account even if beneficiary doesn’t have an UPI Id.

7.

Which of these statements is CORRECT about refunds? Once the refund is marked successfully by payment aggregator then the refund amount reaches customer’s account or card on T+2 days. Refunds are adjusted from merchant’s settlement amount. Refunds are expensive as the acquiring banks charge a fixed fee from the merchants.

Refunds can be initiated up to 13 months from the date of the transaction. 8.

Which of these statements is CORRECT about recurring payments? Recurring payment solutions can be used only if debit happens periodically (weekly, monthly, quarterly, semi-annually, annually). It is mandatory for recurring payment solutions to send pre-debit notification to the customers. To safeguard the users, the upper limit per debit is Rs. 5000 for all types of recurring payment solutions. Any exception cases require approval from RBI. Charges for recurring payments can be percentage or flat fee depending on the solutions.

9.

Which of these statements is NOT CORRECT about pay-out rails? NEFT, IMPS works in real-time and 24x7. It is possible to transfer funds to a credit card using IMPS and NEFT rails. IMPS is real time, but actual inter-bank settlement is done in batches. RTGS is done only if transfer amount is Rs. 2lakh or more.

10. Which of these statements is CORRECT about QR Codes? UPI QR code allows user to transact using RuPay debit cards as UPI and RuPay are managed by NPCI. In dynamic UPI QR code, the amount can be added during transaction. Static QR, by definition, used only for one-time payment. PhonePe App can be used to Scan (& pay) only PhonePe issued UPI QR Code

Feel free to share your answers with me: [email protected]

Reference

Books:

The Ascent of Money – A Financial History of the World (Author: Niall Ferguson) The Psychology of Money (Author: Morgan Housel) Generic:

RBI Vision Document: https://m.rbi.org.in/Scripts/PublicationVisionDocuments.aspx Reports: https://rbi.org.in/Scripts/publications.aspx Licensed entities: https://m.rbi.org.in/Scripts/PublicationsView.aspx? id=12043 RBI DPI: https://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx? prid=50901 NUE: https://m.rbi.org.in/scripts/bs_viewcontent.aspx?Id=3832 Guidelines:

Payments & Settlement Act: https://www.rbi.org.in/scripts/paymentsystems.aspx PA/PG guidelines: https://www.rbi.org.in/Scripts/NotificationUser.aspx?

Id=11822&Mode=0 Master KYC: https://m.rbi.org.in/scripts/BS_ViewMasCirculardetails.aspx? Id=4354&Mode=0 Prepaid instrument: https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx? id=11142 OPGSP Import: https://www.rbi.org.in/scripts/FS_Notification.aspx? Id=10037&Mode=0&fn=5 Remit: https://rbidocs.rbi.org.in/rdocs/notification/PDFs/04MD5127742FD0 914D54B5EC4ECA8076F325.PDF LRS: https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx? id=10192 Purpose code for cross-border: https://www.rbi.org.in/upload/notification/pdfs/52220.pdf NPCI Products: https://www.npci.org.in/(‘What we do’ tab) Useful Sites:

API: https://www.departmentofproduct.com/blog/apis-explained-forproduct-managers/ API (webinar): https://www.postman.com/webinars/apis-101/ Investopedia: www.investopedia.com

About the Author

Aditya Kulkarni is a seasoned FinTech professional with experience in strategy, solutioning, and business development. He worked in leadership positions at India’s leading Digital Payments/FinTech companies. Aditya is from Athani, a small town in North Karnataka. He has done B.Eng. from SJCE (Mysore) and MBA from Singapore Management University. After working in Japan, and Singapore, he is settled in Bengaluru with his wife and daughter. Apart from FinTech, Aditya has keen interest in history and economics. Aditya believes in building knowledge driven teams, companies, and society. This book is a small step from him towards that.