Hope you folks to be
safe and productive at your confinements. Happy learning! Let you be walked
through how actually a Payment gateway works. You must have also come across
the term as payment aggregators. We shall also discuss on the difference
between them.
Let us understand few
important terminologies:
ØCustomer à Someone who purchases the goods and services.
ØIssuing Bank à The customer’s bank account from where the
transacted amount is deducted.
ØMerchant à The shop/establishment
who sells the goods to the customer and facilitate them to pay for the goods
taken through various payment modes such as net banking, card, wallet, etc.
ØAcquiring Bank àThe merchant’s bank account where the merchant
will be credited with the transacted amount with the customer for the goods and
services sold.
ØNetwork/Scheme à Simply, VISA, MasterCard, AMEX, RUPAY, etc. Say
if the customer has the logo of VISA empaneled on his/her card. Here, the
transactions will route through the network called as VISA.
ØNodal/Settlement bank account à Nodal account is an internal account opened for
the intermediary between the customer and the merchant for settling the
transacted funds with the merchant as well as other parties like the payment
processors, networks, etc.
While you are now versed
with the nuances, let us quickly jump on to the customer journey inclusive of
the functional connections, which will help you understand how does even a
transaction goes through! Prior to that, a standard understanding of what
actually a Payment Gateway (PG) is. What is its role in the payment ecosystem?
A PG is a software/sever
that connects between the customer’s issuing bank and the merchant’s acquiring
bank through its payment processors for the transfer of funds. Don’t you worry!
I will make it easier in a bit. So, now that you know a bit about PG, ever
wondered what a Payment Aggregator (PA) is. As the name suggests, it is an
aggregator to all the PGs for a wider acceptance of transactions. Let us
understand simple differences between the two.
A PG is an intermediary
that connects between to the customer’s issuing and the merchant’s acquiring
bank while PA is interface to all the PGs for providing multiple payment
options with a wider scope of acceptance.
A PG can have one or
more payment options such as Net banking/Credit card options that you usually
see in a check out page, which completely depends on the merchant who can
afford to create one/banks, etc. whereas a PA is an interface with multiple
payment options ranging from net banking, cards to wallets or UPI at latest.
This Pas are generally built and owned by the fintech companies.
Imagine a merchant
tagged to only a PG for receiving payment transactions through net banking.
Now, what about the load of transactions? What about the payment success rate
(PSR)? Well chances are high for transactions to fail at any PG end rather than
a PA who balances the load of transactions and distributes it equivalently to
all its underlying PG.
Therefore, whoever be it
a merchant/Bank/any institutions that feels the need to own its own PG need to
pass the certifications as per the PSSA (Payment and Settlement Systems Act),
2007 as authorized by RBI. Whereas, any fintech player who supposedly want to
become the aggregator of PGs, need to pass the certification as per the PCI-DSS
(Payment Card Industry – Data Security Standard).
Since, you have a good
understanding of what a PG/PA is, let us move further with a use case showing
how actually these affect in the payment environment. Here you go with the
workflow of a PG (happy path scenario when the transaction is successful):
 |
I hope the diagram is
self-explanatory. Well, there are multiple other jargons to make the flow
functional cum technical but that’s not required at the initial phase of
understanding.
Now let us have a glance
on the settlement part; as in who earns what! It is obvious that the entire
smoothness of the transaction within a few seconds won’t be available for free
to the players involved in the diagram right!
Do you know that who is
the scapegoat in this entire transaction flow?
No, it’s not the
customer you think of, as Customer is the King. It’s the merchant, who bears
the transaction fees of the entire pool. You must have witnessed mostly at
grocery shops/alcohol outlets wherein the merchant charges an extra chunk for
the card transactions. Well, that’s the sole reason that they are frustrated
with the charges levied on them and they pass it to the customers which is sort
of illegal.
The merchant is credited
with the transaction amount in its acquiring bank account up to T+3 days post
settlement. Most of the cases wherein the PG/PA is an independent organization,
say for example PA, which can be any independent fintech service provider, they
have their settlement account with their acquiring bank and they settle with
the issuing bank on the behalf of the merchant. Once, it deducts all the fees
to be shared amongst all the parties, it credits the remaining balance to the
merchant’s acquiring bank account.
In such cases the PA
receives the processed transaction report from its acquiring bank and it
matches its with own transaction report. For any dispute raised / customers’
refund, the PAs acquiring bank and the customer’s issuing bank coordinate with
each other through reports wherein the PA shares the claim file and the refund
file. The acquiring bank as per the claim file, transfers the money to the PA’s
settlement account. As per the refund file, if the customer’s issuing bank
account has been debited and the customer’s transaction has been failed, or the
customer has not received/satisfied with the goods and services received, as
per the refund file, the message is communicated to the issuing bank and the
customer’s account is refunded with the transacted amount.
In case of any
transaction is not present either in the claim file or the refund file, the
customer is refunded with the amount to his account. I found a very useful
resource in Razorpay website wherein it has beautifully mentioned the reason why
refund takes so much of time. It is an open source to be read and hence,
appending below the link:
Now let us understand
the possible charges that the merchant need to bear in order to be facilitated
with the wider acceptance of payments by its PG/PA.
Let us connect it with
the previous flow:
Consider you have
performed a transaction of Rs. 1000 on an ecommerce portal for buying a
T-Shirt.
Assumption: the PA is
the solution provider of the payment gateway engine to the merchant and settles
the transaction on behalf of the merchant and finally disburses the balance
amount post deduction of charges in the merchant’s acquiring bank account.
The merchant is credited
with the remaining balance post the fees deducted by the:
Ø Issuing bank
Ø The card network (VISA/MC/AMEX, etc)
Ø Payment processing fee (Basically, the switch
charges, data processing charges, etc.)
Ø PA fees
*There might be other
charges as well apart from the aforementioned broad ones. Also, the charges
mentioned in the diagram are hypothetical. Different pricing structure defines
each of the PA/PG in the market uniquely, may it be Tier rate structure or a
flat rate structure.
So, by this far, I
believe you to have understood about the basics of a PA/PG. Let know by your
comments below with any queries/suggestions, which is important, and pertaining
to this article. Happy sharing until then!