IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2

IMPS Merchant Payments
For Banks and Merchants

Version 1.0
June, 2012
IMPS Merchant Payments For Banks and Merchants

Contents
1.
2.
3.
What is IMPS merchant payments service? ................................................................................................5

What are the pre-requisites for availing the service? .................................................................................5
How does it work? ..........................................................................................................................................6
3.1
3.2
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Customer initiated transaction (P2M PUSH) ............................................................................................6

Merchant initiated transaction (P2M PULL) ..............................................................................................6
What are the use cases for P2M PUSH transactions? ................................................................................7
How does customer make face-to-face payment using IMPS P2M PUSH? ..............................................7
What are the use cases for P2M PULL transactions? ................................................................................8
What is Mobile POS application? ..................................................................................................................8
What are the advantages for payment via IMPS? .......................................................................................9
What are the amount limits for transactions through IMPS merchant payments? .................................9
How can the merchant get on-boarded on IMPS merchant payments? ...................................................9
Who are the contact persons in the Banks to get on-boarded on IMPS merchant payments? .......... 10
What are the merchant on-boarding process guidelines for Acquirer Bank? ...................................... 10
For Customer initiated transaction (P2M PUSH), what is the transaction message flow? .................. 13
13.1 What if there is an error in payment reference and amount entered by customer? .............................. 14
13.2 What if acquiring bank is not able to send payment reference verification request to merchant? ........ 15
13.3 What if there is no response from merchant to payment reference verification request? ..................... 16
13.4 What if payment reference online verification is successful, but merchant back-end system is not
updated successfully? ....................................................................................................................................... 17
13.5 What if there is no online interface with merchant? ............................................................................... 18
13.6 What if acquiring bank rejects transaction? ........................................................................................... 18
13.7 What if customer wants to make payment to individual beneficiary, but uses person-to-merchant form
on mobile banking application? ......................................................................................................................... 19
13.8 What if customer wants to make payment to merchant, but uses person-to-person form on mobile
application by mistake? ..................................................................................................................................... 20
13.9 What if there is time-out in the transaction flow? ................................................................................... 21
14. For Merchant initiated transaction (P2M PULL), what is the transaction message flow? ................... 22
14.1 What if there is rejection at Issuing Bank? ............................................................................................ 23
14.2 What if there is rejection at NPCI? ........................................................................................................ 23
14.3 What if Acquiring Bank cannot forward message to NPCI due to communication failure? ................... 24
14.4 What if NPCI cannot forward the financial message to Issuing Bank due to communication failure? .. 24
14.5 What if Issuing Bank cannot forward the financial message to its CBS due to communication failure?25
14.6 What if Issuing Bank does not receive response from its CBS after sending the financial message due
to communication failure? .................................................................................................................................. 25
14.7 What if Issuing Bank does not respond to NPCI after sending the financial message due to
communication failure? ...................................................................................................................................... 26
14.8 What if NPCI does not forward response to Acquiring Bank after receiving the financial message from
Issuing Bank, due to communication failure? .................................................................................................... 27
14.9 What if Acquiring bank is not able to forward message to its CBS, after receiving the financial message
from Issuing Bank, due to communication failure? ............................................................................................ 28
14.10
What if acquiring bank does not receive response from CBS, after sending message to CBS for
merchant credit, due to communication failure? ................................................................................................ 28
14.11
What if Acquiring Bank is not able to respond to merchant due to communication failure? ............. 29
14.12
What if there is time-out to the reversal advice message? ................................................................ 30
15. What is the dispute management process for IMPS merchant payments? .......................................... 30
Page 2

15.1
15.2
15.3
15.4
15.5
15.6
15.7
15.8
15.9
15.10
15.11
15.12
Debit adjustment .................................................................................................................................... 31

Credit adjustment (Refund).................................................................................................................... 31
Chargeback............................................................................................................................................ 32
Re-presentment ..................................................................................................................................... 33
Pre-arbitration ........................................................................................................................................ 33
Pre-arbitration decline ............................................................................................................................ 34
Pre-arbitration Accept ............................................................................................................................ 34
Arbitration............................................................................................................................................... 34
What are the procedures for handling arbitration in the IMPS network? ............................................... 34
What is the Penalty for non-compliance of Settlement Guidelines.................................................... 35
What are the Good-faith guidelines for IMPS transactions? ............................................................. 35
What are the guidelines for handling customer complaints in IMPS network? ................................. 35
16. What are the features required in merchant acquiring platform? .......................................................... 35
17. How does merchant get integrated with Acquiring Bank? ..................................................................... 36
17.1
17.2
For push transactions ............................................................................................................................ 36

For pull transactions .............................................................................................................................. 36
18. What are the various interfaces through which merchant can receive payment via IMPS merchant
payments PULL transaction? ............................................................................................................................. 37
18.1
18.2
18.3
18.4
18.5
18.6
18.7
18.8
18.9
18.10
18.11
18.12
Web application for integration with merchant web site ........................................................................ 37

WAP application for integration with merchant WAP site ...................................................................... 37
IVR application ....................................................................................................................................... 38
Merchant mobile handset application .................................................................................................... 38
SMS based application for customer ..................................................................................................... 38
SMS based application for merchant ..................................................................................................... 38
Reminder SMS based application ......................................................................................................... 39
Merchant server application................................................................................................................... 39
USSD based application ........................................................................................................................ 39
STK based application ....................................................................................................................... 40
WAP based application ...................................................................................................................... 40
Internet based application .................................................................................................................. 40
19. What is the merchant configuration required at the acquiring bank platform? .................................... 41
19.1
19.2
19.3
Merchant set-up ..................................................................................................................................... 41

Merchant configuration .......................................................................................................................... 41
Financial configuration ........................................................................................................................... 41
20. What facility is required for transaction status verification for merchant? .......................................... 41
21. What MIS facility may be provided by Acquiring Bank to the merchant? ............................................. 42
22. What is the reconciliation procedure between Bank and Merchant? .................................................... 42
23. What is the refund procedure between Bank and Merchant? ................................................................. 43
24. What are the security guidelines for acquiring Bank and merchants? ................................................. 43
25. What are the guidelines for settlement of payments for electronic payment transactions involving
intermediaries? .................................................................................................................................................... 44
26. What are the risk management guidelines at Acquiring Bank? ............................................................. 44
27. What are the risk management guidelines at Issuing Bank?.................................................................. 44
28. What is the list of response codes in the IMPS system? ........................................................................ 45
29. What are the reconciliation files and reports that IMPS provides to the member banks? .................. 47
Page 3
Page 4

1. What is IMPS merchant payments service?
IMPS Merchant Payments (P2M Person-to-merchant) service allows customers to make instant, 24*7,
interbank payments to merchants or enterprises via mobile phone. IMPS enables mobile banking users a facility
to make payment to merchants and enterprises, through various access channels such as Internet, mobile
phone, IVR, SMS, USSD.
Customer can make payment to any kind of merchant using IMPS merchant payments service:
1.
2.
3.
4.
5.
6.
7.
Mobile top-up / DTH top-up

Insurance premium payment
Online shopping
Over-the-counter payments
Fees payments to schools / colleges / universities
Utility Bill payments
Travel & Ticketing
The key features of IMPS merchant payments service are as follows:

1.
2.
3.
4.
5.
6.
Instant confirmation to sender and receiver

Convenient and time-saving
Anytime, anywhere service
Safe & secure
24*7*365 availability
Merchant needs to get on-board IMPS network with one Bank. Customer of any Bank in the IMPS
merchant network can make payment to merchant through IMPS
This service is brought to you by National Payments Corporation of India (NPCI) in collaboration with Member
Banks.
2. What are the pre-requisites for availing the service?

Customer needs to be a mobile banking user of their respective Bank. Customer needs to do the following in
order to get started:
1. Register mobile number with the account in the respective Bank
2. Get MMID. MMID stands for Mobile Money Identifier and is 7-digit number that is provided by Bank to
customer. This number is used to identify customer Bank and is linked to the account number. The
combination of mobile number and MMID is unique for the particular account, and customer can link
same mobile number with multiple accounts in the same Bank, and get separate MMID for each account
3. Get M-PIN. M-PIN is Mobile PIN, a secret password that is provided by Bank to customer. Customer
needs to authenticate transaction using M-PIN
4. Download mobile banking application or use SMS / USSD facility provided by the Bank. In order to
perform IMPS transactions, customer needs to download mobile banking application or use SMS /
USSD facility provided by the Bank
5. Perform transaction using mobile banking application or SMS / USSD facility
Merchant needs to do the following to receive payments via IMPS:
1. Open merchant account with the Acquiring Bank
2. Register mobile number with the bank account and get MMID from respective Bank
3. Integrate with the Acquiring Bank.
Page 5
3. How does it work?

There are two ways in which IMPS merchant payments (P2M Person-to-Merchant) transaction can be
performed:
1. Customer Initiated Transaction (P2M PUSH)

2. Merchant Initiated Transaction (P2M PULL)
3.1 Customer initiated transaction (P2M PUSH)

In the customer initiated transaction (P2M PUSH), customer initiates transaction through the Banks mobile
banking application or SMS facility provided by the Bank. The Bank offers IMPS merchant payments form in the
mobile banking application (this form is available in IMPS menu on the main menu of mobile application) or
SMS syntax for performing P2M PUSH transaction. Customer needs to enter the following parameters:
1.
2.
3.
4.
5.
Merchant mobile number

Merchant MMID
Amount
M-PIN
Payment Reference
Payment Reference is an optional 50 characters field provided. This field will be used to enter the unique
reference for the payment, and identifies the transaction to the merchant. The merchant decides what customer
will enter in this field. For e.g. for insurance premium payment, customer may need to enter policy number in the
payment reference field; for electricity bill payment, it may be consumer number. The syntax and information to
be input in the payment reference field will be decided by merchant, and communication of the same will be
merchant ownership.
The SMS syntax for making P2M PUSH transaction through SMS is as follows:
MIMPS <Merchant mobile number> <Merchant MMID> <Amount> <M-PIN> <Payment Reference> to Banks
long code or short code number.
On initiating transaction as above, customer receives the confirmation SMS with status of transaction shortly.
For IMPS P2M PUSH transaction initiated through SMS, transaction limit is Rs 5,000/- per day (for most banks),
and for transactions initiated through mobile banking application, transaction limit is as decided by the Bank (Rs
50,000/- for most banks)
3.2 Merchant initiated transaction (P2M PULL)

In Merchant Initiated transaction (P2M PULL), the transaction is initiated through Merchant application (such as
Merchant website, WAP site, IVR, mobile application). The typical steps to follow for making transaction through
P2M PULL are as follows:
a. Visit merchant application such as web site, mobile application, or WAP site
Page 6

b. Select product / service for which payment is to be made
c. In the payment options available, choose IMPS
d. Enter credentials as follows:
i.
Customer mobile number
ii.
Customer MMID
iii.
OTP (One-Time Password)
e. The transaction status is displayed on the screen
The customer needs to enter the credentials Customer mobile number (as registered with the Bank), customer
MMID (as generated by Bank) and OTP (One-Time Password, as generated by customer).
OTP needs to be generated by customer for each transaction. OTP can be generated by customer by using
mobile banking application or SMS facility as provided by the Bank. The Bank offers Generate OTP form in the
mobile banking application (this form is available in IMPS menu within main menu of mobile banking
application) or SMS syntax for Generate OTP transaction. Customer needs to enter the following parameters:
1. M-PIN
The SMS syntax for Generate OTP through SMS is as follows:
OTP <M-PIN> to Banks long code or short code number.
On initiating transaction as above, customer receives the confirmation SMS with status of transaction shortly.
The OTP generated as above has following characteristics:
1. OTP is valid for 1 hour from time of generation
2. If OTP is generated through SMS, the transaction limit is Rs 5,000/- and if OTP is generated through
mobile banking application, the transaction limit is as decided by the Bank (Rs 50,000/- for most banks)
3. OTP is valid only for one transaction Successful or Failure
4. Only one OTP (latest generated OTP) is valid at a time
4. What are the use cases for P2M PUSH transactions?

Following are the use cases for P2M PUSH transactions:
1.
2.
3.
4.
5.
6.
7.
Insurance premium payment

Mobile / DTH Recharge
Fee payments
Credit card payments
Utility Bill payments
Over-the-counter payments
Face-to-face payments Pizza delivery, Courier, Cabs, Retail
5. How does customer make face-to-face payment using IMPS P2M PUSH?
Customer can make P2M PUSH payment to the enterprise using enterprise mobile number, MMID, and enter
amount, payment reference, and M-PIN, in the mobile banking application or SMS / USSD facility provided by
the Bank. The customer as well as enterprise shall receive confirmation SMS.
Page 7

In case of face-to-face payments, the customer may be paying to the agent of enterprise (such as pizza delivery
person, or courier agent), and it is important for the receiving agent to get an SMS confirming the transaction. So
even if enterprise receives an SMS, the agent in front of customer doesnt know about the transaction status.
To take care of this issue, enterprise can register multiple mobile numbers (mobile numbers belonging to
enterprise agents) with their respective Bank. Customer initiates payment using agents mobile number and
MMID, and the payment is received into the enterprise account (since agent mobile number / MMID is linked with
enterprise account). The customer as well as agent shall receive confirmation SMS.
6. What are the use cases for P2M PULL transactions?

The use cases for P2M PULL transactions are as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Mobile POS
Merchant aggregators
Retailers, FMCG, Food chains
E-commerce, movies, classified, courier
Travel & Ticketing, Radio Taxi
Mutual Funds
Insurance
Utility Bill Payments
Mobile / DTH recharge
Trading / NBFC
Credit Cards
Fees payments
Donation
7. What is Mobile POS application?

Mobile POS is the mobile application that can be downloaded by merchant on their phone. Merchant can receive
payment from customer via IMPS using the mobile POS application. Enterprise may comprise of multiple agents
that receive payments on behalf of enterprise (such as agents at cash counters, pizza delivery agents, courier
agents, taxi drivers, etc). The agents mobile number can be linked to the enterprise bank account at the Bank
end, and the agent can receive payment from customer on behalf of enterprise, by using application on their
mobile phone.
The process is as follows:
1.
2.
3.
4.
5.
6.
7.
8.
Enterprise agent has mobile POS application on the phone

Opens up form Receive payment from customer
Enters payment reference, amount
Asks customer to enter mobile number, MMID and OTP
Agents mobile number (through which payment is initiated) is linked with merchant account
Merchant account is credited and customer account is debited
Customer and agent get confirmation SMS
Facility to link multiple mobile numbers and MMID with one account, so payments can be received in
single account of merchant / aggregator
Mobile POS application can be given by retail organizations at their cash counters. Virtual POS can be deployed
at the cash counters as well, in which customer can make payment by providing their mobile number, MMID and
OTP, and the cash counter person shall enter this information in the virtual POS application on their PC. This
can be integrated with billing system of the retailer as well.
Page 8

The mobile POS can be used by courier agents and receive payments via IMPS. Cash on delivery can be
replaced with payment via IMPS. This can help reduce cost and settlement cycle can be reduced.
Insurance agents can carry mobile POS application as well and collect payment from customers using mobile
POS instead of cash and cheque. There is no investment required for the POS machines and no need for
agents to visit insurance company branch office to submit cash and cheque.
In Mutual Funds, customers can pay to distributors via Mobile POS.
8. What are the advantages for payment via IMPS?

The advantages of payment via IMPS are as follows:
1.
2.
3.
4.
5.
6.
Number of mobile users is lot more. Mobile number can be linked to bank account for everyone
Replacement of cash
Remote payments via website, IVR, mobile application
Mobile POS
No investment on POS machine for receiving payment via IMPS
Convenience, anytime, anywhere payments
9. What are the amount limits for transactions through IMPS merchant payments?
The amount limits for transactions with end-to-end encryption is as follows:
Banks are free to set their own limits, based on bank discretion (Refer RBI circular RBI / 2011-12 / 312
DPSS.CO.PD.No. 1098 / 02.23.02 / 2011-12 dated December 23, 2011)
The amount limits for transactions without end-to-end encryption is as follows:
Transactions up to Rs 5,000/- can be facilitated (As per RBI circular RBI / 2010-11 / 511 DPSS.CO.No. 2502 /
02.23.02 / 2010-11 dated May 04, 2011)
Regarding OTP transaction limits, If OTP is generated through unencrypted channels, the transaction limit is Rs
5,000/- and if OTP is generated through encrypted channels, the transaction limit is as decided by the Bank (Rs
50,000/- for most banks, as of now)
10. How can the merchant get on-boarded on IMPS merchant payments?
The merchant can get on-boarded on IMPS merchant payments through any of the following:
1. Participating Bank
2. Participating Merchant aggregator
For list of participating Banks, please visit http://www.npci.org.in/impsmerpay10.aspx
For list of services available on IMPS merchant payments, please visit http://www.npci.org.in/impsmerpay7.aspx.
This includes services available through merchant aggregators.
Page 9

11. Who are the contact persons in the Banks to get on-boarded on IMPS merchant
payments?
The following officials can be contacted in the Banks to get on-boarded on IMPS merchant payments:
Bank
Axis Bank
Canara Bank
Corporation
Bank
Dombivli
Nagari
Sahakari Bank
Greater
Bombay Bank
HSBC
ICICI Bank
Kotak
Mahindra Bank
Standard
Chartered
Bank
State Bank of
India
Union Bank of
India
Yes Bank
Contact
person
Shri Vinay
Vasudev
Shri Vishal
Shri K
Ramachandran
Shri Milind
Varerkar
Shri Pratik
Gadgil
Shri Milind
Mahadik
Shri Vijay Lulla
Shri Devendra
Verma
Shri Salil Chugh
Shri Saurabh
Jain
Shri Yogesh
Verma
Shri Sachin
Tiwari
New Business
Department,
State Bank
Bhavan,
Madame Cama
Road, Nariman
Point, Mumbai
Shri Gyan S
Narayan
Shri Anand
Bajaj
Designation
Phone
Email
AVP Internet
Banking
Sr Manager
DGM
022 43256376
vinay.vasudev@axisbank.com
vishal@canarabank.com
kram@corpbank.co.in
DGM IT
Officer IT
9611100524
0824-2426443,
9880622361
9833362823
9730356553
Sr Manager
9820178334
Milind.mahadik@greaterbank.com
Sr Vice
President
Vice President
DGM
Chief Manager
022-66696360
022-67465623
vijaylulla@hsbc.co.in
devendraverma@hsbc.co.in
022-26536050
9820087940
salil.chugh@icicibank.com
Saurabh.jai@icicibank.com
Product
Manager
Associate
Director,
Transaction
Banking
9833900529
Yogesh.n.verma@kotak.com
9004333123,
022-61157719
Sachin.tiwari@sc.com
milindvarerkar@dnsb.co.in
pratikgadgil@dnsb.co.in
022-22741218,
022-22741206
Sr Manager
(Marketing)
EVP
022-22892561
gyannarayan@unionbankofindia.com
7738947773
anand.bajaj@yesbank.in
12. What are the merchant on-boarding process guidelines for Acquirer Bank?
The merchant on-boarding process is as follows:
An Acquiring bank should ensure to carry out due diligence before on boarding any merchant to ensure that
Page 10

the fraudulent merchant set-ups, fly by night operators are not boarded.
1.1. An Acquiring bank must have a defined merchant on-boarding policy duly approved by the senior
management of the bank which should outline the process, policy and guidelines to be followed
before boarding any merchant on acquiring bank system. If the acquiring bank is acquiring the
merchants through third party processors (TPP), they should ensure that the TPP should follow the
acquiring bank guidelines. The liability for the merchant on-boarding through TPP rests with the
acquiring bank.
1.2. An Acquiring bank should enter into an agreement with the merchant.
1.3. An Acquiring bank must ensure that the payment to the merchant if enrolled through TPP should
follow the RBI guidelines (RBI/2009-10/231)
1.4. An acquiring bank should perform the following checks on a merchant before enrolling that merchant
as a participant in IMPS.
1. Merchant Business model check
1.1. Verify the physical location of merchant office site inspections of merchant office / place of
business and file a visit report by the acquiring bank or the TPP
1.2. Check if actual product/service matches with their claim
1.3. Check the duration of operation for the merchant.
1.4. Conduct Neighbour check for merchants in existence for less than 1 year.
2. Acquiring bank should obtain the proof of business existence for the merchant
3. Manage exposure to risk by choosing merchants based on a strict set of parameters.
Recommend to check for the following:
3.1. Previous merchant processing relationship with a foreign/offshore acquirer
3.2. Usage of multiple acquirers
3.3. E-commerce business less than one year old
3.4. New merchant without proof to show acceptable charge-back/fraud records
3.5. Accounts that have quickly exceeded approved processing volumes
3.6. Arrangements with third-party processers with suspicious activity
3.7. User of small value transactions to artificially increase transaction counts
Ensure requests for multiple merchant accounts are thoroughly scrutinized.
3.8. Merchant with large number of shell companies
1.5. The following measures are recommended to be taken during the process of ecommerce merchant
acquisition to prevent fraud:
1.1. Website Inspection including:
1.1.1.Content
1.1.2.Products
1.1.3.Privacy policy
1.1.4.Refund policy
1.1.5.Cancellation policy
1.1.6.Terms & conditions
1.1.7.Website data security
1.1.8.Data storage
1.1.9.SSL payment options over the internet
1.1.10. Links to other sites
1.2. Ensure that the merchant does not process any illegal transaction (e.g.: pornography, rape,
terrorism, gambling in goods or services, illegal goods or services)
1.6. It is imperative for acquirers to make sure that mobile payments are as secure as possible. NPCI
recommends following guidelines for acquirers so as to ensure the safety of mobile payments.
Acquirers should:
1. Check if vendor is able to provide assurance that the code within a payment application has not
Page 11

been tampered with or altered without authorization.
2. Ensure that the ability to disable mobile payment solution is provided
3. Check for functionality to track usage and key activities within the mobile payment acceptance
solution
4. Ensure the transaction and customer data is stored/accessed/transmitted in secure form and
according to the secure industry practices. Acquiring Bank has to ensure that the all transaction,
customer and merchant related data should be secure and acquiring bank would be held liable for
the data compromise resulting in the financial loss to the payment Industry. Liability would be
there even if acquiring bank or merchant takes the services of Third Party processors.
5. Provide guidelines to merchants regarding mobile payment best practices
5.1. Any software downloaded onto the consumer mobile device comes from a trusted source
5.2. Ensure that only authorized users (i.e., designated employees) have physical / logical access
to the payment functionality
5.3. Report loss/theft of merchant mobile device or other system
5.4. Protect the payment device from malware
6. Ensure that manual intervention in the process is kept to a minimum.
7. Ensure that sensitive data can be accessed only by a few authorized personnel during the entire
process
1.7. Third Party Processors: Acquiring Bank
1. Many acquirers use Third Party processors to outsource few activities like transaction processing
& customer support. However, it is the responsibility of the acquirer to ensure that the Third Party
Processors do not pose any risk to the payment system
2. An Acquirer that uses any Third Party Processor must comply with all requirements as specified by
NPCI
3. The acquirer has the overall responsibility for the check & controls to monitor the activities of the
Third Party Processors. This includes:
3.1. Control of the approval and review of merchants, and the establishment of merchant fees
3.2. Maintain a file on the TPP that includes all applicable documentation, and retain this file for a
minimum of two years following termination of the relationship.
3.3. Identify each Processor and designate the activities that it is authorized to perform on the
Acquirers behalf.
3.4. Guarantee that the Acquirer and its Processors will comply with the NPCI requirements for
the use of Agents.
3.5. Accept responsibility for any and all losses caused by its Processor.
4. A third party processor agreement or contract must have a clause that allows the acquirers to
terminate the contract if the Third Party processor is involved in any prohibitive or illegal activity
that may harm NPCI reputation or if the TPP becomes insolvent
5. The Acquirer or NPCI may conduct an audit of the TPP at any given point of time
1.8. Third Party Processors: Merchant
1. Since Merchants are responsible for the customer data that they provide any Service Provider
access to, they should ensure that their Service Providers have validated compliance to secure
industry practices for the services provided. Extra scrutiny must be placed on the Service
Providers controls as it raises additional risks to customer data, few steps the merchant must
take are as follows:
2. Ensure that the Service Provider furnishes a written document, ensuring that it will appropriately
protect customer data in accordance with the industry best practices for the duration of the
relationship. This agreement should clearly distinguish between merchant and service provider
control.
Page 12

3. All Service Providers who have an access to the customer data must be listed and monitored by
the merchant.
4. Check whether Service Provider comply to secure industry best practices when it comes to
protect confidential / business critical information / data
5. Shared Hosting Provider
5.1. A Shared Hosting Provider generally provides Information Technology (IT) services like
web hosting, email hosting and data center services to multiple customers. Due to
economies of scale, Shared Hosting Providers are often able to provide these services at
lower rates than if the merchant were to manage these in-house. However, due to the shared
nature of these environments, additional risks arise.
5.2. A significant risk is the possibility that a compromise of the data storage environment can
result in the breach of many customers data. This risk is particularly notable for shared web
hosting environments where virtualization technology is used
5.3. It is thus imperative that a merchant question and evaluate the controls that a Shared
Hosting Provider has in place.
5.4. Ensure that a compromise of one of the Shared Hosting Providers customers will not pose a
risk to the data of other customers.
5.5. Merchants should ask their Shared Hosting Provider about the specific controls that they use
to assure proper segmentation between customer environments.
5.6. Extra scrutiny should be placed on shared resources including, but not limited to, the
management network, disk storage systems, and virtual environment hypervisors.
5.7. The merchant should also address risks that arise if there is a network connection between
the merchants local network and the environment provided by the Shared Hosting Provider
5.8. Ensure that security controls, such as firewalls and intrusion detection/prevention, between
the Shared Hosting Providers environment and the merchants own local network are
implemented
5.9. It is the merchants responsibility to have a clear understanding with the Shared Hosting
Provider as to exactly which controls are to be provided by them and which are to be
provided by the merchant.
13. For Customer initiated transaction (P2M PUSH), what is the transaction message
flow?
Page 13
1) Customer initiates transaction through Issuing bank mobile application, enters merchant mobile number,
merchant MMID, amount, M-PIN and payment reference
2) The information is received by the Issuing Bank, Issuing Bank verifies customer account and debits the
account
3) Issuing Bank forwards information to NPCI
4) NPCI forwards to Acquiring Bank, based on merchant MMID and mobile number
5) Acquiring Bank verifies merchant MMID and mobile number
6) Acquiring Bank sends the Payment Reference information and amount to the merchant back-end
system
7) Merchant verifies the payment reference and amount and reverts with status
8) Acquiring bank credits the merchant account, and sends SMS to merchant
9) Acquiring bank sends the transaction response to NPCI
10) NPCI forwards the transaction response to Issuing Bank
11) Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank
application
12) Acquiring bank updates merchant back-end system
Note: The interface between acquiring bank and merchant / aggregator is up to the acquiring bank to
implement. The following situations may be possible, and it is up to the Bank to decide:
1) The integration between acquiring bank and merchant could be through a merchant aggregator
2) The credit to the merchant account may or may not be instant, and bank may decide to settle funds
instantly or on offline basis
3) The merchant system may not be updated real-time online, and may be done offline, in a batch process
4) The verification step may or may not be used
5) The online verification and merchant system update step may be clubbed together
13.1
What if there is an error in payment reference and amount entered by
customer?
The transaction flow in this case is as follows:
Page 14
account
6) Acquiring Bank sends the Payment Reference information and amount to the merchant back-end
system
7) Merchant verifies the payment reference and amount and reverts with error status
8) Acquiring bank does not credit the merchant account
9) Acquiring bank sends the transaction response to NPCI, with response code MA along with error
message description
11) Issuing bank reverses the customer debit, sends confirmation SMS to customer, and sends response to
customer in Issuing bank application
12) Acquiring bank updates merchant back-end system
13.2
What if acquiring bank is not able to send payment reference verification
request to merchant?
Page 15
1. Customer initiates transaction through Issuing Bank mobile banking application, enters merchant MMID,
mobile number, Amount, M-PIN, Payment reference
2. The information is received by the Issuing Bank, Issuing Bank verifies customer account and debits the
account
3. Issuing Bank forwards information to NPCI
4. NPCI forwards to Acquiring Bank, based on merchant MMID and mobile number
5. Acquiring Bank verifies merchant MMID and mobile number
6. Acquiring Bank is not able to send verification of payment reference request to merchant due to
communication failure
7. Acquiring bank generates Transaction Denied message with response code MF (Merchant system not
available, please try again)
8. Acquiring bank sends response to NPCI
9. NPCI forwards the transaction response to Issuing Bank
10. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
response to customer in Issuing bank application
11. Acquiring bank updates merchant back-end system (if required)
13.3
What if there is no response from merchant to payment reference
verification request?
Page 16
mobile number, Amount, M-PIN, Payment reference
account
4. NPCI forwards to Acquiring Bank, based on merchant MMID and mobile number
5. Acquiring Bank verifies merchant MMID and mobile number
6. Acquiring Bank sends verification of payment reference request to merchant
7. Merchant not able to respond to verification request
8. Acquiring bank generates Transaction Denied message with response code MF (Merchant system
not available, please try again)
9. Acquiring bank sends response to NPCI
10. NPCI forwards the transaction response to Issuing Bank
11. Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
12. Acquiring bank updates the merchant back-end system (if required)
13.4
What if payment reference online verification is successful, but merchant
back-end system is not updated successfully?
account
6) Acquiring Bank sends the Payment Reference information viz. policy number and amount to the
merchant back-end system
7) Merchant verifies the policy number and amount and reverts with status
Page 17

8)
9)
10)
11)
Acquiring bank credits the merchant account, and sends SMS to merchant
Acquiring bank sends the transaction response to NPCI, with response code 00
NPCI forwards the transaction response to Issuing Bank
Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank
application
12) Acquiring bank updates merchant back-end system, but unable to do so. This will not affect the
transaction processing. The acquiring bank system will know the status of merchant back-end system
updation step, and can intimate the merchant regarding the transactions where the step did not get
executed properly. Merchant can do the reconciliation with the back-end system, can update the system
manually or can do refund of the transactions through the acquiring bank platform
13.5
What if there is no online interface with merchant?
account
5) Acquiring Bank verifies merchant MMID and mobile number, and credits the merchant account
6) Acquiring bank sends confirmation SMS to merchant regarding the transaction
7) Acquiring bank sends the transaction response with response code 00 to NPCI
9) Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank
application
13.6
What if acquiring bank rejects transaction?
Page 18
account
5) Acquiring Bank verifies merchant MMID and mobile number, and rejects the transaction with negative
response code
6) Acquiring bank sends the transaction response with negative response code to NPCI
8) Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
The decline from acquiring bank can be due to multiple reasons such as account validations, wrong MMID /
Mobile number of merchant, other reasons, etc
13.7
What if customer wants to make payment to individual beneficiary, but
uses person-to-merchant form on mobile banking application?
Page 19

mobile number, Amount, M-PIN, Payment reference in the person-to-merchant form
account
4. NPCI forwards to acquiring bank based on merchant MMID
5. Acquiring bank checks if the merchant mobile number and merchant MMID belong to the merchant or an
individual. If individual, then acquiring bank will decline the transaction with response code MK Payee
is an individual and not a merchant. Please use person-to-person form for making payment, and
advises the customer to use person-to-person form for making payment instead. Response is sent by
acquiring bank to NPCI
6. NPCI forwards the response to Issuing bank
7. Issuing Bank reverses the customer debit
8. Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank
application
13.8
What if customer wants to make payment to merchant, but uses personto-person form on mobile application by mistake?
1. Customer initiates transaction through Remitter Bank mobile banking application, enters beneficiary
MMID, beneficiary mobile number, Amount, M-PIN on the person-to-person form on mobile banking
application
2. The information is received by the Remitter Bank, Remitter Bank verifies customer account and debits
the account
3. Remitter Bank forwards information to NPCI
4. NPCI forwards to beneficiary bank based on beneficiary MMID
5. Beneficiary bank checks if the beneficiary mobile number and beneficiary MMID belong to the merchant
or an individual. If merchant, then beneficiary bank will decline the transaction with response code ML Payee is a merchant and not an individual. Please use person-to-merchant form for making payment,
and advises the customer to use person-to-merchant form for making payment instead. Response is
sent by acquiring bank to NPCI
6. NPCI forwards the response to Remitter bank
7. Remitter Bank reverses the customer debit
Page 20

8. Remitter Bank sends confirmation SMS to customer, and sends response to customer in Remitter bank
application
13.9
What if there is time-out in the transaction flow?
Timeout scenarios
to
During Debit Between Issuing Bank and its CBS. Reversal will be generated by Issuing Bank system
CBS and the transaction is not processed further. Customer is appropriately informed
After Debit Between Issuing Bank and NPCI Issuing Bank will treat this as time-out transaction.
Issuing Bank will send out Verification Request giving the reference number of the original transaction
to NPCI. Verification request is sent post time-out period of original transaction (30 seconds). Issuing Bank may
send max up to 3 verification requests for one transaction, if it does not receive a response. Acquiring Bank will
respond to this request as per status of original transaction (00 for successful verification and credit transaction
and M0 for credit not successful but verification is successful). Based on response to this request, Issuing Bank
shall reverse the earlier debit (if response code is M0).
After Debit between NPCI and Acquiring Bank This transaction is responded by time-out response
Code by NPCI and send to Issuing Bank. Upon receiving a time-out response, Issuing Bank will send
out a verification request giving the reference number of the original transaction to NPCI. Verification request is
sent post time-out period of original transaction (30 seconds). Issuing Bank may send max up to 3 verification
requests for one transaction, if it does not receive a response. Acquiring Bank will respond to this request as per
status of original transaction (00 for successful verification and credit transaction and M0 for credit not
successful but verification is successful). Based on response to this request, Issuing Bank shall reverse the
earlier debit (if response code is M0).
After Debit between Acquiring Bank switch and CBS This transaction is responded by time-out
Page 21

Response code by Acquiring bank to NPCI and NPCI passes it to Issuing Bank. Issuing Bank will send
out a verification request giving the reference number of the original transaction to NPCI. Verification request is
sent post time-out period of original transaction (30 seconds). Issuing Bank may send max up to 3 verification
requests for one transaction, if it does not receive a response. Acquiring Bank will respond to this request as per
status of original transaction (00 for successful verification and credit transaction and M0 for credit not
successful but verification is successful). Based on response to this request, Issuing Bank shall reverse the
earlier debit (if response code is M0).
14. For Merchant initiated transaction (P2M PULL), what is the transaction message
flow?
The transaction flow is as follows:
1. The customer can initiate the transaction through merchant application. Merchant application could be
based on Web, IVR, or mobile handheld application. Customer enters following information for payment
a. Customer mobile number
b. Customer MMID
c. Amount
d. OTP
2. The transaction is forwarded by merchant application to acquiring bank switch. The information sent by
merchant application includes above payment information by customer, as well as merchant mobile
number and MMID
3. The Acquiring Bank validates merchant credentials (this includes merchant mobile number, MMID, and
may be IP address, username, password, etc as may be provided by acquiring bank to merchant for
authentication of merchant) and sends the transaction to NPCI
4. NPCI validates the request, and based on the NBIN (part of MMID), NPCI identifies the issuing bank and
sends the transaction to the same for debit from the customer account
5. The issuing bank verifies the customer details, fetches the account number and debits the customer
account (based on customer mobile number, customer MMID, amount, and OTP)
6. The issuing bank sends the transaction response to NPCI
7. The issuing bank sends an SMS confirmation to the customer informing him of the debit
8. NPCI sends this response to the acquiring bank
9. Acquiring bank based on the response received, credits the merchant account
10. Acquiring bank sends the transaction response to merchant application
11. Merchant application sends the transaction response to customer via SMS
Page 22
14.1
What if there is rejection at Issuing Bank?
1. Merchant application sends request to acquiring bank. This information includes customer mobile
number, customer MMID, amount, OTP, merchant mobile number, merchant MMID.
2. The acquiring bank validates merchant credentials (this includes merchant mobile number, merchant
MMID, IP address, username, password, etc, as may be provided by acquiring bank to merchant for
authentication of merchant) and originates a financial request
3. The acquiring bank sends this financial request to NPCI
4. NPCI validates the request and forwards this financial request to issuing bank
5. The issuing bank rejects transaction due to some error, and generates an appropriate financial response
6. The issuing bank sends this financial response to NPCI
7. NPCI forwards this financial response to the acquiring bank
8. Acquiring bank sends response to merchant application, and may send SMS to merchant mobile
number
14.2
What if there is rejection at NPCI?
Page 23

4. NPCI validates the request and rejects because of NBIN of customer is not in the list of valid NBINs in
the repository of NPCI, or member bank limit is exceeded or the issuing bank is not yet enabled for
IMPS merchant payments
5. NPCI sends response to acquiring bank with response code 86 or M6 or MG respectively
6. Acquiring bank sends response to merchant application, and may send SMS to merchant mobile
number
14.3
What if Acquiring Bank cannot forward message to NPCI due to
communication failure?
3. Acquiring Bank is not able to forward the request to NPCI.
4. Acquiring bank generates 08 (Transaction declined) response and sends to merchant application, and
may send SMS to merchant mobile number
14.4
What if NPCI cannot forward the financial message to Issuing Bank due to
Page 24

4. NPCI validates the request and is not able to forward this financial request to the issuing bank
5. Since NPCI does not provide the stand-in processing on behalf of the issuing bank, it generates and
sends a response with response code 08 to the acquiring bank
6. Acquiring bank sends the response to merchant application with Transaction Declined message, and
14.5
What if Issuing Bank cannot forward the financial message to its CBS due
to communication failure?
4. NPCI validates the request and forwards this financial request to the Issuing bank
5. The issuing bank is not able to forward this financial message to its CBS
6. The issuing bank generates a response financial message with the response code 08
9. Acquiring bank sends response to merchant application with Transaction Declined message, and may
send SMS to merchant mobile number
14.6
What if Issuing Bank does not receive response from its CBS after
sending the financial message due to communication failure?
Page 25
5. The issuing bank forwards this financial message to its CBS
6. The issuing bank CBS does not respond to the issuing bank
7. Issuing Bank reverses the entry, and sends a response financial message with response code 91
9. NPCI forwards the financial response to the acquiring bank
10. Acquiring bank sends the response to merchant application with Transaction Denied message , and
14.7
What if Issuing Bank does not respond to NPCI after sending the financial
message due to communication failure?
Page 26

5. The issuing bank forwards this financial message to its CBS
6. The issuing bank CBS debits the customer account (based on customer mobile number, MMID, amount,
and OTP) and responds to issuing bank
7. The issuing bank either does not generate a response financial message or is not able to send this
financial response message to NPCI
8. Since NPCI does not provide the stand-in processing on behalf of the issuing bank, it generates and
sends a time out response with response code 91 to the acquiring bank
9. NPCI initiates a 0420 reversal advice and forwards this message to Issuing Bank (response code 91)
10. The Issuing Bank responds with the appropriate 0430 Reversal Advice Response and forwards this
message to NPCI
11. Acquiring bank sends the response to merchant application with Transaction Denied message, and
14.8
What if NPCI does not forward response to Acquiring Bank after receiving
the financial message from Issuing Bank, due to communication failure?
5. The issuing bank debits the customer account (based on customer mobile number, MMID, amount, and
OTP) and generates a response financial message
6. Issuing bank sends response message to NPCI
7. Issuing bank sends SMS to customer about debit
8. NPCI is not able to send response message to acquiring bank due to communication failure
9. Acquiring bank initiates a 0420 reversal advice and forwards this message to NPCI (response code 68)
10. NPCI forwards the 0420 message to Issuing Bank
11. Issuing bank credits the customer account and generates a response 0430 message
12. Issuing bank sends 0430 response message to NPCI
13. Issuing bank sends SMS to customer about credit
14. NPCI forwards 0430 message to Acquiring Bank
15. Acquiring bank sends the response to merchant application with Transaction Denied message, and
Page 27
14.9
What if Acquiring bank is not able to forward message to its CBS, after
receiving the financial message from Issuing Bank, due to communication
failure?
5. The issuing bank debits the customer account (based on customer mobile number, customer MMID,
amount, and OTP) and generates a response financial message
8. NPCI forwards response message to acquiring bank
9. Acquiring bank not able to forward message to its CBS
10. Acquiring bank sends 0420 reversal advice to NPCI (response code 21)
14.10
What if acquiring bank does not receive response from CBS, after sending
message to CBS for merchant credit, due to communication failure?
Page 28
5. The issuing bank debits the customer account (based on customer mobile number, MMID, amount, and
OTP) and generates a response financial message
8. NPCI forwards response message to acquiring bank
9. Acquiring bank forwards message to its CBS
10. CBS not able to respond back to Acquiring Bank
11. Acquiring bank reverses transaction at its end, and forwards reversal advice 0420 message to NPCI
(response code 21)
14.11
What if Acquiring Bank is not able to respond to merchant due to
Page 29

4. NPCI validates the request and forwards this financial request to issuing bank
5. The issuing bank debits the customer account (based on customer mobile number, customer MMID,
amount, and OTP) and generates an appropriate financial response
7. Issuing bank sends SMS to customer with transaction status
9. Acquiring bank credits the merchant account
10. Acquiring bank sends SMS to merchant mobile number. Acquiring bank is not able to send the response
to merchant application
11. Merchant application should be able to pull the transaction status from acquiring bank via API. Acquiring
bank should provide appropriate API to merchant for the same, and this should be part of the integration
between merchant and acquiring bank
14.12
What if there is time-out to the reversal advice message?
1. If timeout appears, the acquirer or NPCI will create and repeat a 0421 reversal request in regular
intervals until the number of repetitions reaches a pre-defined value (3 excluding first 0420) or the
0430 response is received
2. Upon receipt of 042x request, the NPCI or issuer will match this message to possible previous
messages and perform the appropriate action based on matching result
15. What is the dispute management process for IMPS merchant payments?
Page 30

IMPS offers Dispute Management System (DMS) to member banks for handling disputes in the transactions.
Following facilities are available through DMS system:
1.
2.
3.
4.
5.
6.
7.
8.
Debit adjustment
Credit adjustment (Refund)
Chargeback
Re-presentment
Pre-arbitration
Pre-arbitration accept / decline
Arbitration
Good-faith
15.1
Debit adjustment
Debit adjustment is applicable to P2M Push transactions which are timed-out. The merchant account is credited
by acquiring bank, but the status is not known to NPCI or to Issuing Bank because of connectivity failure. Issuing
bank initiated 3 verification requests as well, but not able to get the status because of time-out issue.
In this particular situation, the debit to customer account is not reversed by the Issuing Bank. The interbank
settlement is also not done for this transaction by NPCI. If merchant account is credited by acquiring bank, but
they have not received the credit by NPCI, they shall incur shortfall for this transaction. Therefore, Acquiring
bank can raise debit adjustment for this transaction through DMS system.
Debit adjustment can be raised only in following situations:
1. The transaction is time-out
2. Acquiring bank can raise debit adjustment
3. Debit adjustment can be raised within 7 days of transaction date
Once the debit adjustment is raised, acquiring bank shall be credited and issuing bank shall be debited. This
shall happen automatically next day by NPCI.
Acquiring bank shall identify such transactions through their reconciliation process.
If merchant account is not credited, acquiring bank shall not take any action. Issuing bank can then reverse the
customer debit after 7 days.
15.2
Credit adjustment (Refund)
There are instances in which the Acquiring Bank or the merchant needs to issue refund to the Issuing Bank. The
situations in which refund could be raised are as follows:
1.
2.
3.
4.
5.
6.
Non-receipt of goods/services
Not as described or defective merchandise
Cancelled / Returned goods/services
Incorrect transaction amount
Duplicate processing
Incorrect payment reference
Page 31

7. Customer account is debited, but merchant account not credited, and reversal of customer debit not
processed
Facility for raising credit adjustment (Refund) is available in the DMS system. Credit adjustment can be raised in
following conditions:
1.
2.
3.
4.
5.
Acquiring bank can raise credit adjustment

Credit adjustment can be raised for successful transactions
Credit adjustment can be raised within 60 days of transaction date
Credit adjustment cannot be raised if chargeback is already raised for this record
Facility to provide partial credit adjustment shall be available in the system. Multiple partial credit
adjustments can be raised as well as long as sum total of credit adjustments does not exceed the
original transaction amount.
Credit adjustment can be raised as single record, or as bulk upload. The credit adjustment records shall be
picked up in the settlement cycle. Acquiring bank shall be debited and Issuing Bank shall be credited. This shall
happen automatically next day by NPCI.
Acquiring Bank can upload bulk file with following fields to raise credit adjustments:
1.
2.
3.
4.
5.
Bank adjustment reference

Transaction date
Adjustment amount
RRN
Reason code
15.3
Chargeback
Chargeback can be raised by Issuing Bank, within 60 days of transaction date.

Chargeback can be raised for the reasons as shown below. Please note that chargeback can be raised only for
technical reasons currently, and not for business reasons.
Issuing bank should provide documentation for the chargeback as shown below.
When chargeback is raised, acquiring bank shall be debited and Issuing bank shall be credited. This will happen
next day automatically by NPCI.
Reason code
102
Reason description
Customer account is
debited, merchant
account is not credited,
and reversal of
customer debit is not
processed
Documentation required
Issuing bank CBS and mobile payment switch logs to
demonstrate customer account was debited
Customer account information to demonstrate debit
Customer complaint regarding merchant account not credited
NPCI record containing transaction status
Settlement records demonstrating transaction was settled
Documentation to prove there was no credit adjustment raised
by the acquiring bank
Page 32

107
Duplicate processing
15.4
RRN number of first transaction must be provided. The merchant

name and location, transaction amount, payment reference (if
provided), and the transaction date must be the same. Issuers must
review transactions presented with ticket numbers closely. If the
ticket numbers are different, the transactions are not considered
duplicates, although the merchant locations, transaction amounts,
and transaction dates may be the same
Re-presentment
1. Acquiring bank can re-present the charge to NPCI, for the chargeback dispute case, within 30 days of
chargeback date
2. Acquiring bank can upload the evidence copies via online DMS system.
3. When re-presentment is raised, issuing bank will be debited, and acquiring bank will be credited. This
will happen the next day automatically by NPCI
4. The reason code to be used for re-presentment and documentation to be provided is as depicted below
Chargeback
reason
102 - Customer
account is debited,
merchant account is
not credited, and
reversal of customer
debit is not
processed
107 Duplicate
processing
15.5
Re-presentment
reason
201 - See
corresponding
documentation /
chargeback
remedied
Documentation required
204 Credit
previously issued
201 - See
corresponding
documentation /
chargeback
remedied
The acquirer needs to provide the date that it processed the credit
to the customers account
The acquirer can provide documentation to support two separate
transactions by providing two different TIDs with the same customer
account number
204 Credit
previously issued
The acquirer needs to provide the date that it processed the credit
to customers account
The acquirer needs to substantiate that merchant account was

credited, and need to provide following supporting documentation
a. Acquiring bank CBS and mobile payment logs that indicate
that merchant account was credited
b. Merchant account information
Pre-arbitration
1. If the chargeback was valid and acquirer failed to remedy the dispute properly, the issuer may continue
the chargeback through pre-arbitration procedure. Pre-arbitration can be raised within 30 days of representment
2. A progressive documentation is required with the pre-arbitration in response to new information or
rebutting any acquirer explanation provided with the re-presentment. The progressive documentation
Page 33

must be dated after the re-presentment and specifically address the rebuttal provided with the representment
3. Disputes satisfying the validation process will be processed by DMS Online system
4. Acquiring Bank has to respond to the pre-arbitration raised by Issuing Bank within 15 days from the prearbitration date
15.6
Pre-arbitration decline
1. Acquiring Bank can decline the pre-arbitration along with reasons and attachments. A progressive
documentation is required with the pre-arbitration decline in response to new information or rebutting
any issuing bank explanation provided with the pre-arbitration. The progressive documentation must be
dated after the pre-arbitration and specifically address the rebuttal provided with the pre-arbitration.
15.7
Pre-arbitration Accept
1. Acquiring bank can accept the pre-arbitration within 15 days, and the amount of re-presentment will be
reversed to the Issuing bank.
2. In the absence of response from the Acquiring Bank within 15 days, the pre-arbitration submitted by the
Issuing Bank would be considered as accepted (by default) and the amount of re-presentment will be
reversed to the Issuing Bank.
3. In case of acceptance of pre-arbitration or deemed acceptance (in absence of response), a flat penalty
of Rs 100 will be imposed at the time of Pre-arbitration, for uploading of incorrect copies of documents /
records by Acquiring Bank. This amount will be credited to the Issuing Bank.
15.8
Arbitration
1. Where a decline by the Acquiring Bank is not acceptable to the Issuing Bank, they can refer the issue for
arbitration by manual process.
15.9
What are the procedures for handling arbitration in the IMPS network?
The procedures for handling arbitration in the IMPS network are as follows:
1. The timeframe for referring a dispute to arbitration is 30 days from the date of closure of pre-arbitration
process
2. All disputes pertaining to settlements will be referred to Panel for Resolution of Disputes (PRD)
3. The processing fee for referring dispute to arbitration is Rs 500
4. The Panel for Resolution of Disputes (PRD) as defined in the RBI circular DPSS.CO.CHD.No.
654/03.01.03/2010-2011 dated September 2010 will be constituted from the members of the steering
committee
5. The PRD will comprise of 5 members, 4 members of the steering committee and the Chairman who will
be either the Chief Executive Officer or the Chief Operating Officer of NPCI.
Following are the members of PRD for IMPS:
Page 34

1)
2)
3)
4)
SBI
ICICI Bank
Axis Bank
Corporation Bank
The COO of NPCI shall be the Chairman.

6. In case of specific disputes involving any member(s) of the PRD, the member(s) concerned shall be
replaced by other member(s) of IMPS for the limited purpose of looking into the specific dispute.
7. The PRD shall dispose of the dispute within 15 working days of submitting the dispute
8. Any party aggrieved by the decision of PRD can approach the Appellate Authority for review. Relevant
provisions of RBI circular DPSS.CO.CHD.No. 654/03.01.03/2010-2011 dated September 24, 2010 will
be applicable.
9. The Appellate Authority shall dispose of the appeal within 15 working days of submitting the appeal
10. Until the disposal of appeal by the Appellate Authority, the PRD can decide to levy the refund /
compensation and hold such amount in an interim account till disposal of the appeal as per the RBI
circular DPSS.CO.CHD.No. 654/03.01.03/2010-2011 dated September 24
15.10
What is the Penalty for non-compliance of Settlement Guidelines
NPCI will levy a penalty of Rs 100 for each instance of non-compliance of any provision of the IMPS Dispute
Management & Settlement guidelines.
15.11
What are the Good-faith guidelines for IMPS transactions?
1. The good-faith window is available for those cases where chargeback/re-presentment/debit adjustment
timeframe is lapsed
2. Transactions for which chargeback/re-presentment/debit adjustment was not raised within the
prescribed timeframe can be represented through the good-faith
3. The good-faith request has to be lodged by issuer/acquirer within 30 days of expiry date of
chargeback/re-presentment/debit adjustment. The good-faith resolution timeframe is 30 days from the
date of raising good-faith
4. Only accepted cases will have a commercial impact. The transaction value will be included in that days
settlement files for transfer of money to the member bank account
5. For decline cases, there will be no commercial impact
15.12
What are the guidelines for handling customer complaints in IMPS
network?
In mobile remittance a debit to a customers account takes place first at his / her request and therefore it is
expected that there can only be complaint about beneficiary not receiving the credit. Any complaint about credit
not being given to a beneficiary should be conclusively and bilaterally dealt with by the Remitting and Beneficiary
banks within 3 days from the date of the complaint
16. What are the features required in merchant acquiring platform?

The merchant acquiring platform needs to have following features:
Page 35
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Merchant account setup

Integration with merchant back-end system
Merchant technical configuration
Merchant financial configuration
Transaction processing
Transaction MIS
Reconciliation
Settlement with merchant
Refund processing
Dispute management system
17. How does merchant get integrated with Acquiring Bank?

Integration kit is shared between Merchant and Acquiring Bank, and integration carried out accordingly.
17.1
For push transactions
Acquiring bank should be able to integrate with merchant back-end system for payment reference verification
and update of merchant back-end system after transaction is complete
17.2
For pull transactions
API to be provided by acquiring bank to merchant for integration with merchant website / WAP application
For SMS / IVR / mobile handset application, the following integration could be required with merchant
application:
1. Pre-payment integration before the payment, the merchant payment reference data may need to be
verified. This can be done through the pre-payment merchant URL, where merchant URL is called and
payment reference field is passed. If successful response is received, further processing is done for
payment transaction, otherwise error message is sent
2. Post-payment integration after the payment, the merchant back-end system may be called to update
the transaction status at the back-end
The above two can be configured in the merchant technical configuration of the merchant account
Verification integration - If response is not received by merchant for transaction request, merchant should be
able to call verification URL for verifying transaction status at acquiring bank.
Page 36

18. What are the various interfaces through which merchant can receive payment via
IMPS merchant payments PULL transaction?
Acquiring bank needs to provide an application to merchant to receive payment.
Following types of applications can be provided:
1.
2.
3.
4.
Web application for receiving payments via web

IVR application
Merchant mobile handset application for receiving payments from customers
SMS based application
18.1
Web application for integration with merchant web site
Acquiring bank will provide a payment web page. This will be integrated with merchant website. Customer will be
redirected to this webpage during the payment step of the transaction. The following parameters will be passed
from merchant website to the payment web page:
1.
2.
3.
4.
5.
6.
Merchant user name

Merchant password
Merchant IP address
Amount (if pre-populated)
Customer mobile number (if pre-populated)
Payment reference (if pre-populated)
The payment web page will validate the merchant details, such as user name, password, IP address, and allow
payment only if validation is successful
The above page will contain following input fields from customer:
1.
2.
3.
4.
5.

Customer MMID
OTP
Amount (pre-populated, if available)
Payment reference (pre-populated, if available)
This will be a secure page. Information from the secure page will be sent to the acquiring bank switch. Following
parameters will be sent to acquiring bank switch:
1.
2.
3.
4.
5.
6.
7.
Merchant mobile number

Merchant MMID
Customer MMID
OTP
Amount
Payment reference
18.2
WAP application for integration with merchant WAP site

Page 37

Similar to above web application
18.3
IVR application
Acquiring bank will provide an IVR number to merchant for receiving payments. Merchant can call the IVR
number, and will be prompted to enter merchant ID. If merchant calls from his registered mobile number or
phone number, the step to capture merchant ID can be skipped. Upon identifying the merchant, IVR will prompt
to enter amount. Merchant will then be asked to conference the customer with the IVR call. Customer will get the
confirmation of merchant name, and amount to be paid, will be prompted to asked to enter mobile number,
MMID, and OTP. The information will be sent to acquiring bank switch, and IVR will wait for transaction status to
be received. Once the transaction status is received, customer will be informed about the same on the IVR call.
18.4
Merchant mobile handset application
Acquiring bank can provide a mobile handset application to the merchant. Merchant downloads the application
on his handset and registers his mobile number with the acquiring bank. The application has a Receive
payment form on the handset application.
For receiving payment from customer, the merchant enters customer mobile number, MMID, OTP, amount, and
payment reference. Merchant is identified from the mobile number from where the request is initiated.
The transaction status is received on the mobile handset application of merchant.
18.5
SMS based application for customer
Customer sends SMS with following parameters: merchant short name, amount, payment reference, MMID,
OTP
The acquiring bank platform validates the merchant short name, payment reference, amount. On successful
validation, acquiring bank shall send customer mobile number, MMID, and OTP to NPCI for further transaction
processing. Upon successful response, customer and merchant receive confirmation SMS.
18.6
SMS based application for merchant
Merchant can initiate payment via SMS for receiving payment from customer. Merchant registers his mobile
number with his merchant account with the acquiring bank. From his registered mobile number, merchant sends
SMS with following parameters:
1. Customer mobile number

2. Amount
3. Payment reference
An IVR call or USSD message is made to the customer mobile number, and is prompted for merchant name,
amount and is asked to confirm or reject the transaction. Alternatively, merchant sends SMS with customer
mobile number, MMID and OTP.
Upon confirmation, customer will be asked to enter MMID, and OTP.
Page 38
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
18.7
Reminder SMS based application
Merchant can send a reminder SMS to customer for payment. The SMS will contain details about the payment.
Customer will respond to the SMS with a reply SMS, and will send following parameters in the SMS:
1.
2.
3.
4.
5.
Merchant ID
Amount
Payment reference
Customer MMID
OTP
The acquiring bank will receive the SMS, will validate the various information, along with payment reference, and
does transaction processing through NPCI
18.8
Merchant server application
Customer can call merchant call center for ordering product /service and making payment. The agent will help
customer with the order, and enter following information in his merchant server application:

2. Amount
Merchant will initiate the payment transaction upon entering the above information. Customer will receive an IVR
call or USSD message on his mobile and will prompted for merchant name, amount and is asked to confirm or
reject the transaction.
Upon confirmation, customer will be asked to enter MMID, and OTP.
18.9
USSD based application
Merchant can initiate payment transaction via USSD. Acquiring bank to provide USSD number to the merchant.
Merchant initiates transaction through the USSD number. A form is sent by the USSD server to the merchant,
and merchant is prompted to enter customer mobile number, amount, and payment reference.
Upon entry of these details, a USSD message or IVR call will be sent to customer and will be prompted for
merchant name and amount and will be asked to confirm or reject the transaction. Upon confirmation, customer
Page 39

will be asked to enter customer MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID
and OTP on the USSD form.
18.10
STK based application
The merchant transaction initiation form will be available on the merchant SIM card. Merchant accesses the form
on the SIM card for initiating payment from customer, and enters following parameters
2. Amount
An IVR call or USSD message is sent to the customer mobile number, and is prompted for merchant name,
amount and is asked to confirm or reject the transaction. Upon confirmation, customer will be asked to enter
MMID, and OTP. Alternatively, merchant enters customer mobile number, MMID and OTP on the USSD form.
18.11
WAP based application
Merchant can access the WAP site provided by acquiring bank for initiate payment transaction from customer.
Merchant can log on to the WAP site, and can access payment initiation page. Merchant will enter customer
mobile number, amount, payment reference.
18.12
Internet based application
Merchant can access the Internet site provided by acquiring bank for initiate payment transaction from customer.
Merchant can log on to the web site, and can access payment initiation page. Merchant will enter customer
mobile number, amount, payment reference.
Page 40

19. What is the merchant configuration required at the acquiring bank platform?
The following configuration needs to be there in the acquiring side platform:
19.1
Merchant set-up
Acquiring bank could set up the merchant account through web interface. Access should be provided on need
basis to required personnel. Bank should be able to enter following information related to the merchant:
1.
2.
3.
4.
5.
6.
7.
8.
Merchant name
Address
Contact information
Merchant MMID
Merchant Mobile number
Merchant account number
Merchant IFSC code
Merchant category code
19.2
Merchant configuration
Following configuration is required for merchant:

1.
2.
3.
4.
5.
6.
Payment reference is mandatory or not

Real-time validation is required or not
Real-time status update is required or not after transaction
Confirmation SMS is required to be sent to merchant or not
Confirmation email is required to be sent to merchant or not
Mobile number(s) from where merchant can initiate payment via SMS / USSD / STK
If real-time validation is required, the pre-payment URL is required to be configured

If real-time status update is required, the post-payment URL is required to be configured
If confirmation SMS is required, merchant mobile number is required to be configured where SMS is to be sent
If confirmation email is required, merchant email is required to be configured where email is to be sent
19.3
Financial configuration
The following financial configuration is required to be configured:

1. Transaction fee from merchant
20. What facility is required for transaction status verification for merchant?
An interface should be provided to merchant to verify the transaction status. This is useful in case the transaction
is complete, but merchant doesnt get to see the transaction status.
Page 41

An online API to be provided to merchant that can be used to check transaction status as exception handling
process. In case merchant does not get transaction status, he can call this URL 3 times in 30 seconds interval
and get transaction status.
Apart from exception handling, this interface can be used for getting ad-hoc transaction status as well.
21. What MIS facility may be provided by Acquiring Bank to the merchant?
Acquiring Bank may provide an interface to the merchant to get transaction MIS. The MIS may provide following
facilities to the merchants, so they are able to cater to customers queries without escalating queries to the Bank
every time
1. Download the transactions through MIS for a particular date

2. Download the refunded transactions for a particular date
3. Track the complete lifecycle of particular transaction
a. Life cycle starts with transaction details (transaction date, amount, merchant transaction id,
Bank transaction id, etc)
b. Refund details (if refund processed against that particular transaction, refund date, merchant
transaction id, bank transaction id, amount, refund status, refund transaction number, etc)
c. Dispute adjustment details (if dispute adjustment processed against this particular transaction,
e.g. chargeback, re-presentment, pre-arbitration, etc)
4. Search based on merchant transaction id or bank transaction id
Acquiring Bank may provide settlement and payment advice on daily basis to the merchant for all transactions,
including the disputed transactions.
Acquiring bank may provide intimation to the merchant in case of chargeback, pre-arbitration and other disputes.
22. What is the reconciliation procedure between Bank and Merchant?

Acquiring Bank may provide reconciliation file to the merchant, which contains details on the successful
transactions. The file may contain following fields:
1.
2.
3.
4.
Bank reference number

Amount
Date of transaction
Merchant transaction ID
Based on the above information, merchant shall reconcile with their system, and shall identify all transactions
where they have received the credit, but have not fulfilled the service. Merchant shall prepare a file of such
transactions to issue refund to customers.
Page 42

23. What is the refund procedure between Bank and Merchant?
Merchant shall create a file containing Refund to be made transactions to the Acquiring Bank. The file shall
contain following fields:
1.
2.
3.
4.
Merchant transaction id
Amount
Bank reference number
Date of transaction
Merchant should provide the file for refunds to acquiring bank on the next day of transaction.
Acquiring Bank shall create file for refunds to be issued as per format acceptable in the Dispute Management
System (DMS) for credit adjustment (refund). The file shall be uploaded to the DMS system.
During the settlement cycle, refunds shall be processed. Acquiring Bank shall be debited and respective Issuing
Bank shall be credited. The next day daily settlement report shall contain the details of these adjustments for
Acquiring Bank and respective Issuing Banks.
Issuing Bank shall provide credit to the respective customer based on the advice in the daily settlement report.
Acquiring Bank may provide a file with transactions details of refunds made through the system.
24. What are the security guidelines for acquiring Bank and merchants?
The Merchant needs to have necessary information security controls in place. Merchant should be
educated that critical data processed in IMPS transactions are important and equivalent to card holder
data in debit or credit card transactions or any other bank transactions. They need to follow industry best
practices when it comes to protect business critical data
OTP should not be displayed on the merchant application end user screen in clear text
HTTPS is mandatory between Merchant and Acquirer
Acquirer needs to have strong authentication process for the merchant which includes IP address,
username and password over encrypted channel
Issuer need to adhere strictly on time validation since OTP generation (1 hour for all banks)
The OTP will be used only for one transaction (either successful or failure)
OTP length should be minimum of 6 digits and should be adhered by Issuer as well as Acquirer
Triple DES encryption needs to be in place
OTP and other transaction details from merchant end will traverse on secure channel (HTTPS)
OTP will be encrypted at all times using TDES during the transaction process
OTP transmission from acquirer bank to NPCI to issuing bank can be encrypted/decrypted using HSM
encryption or software encryption.
Mobile number and MMID of customer, if shared with merchant, should be masked by default, by
acquiring bank. In case of MMID, the last 3 digits can be masked. First 4 digits comprising of NBIN can
be left unmasked for easy recognition of issuer bank. However, sharing of customer mobile number and
MMID with select merchants is allowed as per the discretion of the acquirer bank. The liability of misuse
of customer mobile number and MMID lies with the Acquiring Bank. Acquiring Bank should take
necessary precautions for the security and confidentiality of the data and if required as per the discretion
of the Acquiring Bank this can be shared only with select personnel of the merchant
Page 43
OTP should not be stored on merchant application (Just like PCI DSS does not allow storage of
authentication data like CVV, PIN, PIN Block, Mag Stripe data)
Merchant or aggregator application must follow secure application development and deployment
practices.
Merchant or aggregator application must have undergone application security testing comprising of
standards like OWASP Top 10, SANS Top 20, etc.
25. What are the guidelines for settlement of payments for electronic payment
transactions involving intermediaries?
The directions for opening and operation of accounts and settlement of payments for electronic payment
transactions
involving
intermediaries
are
as
per
the
RBI
circular
RBI
/
200910/231/DPSS.CO.PD.No.1102/02.14.08/2009-10 dated November 24, 2009. The details are as below:
The credit to merchant account by Acquiring Bank may or may not be instant, and Banks may decide to settle
funds instantly or on offline basis, as per terms and conditions agreed with merchant.
26. What are the risk management guidelines at Acquiring Bank?

Acquiring bank shall be responsible for the following:
1) Operate a merchant acquiring platform
2) Provide mobile based application to merchants for receiving funds from customers via mobile
3) Decline the transaction if payee is merchant, but person-to-person form is being used for making
payment
4) Decline the transaction if payee is individual, but person-to-merchant form is being used for making
payment
5) Decline the transaction if merchant is determined to be fraud and account is blocked
6) Establish and ensure transaction amount limit for the merchant per customer i.e. merchant should not be
able to receive more than the transaction limit from a single customer on a per hour, per day, per month
basis
7) Establish and ensure number of transactions limit for the merchant per customer i.e. merchant should
not be able to receive more than the number of transactions specified per customer on a per hour, per
day, per month basis
8) Fraud check (online and offline)
9) Alert SMS to be sent to the merchant with customers and merchants details
27. What are the risk management guidelines at Issuing Bank?

Issuing bank shall be responsible for the following:
1) Transaction amount limit applicable to OTP as per mobile payment guidelines of RBI. Depending on the
method of OTP generation, the transaction limit should be applicable. For e.g. if OTP is generated using
Page 44
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
mobile banking application with M-PIN as second factor authentication, and end-to-end encryption, the
limit can be unlimited (based on bank discretion). If it is generated through means which are not end-toend encrypted, transaction limit can be Rs 5,000/- per customer per day. OTP generation process needs
to be two-factor authentication process, as applicable to the funds transfer via mobile operating
guidelines.
Debit authorization for transaction through OTP. Issuing bank needs to validate customer mobile
number, customer MMID, amount, and OTP
OTP time limit. Issuing bank needs to provide OTP with a certain validity period. If transaction is
conducted beyond this validity period, issuing bank needs to decline transaction
Validation of number of transactions in a day
Validation of transaction limit for a mobile in a day
Separate form for customer initiated person-to-merchant payment transactions. Ensure population of
correct values in the transaction request
Multiple requests from same handset within X time period with same reference / transaction number (this
is to avoid multiple requests for the same transactions)
Adequacy of Collateral posted with NPCI for mobile remittances.
AML related validations for Funds Transfer transaction for the debit leg (online or offline)
Fraud Check (online or offline)
An Alert SMS for Debit leg is sent to customer with details of Sender and Beneficiary.
Population of correct values in verification requests. NPCI shall not validate or match any of the values
sent in the verification requests with the original transaction.
28. What is the list of response codes in the IMPS system?

IMPS
Response
Code
CU
Description
ISO8583
Response Code
Technical
decline
Business
decline
HOST (CBS) OFFLINE
08
IU
ISSUER NODE OFFLINE
08
08
PROCESSOR DOWN
91
M0
MO
M1
M2
M3
VER SUCCESSFUL ORG CRD

TRXN DECLINED
INVALID BENEFICIARY
MOBILE NO/MAS
AMOUNT LIMIT EXCEEDED
FOR CUSTOMER
ACCOUNT BLOCKED/FROZEN
M3
M4
NRE ACCOUNT
M4
M5
ACCOUNT CLOSED
M5
M6
M6
86
LIMIT EXCEEDED FOR

MEMBER BANK
INVALID NBIN
92
00
TRANSACTION APPROVED
00
00
TRANSACTION APPROVED
(during verification processing
code will be 032)
00
M1
M2
Page 45

01
INVALID TRANSACTION
12
05
INVALID TRANSACTION TYPE
12
07
INVALID RESPONSE CODE
20
39
UNABLE TO PROCESS
96
MA
Merchant error
MA
MC
Functionality not yet available for

merchant through the payee
bank
Payee is an individual and not a
merchant. Please use person-toperson form for making payment
MC
MK
Payee is a merchant and not an

individual. Please use person-tomerchant form for making
payment
Merchant system not available,
please try again
ML
MF
MK
ML
MF
M9
Invalid / Incorrect OTP
M9
MZ
OTP expired
MZ
MH
OTP transaction limit exceeded
MH
MG
Functionality not yet available for

customer through the issuing
bank
Not sufficient funds
MG
51
30
Transaction not permitted to

account holder
57
18
Invalid message format
30
28
No action taken
21
50
Response received too late
68
08
Issuer or switch is inoperative
91
96
PIN block error
10
14
Exceeds transaction amount limit
61
19
Security violation
63
20
Lost or stolen account
43
01
Error
06
31
Suspected malfunction
22
02
Do not honor
05
38
Duplicate transaction
94
20
Suspected fraud
34
01
Cutoff is in process
90
27
Customer cancellation
17
01
Reconcile error
95
15
Exceeds transaction frequency

limit
Requested function not
supported
65
24
01
40
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Page 46

06
Invalid amount field
13
29. What are the reconciliation files and reports that IMPS provides to the member
banks?
The following reconciliation files and reports are available:
1. Acquirer raw data file for P2M transactions - This contains the transactions where BANK is acquiring the
transactions for P2M acting as remitter in case of PUSH transaction and acting as beneficiary in case
of PULL transaction
2. Issuer raw data file for P2M transactions - This contains the transactions where BANK is receiving the
transactions for P2M acting as beneficiary in case of PUSH transaction and acting as remitter in case
of PULL transaction
3. Beneficiary settlement report for all transactions - This contains all transactions where BANK is acting as
beneficiary.
4. Remitter settlement report for all transactions Remitter Merchant Settlement Report - This contains all
transactions where BANK is acting as remitter.
5. Verification report for P2M transactions - This report contains all verification transactions for P2M
transactions
6. Acquirer reversal This contains all reversal advices initiated from acquiring bank which are dropped at
NPCI switch
7. Issuer reversal This contains all reversal advices to be received by issuing bank which are dropped at
NPCI switch
Page 47

IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2

Enviado por

Direitos autorais:

Formatos disponíveis

IMPS Merchant Payments

For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

What is IMPS merchant payments service? ................................................................................................5

Customer initiated transaction (P2M PUSH) ............................................................................................6

IMPS Merchant Payments For Banks and Merchants

Debit adjustment .................................................................................................................................... 31

For push transactions ............................................................................................................................ 36

Web application for integration with merchant web site ........................................................................ 37

Merchant set-up ..................................................................................................................................... 41

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

Mobile top-up / DTH top-up

The key features of IMPS merchant payments service are as follows:

Instant confirmation to sender and receiver

2. What are the pre-requisites for availing the service?

IMPS Merchant Payments For Banks and Merchants

3. How does it work?

1. Customer Initiated Transaction (P2M PUSH)

3.1 Customer initiated transaction (P2M PUSH)

Merchant mobile number

3.2 Merchant initiated transaction (P2M PULL)

IMPS Merchant Payments For Banks and Merchants

4. What are the use cases for P2M PUSH transactions?

Insurance premium payment

IMPS Merchant Payments For Banks and Merchants

6. What are the use cases for P2M PULL transactions?

7. What is Mobile POS application?

Enterprise agent has mobile POS application on the phone

IMPS Merchant Payments For Banks and Merchants

8. What are the advantages for payment via IMPS?

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

What if there is no online interface with merchant?

The transaction flow in this case is as follows:

What if acquiring bank rejects transaction?

The transaction flow in this case is as follows:

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

What if there is time-out in the transaction flow?

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

What if there is rejection at Issuing Bank?

What if there is rejection at NPCI?

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

IMPS Merchant Payments For Banks and Merchants

What if there is time-out to the reversal advice message?

IMPS Merchant Payments For Banks and Merchants

Credit adjustment (Refund)