Payment

Payment
The payments domain looks like ‘jungle’ with never ending list of payment method
with various entities moving money in intricate ways. Here is a series of articles
which will demystify some core terminologies and concepts.

Payment
Issuing
Bank
User
ACS Page
ii. Aggregator
Godel
Godel

Prologue :- various purposes,
Payment :- A payment is the trade of value from one
party (such as a person or company) to another for
goods, or services, or to fulfill a legal obligation.
1. Prologue Payment

1. Prologue Payment
Includes ::--
•Merchant: Entity that intends to collect funds. It
can be e-commerce company or utility company or
grocery store or educational institute.
•Acquiring banks: Bank that processes
transactions (through processor) and settles funds
to merchant (Acquiring Banks: HDFC, SBI, IMSL, UBI,
CITI, Axis, Kotak, Yes etc. Processors: CyberSource,
MIGS, FSS etc.)

1. Prologue Payment
Includes ::--
•Issuing banks: Bank that issues the card (credit,
debit or prepaid) (E.g.: ICICI, HDFC, SBI)
•Net-Banking: Allows customer to transact through
bank account (E.g.: ICICI, HDFC, SBI, 50 more banks
etc.)

1. Prologue Payment
Includes ::--
•Wallets: PPI (Prepaid Instrument) licensed entities
that allow users to load money through credit /
debit card, net-banking and wallet amount can be
used in designated merchants (E.g.: PayTM,
Mobikwik etc.)
•Prepaid cards: Customer can load the money on
card spend at designated merchants (E.g. Sodexo)

1. Prologue Payment
Includes ::--
•Payment Containers: They allow customer to make
payment through wallet, credit cards, debit cards,
UPI. (E.g. PhonePe,Amazon Pay etc.)
•Payment Aggregators: Payment companies who
integrate with acquiring banks, net-banking,
containers, wallets and provide single point of
integration and settlement to merchants. (E.g.:
BillDesk,TechProcess,PayU,RazorPay etc.)

When various entities move the funds from
point A to Point B, they charge certain fees. As
merchant you would deal with an aggregator.
Main purpose of any business… to earn
revenue and that’s exactly what aggregator do
when they enable payments for a merchant.
1. PG/Aggregator Charges

Payment Gateway is an e-commerce application service that
will enable you to have digital payments, like credit/debit
cards, net banking, various e-wallets, etc.
Payment Aggregator on the other hand are service
providers(companies) that integrate with various merchants
and provide them with payment gateways as a service.

Example:
Consider commercial payment aggregators like Citrus,
Billdesk, RazorPay, these companies offer payment gateway
services to different merchants for a price. These companies
accept payments on behalf of the merchant from the customer
and then transfer the money to the merchant account after a
stipulated time period

PG charges examples :-
•Percentage (%) of successful transaction value
(E.g. 1.50% of value)
•Flat fee per successful transaction (Rs.10 per
transaction)
•Mixed pricing i.e. combination of % of value +
Fixed Fee (E.g. 2% + Rs.1)

Factors that influence aggregator’s charges:
•Type of merchant (whether e-commerce, Utility
or insurance)
•B2B or B2C business model
•How big the merchant is (remember, payments
is a volume game)
•What is aggregator back-to-back commercial
arrangement with banks

2. How aggregator Collect Charges
There are three commercial models in
practice.
•Let’s assume: PG Charge = 1%, GST = 18%
(Financial Services), Transaction
Amount = 100

1. Upfront Deduction
•Aggregator deducts the charges and GST amount before
settling transaction amount to merchant.
•Customer Pays = 100, aggregator deducts = 1.18 and merchant
gets = 98.82

2. Surcharge
•Let us say merchant doesn’t want to bear the charges then
who will?
•The user, aggregator’s charges + GST amount is passed on to
the user
•Customer pays = 101.18, aggregator keeps = 1.18 and merchant
gets = 100

2. Surcharge

3. Invoicing
•Sometimes either merchant or merchant’s business model
doesn’t allow to either deduct money upfront or surcharge to
user. In such cases, the aggregator will raise invoice to
merchant on monthly basis.
•Customer Pays: 100, Merchant Gets = 100 and Aggregator will
invoice amount = 1.18

3. How to select payment aggregator?

4. How payment aggregator make money?
Typical cost structure for e-commerce merchants:
•Debit Cards (below Rs.2000): No Cost
•Debit Cards (above Rs.2000): Differential pricing for On-Us and Off-
us cards (in percentage, %)
•Credit Cards: Differential pricing for On-Us and Off-Us cards (in
percentage, %)
•Amex: in % and higher than other cards
•Net-banking: Either fixed cost in percentage (%) of value or
revenue sharing (60:40 or 50:50)
•Other payment methods: in percentage (%) of value

Pricing Principle
•Wherever it is fixed cost, charges should be higher than cost
(Example: If fixed cost is 1.50% then charge to merchant should be
1.55% or more)
•Wherever there is revenue sharing arrangement, don’t worry about
making loss but try to keep 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 revenue will be reduced to half)

1. Debit Card Transaction of less than Rs.2000:
•As per Govt. rule there is no charge on debit card transactions
below Rs.2000. But Acquiring bank gets subsidy (up to 0.25%) from
the Govt. So an aggregator can strike deal with acquiring banks to
receive few basis points (5bps or 10bps) against volume
commitment

2. On-Us rates:
•Say aggregator has differential rate for On-Us and Off-Us from
multiple acquiring banks then process On-Us transaction for
respective issuers and thus can optimize the cost

3. Subvention:
•Banks like to enjoy the float and banks often work with payment
aggregators and give subvention of few basis points against
volume commitment.
•Banks doesn’t work on this model all the time with all the
aggregators. Example: Bank A has given subvention to aggregator
A for merchant A. But same bank will not enter subvention deal with
aggregator B for same merchant as there is nothing additional
gain a bank will get by moving the engagement.

4. Nodal Account benefits:
•Aggregator’s nodal account is quite lucrative for any bank as huge
amount moves through the account. Although aggregator cannot
earn interest but banks can use this amount to increase ‘the
leverage’. So banks are ready to plough back some amount to
aggregator against the float or provide better costs or give priority
in partnership deals/RFPs etc.

Banks are the one who process the payments and a payment
aggregator is just a layer above those banks. To process
transactions, the aggregator has to procure MID (Merchant ID)
from the banks and then link those MIDs to the Live ID that of the
merchant.
5. MID & Live ID

MID Insurance Time
MID approval process is time consuming and turn around time
varies from bank to bank. So procurement of MID may take weeks if
not months.
5. MID & Live ID

MID Insurance Time
So how an aggregator can manage the delays?
•Have better turn around time with banks for issuance of MIDs
•Every aggregator would have procured industry specific MIDs
from banks (basically, an aggregator is a merchant to banks).
Aggregator can configure those generic MIDs to start with and
replace them with bank approved MIDs
5. MID & Live ID

MID Insurance Time
How do you know in whose name MID is?
•If merchant is configured on its own MID then merchant’s name
would appear in the statement. In case merchant is on generic MID
or transaction is done on one of carpet approved banks then
aggregator’s name will be shown.
•Interesting case: Do transaction on PhonePe and sometimes you
may see the name FX Mart.
5. MID & Live ID

Live ID (issued by aggregator)
•Live ID is unique identifier issued by aggregator to a merchant
(sometimes they call it MID). As mentioned earlier, bank/wallet
issued MIDs are linked to this Live Id.
•Transactions, refunds, settlements, chargeback, card vault of a
merchant are linked to this unique Live ID.
Some of the attributes of Live Id.
5. MID & Live ID

•Account Configuration. Each Live ID can be configured with one
bank account (If merchant require multi-account settlement then
use special fields/scheme codes)
•Acquiring bank Configuration: Multiple acquiring banks can be
configured for one Live Id (helps in configuring performance based
routing for cards)
5. MID & Live ID

•Commercials: One set of rates 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
5. MID & Live ID

Different payment methods have
different transactions flows and some of
the payment methods can have
different flavors of flows.
1. Transaction

1. Card
•Various flavors of card transaction:
•If Acquiring Bank and Issuing Bank are same then flow can skip the
stage 3 & Such flow is called On-Us transaction
•If acquiring bank and issuing bank are different then transaction
is done with flow i.e. Off-Us flow
1. Transaction

1. Card
•Direct OTP: Instead of redirection, transaction has two legs
(a)merchant triggers API to ACS to generate OTP for the card
(b)Customer receives the OTP on registered number
(c)OTP is captured on merchant’s site/app
(d)merchant triggers second API to ACS to validate the OTP
•DC and ATM Flow: For Debit cards of selected banks, instead of
OTP or 3DS password, customer can complete transaction with
ATM PIN. Customer is redirected to FSS hosted page to enter ATM
PIN
1. Transaction ACS- Access Control Server
DC- Debit Card
FSS- Financial Software System

2. Net Banking Transaction
Customer is redirected to bank’s online net-banking page to
authenticate themself and complete the transactions. Different
banks have different ways to validate the user.
1. Transaction

2. Net Banking Transaction
•E.g. ICICI Bank: Along with Customer Id and password stage,
customer may be asked to enter grid number or OTP. In case of
HDFC, you may be posed with security questions.
Notes on Net-banking :
•For repeat users the banks remove those additional checks (grid,
OTP, security questions)
•These pages are different that your regular net-banking pages
(they both look same but are different URL… try yourself and check)
1. Transaction

3. Wallet
•A customer is redirected to wallet’s page where customer validates
the credentials and completes the transaction.
•Wallets also provide link and payflow, where user can link the
wallet with one time validation and then wallet balance will be
shown on merchant’s page and wallet can be debited with single
click.
1. Transaction

4. Payment Containers
Containers are something which are combine wallet, cards, UPI
under one user account. Customer can select the preferred
payment method to complete the transaction
1. Transaction

Main purpose of online payments is getting ‘money’ from user. So
‘settlement’ is the crucial part of the payment cycle. Let’s assume
transaction was successful, when will merchant get the money and
how much?
Three factors affect settlement time
2. Settlement Time

1. Type of merchant:
•Standard settlement time is T+2 working days
•Exceptions:
(a) MF merchant (T or T+1 depending on liquid or non-liquid funds)
(b) if you are large merchant then you can negotiate on T+1 day
settlement
2. Settlement Time

2. T Count
In 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)
2. Settlement Time

3. Transaction time:
Different banks have different transaction cut off time. So any
transaction done after cut-off will move to next settlement batch.
2. Settlement Time

Let us assume, the settlement time is T+2 days then this is how
settlement cycle looks
Why T+2 day?
•Because it takes time for reconciliation and then move the money.
2. Settlement Time

Settlement amount depends on commercial model the merchant is
configured and how much amount needs to adjusted for refund
processing and chargeback recovery
3. Settlement Amount

1. Upfront deduction model
•Settlement Amount = Transaction amount (-) PG Charges (-) GST
Amount (-) Refund adjustment (-) Chargeback Amount Recovered
•Settlement Amount = 100 (-)1 (-) 0.18 (-) 50 = 48.82

2. Surcharge model
•Settlement Amount = Transaction Amount (-) Refund adjustment (-)
Chargeback Amount Recovered
•Settlement Amount = 100 (-) 50 = 50
•Note: PG charges + GST is borne by user so not part of settlement
calculation

3. Invoicing Model
•Settlement Amount = Transaction amount (-) Refund adjustment (-)
Chargeback Amount Recovered
•Settlement Amount = 100 (-) 50 = 50
•Note: PG Charges + GST is invoiced to merchant so not part of
settlement calculation

•Current Account: Opened by businesses that allows large amount
of transactions with low (or zero) interest rates
4. Settlement Little More Details

•Nodal Account: Non-interest earning account that is regulated by
RBI. Mandatory for businesses that pool money for subsequent
disbursement (E.g. e-Commerce marketplaces, payment
Aggregators).
In case of nodal accounts, the funds pooled should be out of the
account not later than T+3 working days (definition of T can vary)
and anomalies to nodal guidelines that are found in bank audit are
reported to RBI

•Escrow Account: Non-interest bearing accounts that are opened
as per terms agreed by parties. Agreement can ‘bipartite’
(merchant, bank) and ‘tripartite’ (merchant—bank—Aggregator).
Tripartite agreement is required if aggregator needs access to the
account to move the money

Multi-Account Settlement:
There is possibility that merchant wants to settle funds to different
accounts based on business model.
•Example 1: A Mutual Fund aggregator, should settle funds directly
to AMC’s account. If customer buys HDFC’s MF then funds should
go HDFC’s account and if customer buys Aditya Birla’s MF then
funds should be credited to Aditya Birla’s account

Multi-Account Settlement:
Example 2: A automotive company launched a App where customer
can select the dealer’s name and make payment towards service.
The funds should be directly settled to selected dealer’s account
and dealer should be able to mark refunds.

Can achieve in two ways:-
1. Have separate Live Id for each dealer and pass the appropriate
Live Id that is meant for selected dealer funds will be settled to the
account that is linked to that Live Id.

2. Create special fields or schemes for each dealer and link to
dealer’s bank account. During transaction pass the appropriate
scheme so settlement is done to that account

Refunds can be marked only against successful transactions.
Merchant can either mark full or partial refunds.
•Full Refund: Entire transaction amount is refunded
•Partial Refund: Only part of transaction amount is refunded. It is
possible that merchant can mark multiple partial refunds against
the same transaction.
5. Refunds

Merchant can mark refund multiple ways:
•Call refund API
•Mark refund in aggregator’s admin module
•File upload (mark multiple refunds in one go) in admin module
5. Refunds

Refund processing has few checks:
1. Refund 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
5. Refunds

3. Duplicate refund should not be processes (cases where refund
amount is less than transaction amount). To achieve this every
refund done should have unique id with status checks
•Example: Transaction Amount = 1000 then merchant marks refund
for 500 and by mistake marks refund again for 500. The second
(duplicate) one should be failed
5. Refunds

4. Merchant should have sufficient settlement amount to adjust the
refund amount
5. Refunds

A. Refund Flow
•During refund, the money traces back to its source through series
of identifiers that were created during transaction leg and return
to customer’s card/account.
•Once merchant marks refund then aggregator processes it on
next working day.
5. Refunds

B. So refunds are cumbersome… but why costly?
•Aggregator doesn’t charge any fee to process refunds. But
merchant still loses money on these refunds
•Example: Merchantis in upfront deduction model. Transaction
Amount Rs.100, PG Charge: 1% so Settlement Amount = Rs.98.82
•But merchant needs to return Rs.100.
•That leaves Rs.1.18 hole in merchant’s account (Without considering
TDS deduction)
5. Refunds

B. So refunds are cumbersome… but why costly?
•Does merchant lose money in surcharge and invoice model?
•In case of invoicing model, merchant loses money but in case of
surcharge model, customer loses money
•Example: In surcharge model, Transaction Amount = 100, PG
Charge 1% so total amount will be 101.18. But merchant can mark
only 100 as refund (any amount higher will be more than transaction
amount) so customer receives only 100 and surcharge collected
won’t be refunded (majority cases)
5. Refunds

What is chargeback:
Chargeback is a dispute raised by cardholder with the issuing
bank in case of cardholder doesn’t receive the service or doesn’t
receive refund when merchant fails to deliver service.
6. Curious Case of Chargeback

Chargeback flow:
•Chargeback raised by customer with her issuing bank reaches
merchant through acquiring bank and then aggregator.

Handling of Chargeback:
•Post receiving the chargeback info, merchant will have 4–5 days to
respond to the chargeback by either accepting or rejecting it.
•Accept: It is valid chargeback, acquiring bank recovers funds from
aggregator and aggregator will adjust the amount from merchant’s
next settlement. Customer receives the credit

Handling of Chargeback:
•Reject: Merchant provides information (proofs) that service
provisioning is done as per terms or refund is given to customer
•If merchant doesn’t reply within stipulated time period then such
chargeback is considered as valid chargeback.
•Merchant should take care that do not accept chargeback where
already refund is initiated (else customer will receive money twice)
•Issuing bank won’t accept the information provided by merchant
blindly and if the bank thinks that information is not sufficient then
it will go into second presentment.

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 merchant to keep chargebacks within specified limit.
If chargebacks are higher than normal then merchant will be on
radar of Acquiring Bank and Visa/MasterCard. And acquiring bank
may take decision to revoke the MID(merchant Id).

Importance of chargeback:
b. For Aggregator: If merchant doesn’t reply or do not provide
satisfactory proof then acquiring bank recovers the chargeback
amount from aggregator. (e.g. merchant closed business or non-
responsive) then aggregator will have no avenue to recover that
amount.
•Example: PG Charge: 2%, back-to-back cost = 1.90% so aggregator
has to process Rs.10,00,000 value (2,000 transactions of Rs.500 each)
to make profit of Rs.1,000. And one mismanaged chargeback of
Rs.1000 will wipe out that entire profit.

So, what are the risks in payment ecosystem (for aggregator or
acquirer)?
a. Fraudulent transactions
b. Chargeback related risk
1. Risk & Underwriting

How to decide on ‘RIGHT’ merchant?
Merchant’s business model
•What merchant is selling, whom merchant is selling, what are the
deliverables, mode of delivery, what is business cycle (daily,
sporadic, seasonal), what is the vintage, merchant’s financials,
founders/director background, what are the deliverables, what are
cancellation or refund related policies etc.

How to decide on ‘RIGHT’ merchant?
Collect and verify merchants credentials
•(Company documents, authorized signatory’s documents etc.)Every
merchant has different business model, an e-commerce company
may deliver goods in a day and other one may take 15 days. A
merchant may delivery service online (ticketing) but other will do
physical delivery (e-commerce). A merchant may allow refunds (e-
commerce) and other one may not allow refunds (examination fee).
So aggregator should understand merchant’s business model,
processes, policies, information available on customer touch points
to ‘underwrite’ the merchant.

Payment Page is the page where
customer selects the payment method
(cards, net-banking, wallet, payment
container, UPI, credit products etc.) to
start the transaction.
1. Payment Pages

A. Payment aggregator hosted page (Non-Seamless or redirection
flow)
•Payment page is hosted by aggregator. When customer clicks on
‘pay’ button, customer is redirected this page to select the payment
method and proceed with transaction.
Pros: (a) Simple integration so less effort
1. Payment Pages

flow)
1. Payment Pages

flow)
Cons:
•Merchant will not have control on page design
•Aggregator many not have all payment methods
•If save card option is enabled then cards are saved with
aggregator (locked-in)
•If merchant decides to add multiple aggregators then have to add
one radio button for each aggregator. Such arrangement gives
bad user experience and merchant won’t have control on
performance or commercial optimisation.
1. Payment Pages

B. iFrame
•Merchant can embed the aggregators iFrameinto merchant’s
website. Overall look of the page is in merchant’s control except the
iFramepart
Pros: Little better control on page look and less effort in integration
Cons: Cannot add multiple aggregators or add radio button for
each aggregator
1. Payment Pages

C. Merchant hosted page (Seamless Flow)
•Payment page is hosted by merchant where merchant will list all
applicable payment methods. To enable such flow, merchant has to
request its aggregators, banks, wallets to enable ‘seamless flow’ for
merchant’s Live Id.
Pros:
•Better control on page design
•Flexibility to add multiple aggregators, banks and payment
methods to increase payment method coverage
•With routing logics, merchant can optimise performance and
commercials
1. Payment Pages

1. Payment Pages

Cons:
•Requires effort to maintain the page
•Integration effort will be high when merchant adds new payment
partners
•High development effort to write and maintain transaction routing
logics
•Need card vault strategy to provide uniform user experience
1. Payment Pages

Working of Seamless Flow:
1. Payment Pages

Merchant can use seamless, iFrameor redirection flows of
Technical Solution Providers (E.g.: JusPay). Such TSP arrangements
help merchant to add new aggregator/payment method without
much effort and provide uniform save card flow.
1. Payment Pages

•Success rate of transaction done with saved cards is higher than
regular transactions
•Ease of completing transaction (as involves less steps)
•If a customer has saved card that means the customer will come
again to purchase (indicates loyalty, repeat purchase possibility,
higher LTV)
Who can save the card??
2. Save Card/Card Vault

a. Merchant
•A merchant can save the card if it is PCI Certified
Pros:
•No lock in with any aggregator or bank or TSP
•Better control on routing
•Use same card vault across multiple Live Ids of same aggregator

a. Merchant
Cons:
•Huge costs related to audits, insurance, resources (if you want to
have an elephant as a pet then be ready to buy a farm to feed it)
•Risk of saving card (remember, everything in payments is
associated with risk)

b. Payment Aggregator
All payment aggregators are PCI Certified entities and can provide
card vault service to merchants.
Pros:
•No additional cost to merchant as aggregator bears costs and
risks

b. Payment Aggregator
Cons:
•Saved cards are locked in the aggregator (Saved cards always
have to be processed with that aggregator only and merchant
cannot use other aggregator to process it)
•Merchant may think that I will vault card with aggregator A and
then move to aggregator B when the time comes. But such
migrations are next to impossible. Although technically it is allowed
but aggregators won’t do it giving various reasons of compliance,
risk etc. but main reason is that the existing aggregator would hate
to lose exclusivity with merchant

c. Technical Solution provider (TSP)
•FinTech companies that provide aggregator agnostic card vault
(E.g. JusPay)
Pros:
•Cards are not locked in with any aggregator or aggregator’s Live
Id so merchant can use any aggregator/acquiring bank of its
choice to process cards
•Merchant can enjoy benefits of card vault but TSP will do PCI
heavy lifting

c. Technical Solution provider (TSP)
Cons:
•TSPs may charge additional fees to merchant

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

•When to save: Typically, card is saved only when transaction is
successful.
•There are cases where merchant has vaulted card even for
unsuccessful transaction. This is wrong method as a card with
wrong credentials might get saved and transaction done with that
card will always fail.

What is saved: Only card number and expiry date is saved.
•A repeat user has to enter the CVV to complete the transaction.
•Note: Some aggregators allow transaction without CVV but that is
an exception

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
•Optimise commercials by routing transaction through cheapest
payment service provider
•Fulfilling volume commitment (To get better rates you might
committed volume to payment service provider)
3. Transaction Routing

Some of the possible routing logics:
a. Business Line Based
•Merchant can configure different aggregators for different
internal business lines or product lines.
•Example: All B2C transactions go through one aggregator and B2B
transactions processed through another aggregator.

b. Channel based
•Merchant can have channel wise routing for website, m-Site,
mobile App
•Example: All website transaction routed to Aggregator A but all
mobile App transactions to Aggregator B.
c. Round Robin method:
•Send one transaction to aggregator A, next one to B, next to C so
on. Logic doesn’t serve any purpose except merchant wants to keep
every aggregator happy by giving piece of action

d. Keep ‘passing’ until fails
•Send transaction to aggregator A till one transaction fails and
then start sending transaction to aggregator B till one transaction
fails and then bring back A again and so on. This is crude way of
performance based routing logic
e. Primary and Retry
•Aggregator A acts as primary for all transactions and backup
aggregator B is called in only when user of failed transaction try to
make another payment.

f. Performance Based
•Measure the performance of aggregators and acquiring banks
that are integrated and route the transaction through gateway who
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 other
aggregator). If aggregator A’s performance drops then start
routing volumes to B till 10:90 split.

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

g. Payment Method Based:

h. Commercials Based:
•It is possible that one aggregator can provide better rates 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/aggregators.

•Example 1: Let us say merchant has good commercials on net-
banking from aggregator A and good rates on credit cards from
aggregator B. Then route the transactions accordingly
•Example 2: On-Us Off transaction: Aggregator/acquiring banks
can provide differential rates for On-US off transaction so route
card transaction accordingly

i. Volume Based
•Transaction count based: Volume is split among aggregators
based on transaction count (assuming ticket size is same). Typically
works well if 50:50 split between two aggregators but not ideal for
complicated volume split cases.
•Example: If 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 requires additional logic to remember last aggregator
used and its count.

i. Volume Based
•Timer based: Build a timer based logic that can use current
timestamp. As this model is built on probabilities so 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 current timestamp and do mod 100 and if that number is less
than 5 then send to A, if number is less than 30 then send to B and
rest will go through C.

i. Volume Based
•Payment method wise split: Merchant knows the volume across
various payment methods and split payment methods such a way
to fulfil volume commitment.
•Example: Visa Cards and few net-banking constitute 50% of
volume. So if volume is to split 50:50 between to aggregators then
route all Visa Cards and selected bank through aggregator A and
rest through B.

A. Payment Page:
Payment Page is the page where customer selects the payment
method (cards, net-banking, wallet, payment container, UPI, credit
products etc.) to start the transaction.
4. Integration-Final Note

B. Payment coverage:
•How many aggregators, acquiring banks, wallets you need to have
optimal payment method coverage. Do not add a payment method
just because it is available in market.
•Example: If you are an e-commerce merchant with low ticket size
then you won’t need EMI on cards but if you are selling airline
tickets then EMI will be good sales booster.
•Note: Every time you add in new payment provider that mean you
will get additional settlement report and your finance team will not
be happy about it.

C. Payment Flow Flavours:
•For Cards: Standard card flow or direct OTP flow or Debit Card
ATM PIN flow
•In case of wallets, standard re-direction flow or link & Pay flow
•Multiple flow means, you should be ready to do multiple
integrations and also, cleverly manage those flows

D. API Needed:
•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 aggregators, payment providers have different
parameters, some are mandatory and some are optional. So are
the response codes and error codes. So need to have capability to
handle all API calls uniformly.
•Note: Alternatively use TSP who can provide or develop such
payment platform (E.g. JusPay)

E. Card vault strategy:
•Do you want to save card and with whom (self, aggregator, TSP).
•If you have already vaulted cards with aggregator then plan your
next step because you may have to face lot of resistance and it is
time consuming process
•Migration to your own vault, another aggregator or TSP
•Start afresh (check total vaulted cards, active users and expired
cards and decide whether want to migrate or start afresh)
•Use aggregator A to process already saved cards and save new
cards to your own vault or TSP’s vault

F. Routing Logics:
•Set your objective and define the routing logic accordingly
(covered in last section). Keep fine tuning the routing logic till you
consistently achieve better results
G. Checkout Flow:
•Think of overall checkout experience that should be frictionless in
terms positioning of payment methods and shouldn’t confuse
customer.
•If adding coupons then make sure coupons are easily accessible
as part of the flow

I. Operations:
a. Settlement Reconciliation: Every new payment service provider
will give you new set of settlement file. So more the payment
providers then more files. You finance team will not be happy
handling so many files. Think of automating settlement
reconciliation
b. Refund Management: More payment providers and more
complex routing means, you need capability to remember through
which payment provider transaction is done and you need to mark
refunds against same payment provider.

I. Operations:
c. 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 dashboard. So think of unifying dashboard.
d. Keep an eye on operations: Adding and removing payment
aggregator (service provider) is common practice but here are
some points that you need to consider before plug off payment
provider.

There are various ways a success rate is measured. The numerator
always remains same (i.e. successful transactions) but denominator
can be,
•Total transactions initiated by merchant
•Total transactions received by aggregator
Note: Above two should be same (if difference is high then it is a
concern)
•Total transaction initiated by merchant—user cancelled cases
•Total transactions initiated by merchant—User cancelled cases—
User mistake cases
5. Understanding Success Rate

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 ‘postpaid’ customer has to pay the bill before due
date. So those 20 failed transaction customers paid the bill within a
week. So what is the success rate now… 80% or 100%?
•View 2: If you are Flipkart, then out of those 20 failed transaction
customers 10 may not come back to buy or buy from other site. So
success rate is 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 customer paid anyway. Also, it is
possible that first 4 times transaction failed as customer had
entered wrong expiry date.

A. System Uptime:
•Basic expectation and goal should be 100% (or near) system uptime
for aggregator/payment service providers. Also, aggregator should
have business continuity plan in place and ability to handle spikes
or overloads.
•Even merchant should be able to handle spikes and maintain 100%
uptime
6. How to Improve Success Rate

B. Bank Integration:
•As a merchant, make sure aggregator provides you better
acquiring bank and payment processor combination as it plays
crucial role success rate of cards.
•Note: Aggregator has back-to-back cost with acquiring bank and
will be able to enable the best acquiring bank provided the
commercials with merchant allows.

C. Performance Based Routing
•A merchant can integrate two aggregators or acquiring banks and
set-up performance based routing.
•An aggregator can enable such routing by enabling two acquiring
banks for the merchant.
•Note: Sometimes the commercials with merchant won’t allow
aggregator to provide two best performing acquiring banks

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

E. Bank Alerts:
•There are two types of downtimes: Scheduled and unscheduled.
Aggregator should have mechanism to alert/inform merchants
about both downtimes proactively. So merchant can show the
downtime alert in checkout page and customer may use different
payment method to complete the transaction
•Example: ICICI NB success rate is 70% but if you are observing
success rate of 50% then show alert that ‘bank is not performing
optimal level, either continue or change payment method’

F. Retry Option:
•Instead of standard retry page show the best alternative payment
method to complete the transaction
•Example: If net-banking option is failed then show the debit card
option or if debit card transaction failed with OTP flow then show
ATM PIN flow
•Note: To enable such smart retries, merchant should have
required backend integrations

G. Save Card:
•Success rate of transaction done using saved card is higher than
regular transaction. If you have business case then save the card
with PCI entity (merchant, aggregator, TSP)

H. Alternate Transaction Flows:
•Debit Card + ATM PIN: Implement debit card + ATM PIN flow that is
simpler and provides better success rate on majority of banks. This
flow is subject to approval from banks and also, different banks
have velocity checks on transaction amount and number of
transactions per day. So understand all details before enabling the
same
•Direct OTP: Implement direct OTP flow on selected banks.
Considering it has less/no redirections, the success rate is better
than standard ACS flow.

H. Alternate Transaction Flows:
•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 customer. Based on the selection,
customer is switched to PSP App for completing the transaction
and returned to merchant’s App
•Link and Pay for wallet: Wallets provide link and pay feature where
customer 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 for payment or
change payment method. With this flow, user dropout related to low
balance can be reduced drastically

I. Optimize mobile transactions
•Mobile transactions are tedious especially w.r.t. card transaction
(entering OTP) and net-banking transaction (pages are not
optimized 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 aggregators as value added service and
JusPay which is specialized in this service.

A subscriber will provide their credit card information to pay for
the goods or services on a periodic basis. The vendor will then
withdraw the payment on a regular schedule until such time as the
subscriber's subscription expires and/or is cancelled.
Recurring billing provides a benefit to subscribers who don't have
to worry about another monthly bill to stay on top of - or risk
missing out on delivery of a product or service. Instead, with
recurring billing, the subscriber is guaranteed to have continuous
service.
1. How does recurring Payment work?

Recurring billing also offers great benefits to vendors. It makes
your revenue more predictable, since you already know what
payments will be made, and it takes away many of the
administrative headaches associated with collections. It's also good
for customer retention.
The subscription economy is exploding. Consumers don’t want to
buy products anymore, they want subscriptions to the products
and services they want, when they want them. And they're willing to
pay for this through recurring billing.
1. How does recurring Payment work?

There are two types in payments:
● Active Payments: Where user visits merchant’s website/app to
make payment
● Passive Payments: Where merchant pulls money from
customer without customer’s intervention
2. Recurring Payment Solutions

Nature of recurring Payments that we do
● Fixed Amount & Fixed Cycle: Here amount as well as
periodicity of payment will remain same. Periodicity can be
monthly, quarterly, half yearly, yearly etc.
Example: Monthly SIP 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 top up amount remain same
but periodicity is random as wallet may reach threshold amount
any time

● Variable Amount & Fixed Cycle: Here the periodicity of
payment remains same but amount may vary for every debit
Example: I pay my Vodafone bill every month but bill amount varies
every month depending on my usage

● Variable amount & Variable Cycle: In this case, both
periodicity of payment and amount varies.
Example: I can take Ola ride any time and my ride charge will vary
every time.

Addressing Recurring Payment Scenarios:
Recurring payment solutions are available in both online (digital)
and offline (paper) format that allow customer to set-up mandate
on bank account or cards and merchant can pull the funds for
respective account/card within boundaries of customer’s mandate
● Online Recurring Solutions: Standing Instruction on Cards, e-
NACH, e-Mandate
● Offline Recurring Solutions: ACH, ECS, Direct Debit

Addressing Recurring Payment Scenarios: Irrespective of their
format, recurring solutions involve three main stages: Mandate
Form filling, Mandate registration and Mandate debit

A. Mandate Form Filling: Customer to fill mandate parameters that
define boundaries for debit. Mandate parameters are,
● Duration: Start and End date
● Maximum Amount per debit
● Fixed or Variable Amount
● Cycle/Periodicity: Monthly, Quarterly, Half yearly, Yearly and
‘As and when presented’
Note: Merchant can show pre-filled form that can be approved by
customer or camouflage the mandate parameters and take
consent from user. (I will cover these methods in next chapters)

B. Mandate Validation:
The mandate needs to be validated or customer’s credentials
needs to be verified.
● Standing Instruction and e-Mandate: Customer to customer
to complete a successful transaction
● NACH, ECS, Direct Debit, e-NACH: Mandate to be validated
by customer’s bank

C. Mandate Debit
Once the mandate is successfully registered then merchant can
debit the customer’s account/card within the boundaries of
mandate parameter. Once amount is debited, merchant will
receive settlement.

A. Mandate Form
A Standing Instruction is defined by boundaries of duration,
Frequency (periodicity), maximum amount per debit and/or amount
type (fixed or variable).
But it is not necessary that merchant has to show the mandate
form to customer to complete it. So in many cases the mandate is
pre-filled by merchant or only minimum required parameters are
shown and rest are implied
3. Standing Instruction on Card

A. Mandate Form
In example (a), it just says monthly donation of Rs.900. That means,
maximum amount per debit = Rs.900, Frequency = every month,
Duration = Until cancelled (last one is implied)

A. Mandate Form
In example (b), maximum amount per debit = Rs.599, Frequency = As
and when presented, Duration = Until cancelled (last two are
implied)

Why do you need mandate parameters?
Typically there is no check on mandate parameters during card
debit. But mandate boundaries give assurance to customer that
Standing Instruction won’t be misused or overused by merchant.

Why you shouldn’t ask customer to fill mandate form?
If merchant shows a form with 3–4 fields then user will drop out for
various reasons: lengthy process, laziness, confusion, decision
making. Keep it simple so that conversions are higher.

B. Mandate Registration:
Customer has to complete a successful transaction to set the
Standing Instruction. Successful transaction can be done either
with token amount (e.g. Rs.5) or first payment of the cycle (e.g in
above illustration, first donation of Rs.900)

B. Mandate Registration: Once the Standing Instruction is
registered successfully then merchant can debit the card.

C. Mandate Debit:
Merchant can run a scheduler or trigger APIs to debit the cards.
And card will be debited within the boundaries of mandate
parameters.
Debit status will be updated in near real time (if not then on T+1 day
when bank reconciliation is done)

C. Mandate Debit:

What is that red box (above flow diagram)… Watch out for SMS:
In Standing Instruction, subsequent debits are done without 2nd
Factor Authentication. So issuing banks are obliged to send SMS to
user mentioning that amount is debited and transaction is not
done as per 2FA guideline as mandated by RBI circular of 31st July
2012. This message may trigger panic or confusion.

Remedy: Merchant can send SMS to customer before the debit date
about the debit. Something like “Dear User, as per Standing
Instruction set by you on Visa card <XXXX XXX XXX 1234> will be
debited on <Date> for amount <Rs.900>”. Such proactive
communication will reduce the impact of SMS

When to debit the card?
● On Trigger: In wallet top-up case, the wallet balance
dropping to Rs.200 is the trigger for debit
● On Date with Trigger: In case of mobile postpaid bill, debit
date can be fixed for a user (e.g. 2 days before bill due date)
but amount may vary for every billing cycle

● On Date: In case of donation example, NGO has to decide on
debit date. It can be
(1) date on which donor had set the standing instruction (3rd of
every month)
(2) one common day for all standing instruction (E.g. 5th of every
month)
(3) 2 different dates depending whether donor has set Standing
Instruction on 1st of month or 2nd half of month (E.g. 5th and
20th respectively

https://medium.com/@kulkarni.adi
Reference

Payment

More Related Content

What's hot

Similar to Payment

More from Aman Lalpuria

Recently uploaded

Payment