IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2
IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2
IMPS Merchant Payments Doc For Banks and Merchants 2 Merchant Payments Doc For Banks and Merchants 2
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
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
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
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
19. What is the merchant configuration required at the acquiring bank platform? .................................... 41
19.1
19.2
19.3
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
This service is brought to you by National Payments Corporation of India (NPCI) in collaboration with Member
Banks.
Page 5
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)
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
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
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
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
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
AVP Internet
Banking
Sr Manager
DGM
022 43256376
[email protected]
[email protected]
[email protected]
DGM IT
Officer IT
9611100524
0824-2426443,
9880622361
9833362823
9730356553
Sr Manager
9820178334
Sr Vice
President
Vice President
DGM
Chief Manager
022-66696360
022-67465623
[email protected]
[email protected]
022-26536050
9820087940
[email protected]
[email protected]
Product
Manager
Associate
Director,
Transaction
Banking
9833900529
9004333123,
022-61157719
[email protected]
[email protected]
022-22741218,
022-22741206
Sr Manager
(Marketing)
EVP
022-22892561
7738947773
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
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
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 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
10) NPCI forwards the transaction response to Issuing Bank
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?
The transaction flow in this case is as follows:
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?
The transaction flow in this case is as follows:
Page 16
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 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
response to customer in Issuing bank application
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?
The transaction flow in this case is as follows:
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 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
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
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, 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
8) NPCI forwards the transaction response to Issuing Bank
9) Issuing Bank sends confirmation SMS to customer, and sends response to customer in Issuing bank
application
13.6
Page 18
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, and rejects the transaction with negative
response code
6) Acquiring bank sends the transaction response with negative response code to NPCI
7) NPCI forwards the transaction response to Issuing Bank
8) Issuing Bank reverses the customer debit, and sends confirmation SMS to customer, and sends
response to customer in Issuing bank application
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?
The transaction flow in this case is as follows:
Page 19
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
13.9
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
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
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
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
Page 23
14.3
What if Acquiring Bank cannot forward message to NPCI due to
communication failure?
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. 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
communication failure?
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
Page 24
14.5
What if Issuing Bank cannot forward the financial message to its CBS due
to communication failure?
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 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
7. The issuing bank sends this financial response to NPCI
8. NPCI forwards this financial response to the acquiring bank
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
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 the Issuing bank
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
8. The issuing bank sends this financial response to NPCI
9. NPCI forwards the financial response to the acquiring bank
10. Acquiring bank sends the response to merchant application with Transaction Denied message , and
may send SMS to merchant mobile number
14.7
What if Issuing Bank does not respond to NPCI after sending the financial
message due to communication failure?
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
Page 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?
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 the Issuing bank
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
may send SMS to merchant mobile number
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?
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 the Issuing bank
5. The issuing bank debits the customer account (based on customer mobile number, customer 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 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)
11. NPCI forwards the 0420 message to Issuing Bank
12. Issuing bank credits the customer account and generates a response 0430 message
13. Issuing bank sends 0430 response message to NPCI
14. Issuing bank sends SMS to customer about credit
15. NPCI forwards 0430 message to Acquiring Bank
16. Acquiring bank sends the response to merchant application with Transaction Denied message , and
may send SMS to merchant mobile number
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
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 the Issuing bank
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 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)
12. NPCI forwards the 0420 message to Issuing Bank
13. Issuing bank credits the customer account and generates a response 0430 message
14. Issuing bank sends 0430 response message to NPCI
15. Issuing bank sends SMS to customer about credit
16. NPCI forwards 0430 message to Acquiring Bank
17. Acquiring bank sends the response to merchant application with Transaction Denied message , and
may send SMS to merchant mobile number
14.11
What if Acquiring Bank is not able to respond to merchant due to
communication failure?
Page 29
14.12
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
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
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
1.
2.
3.
4.
5.
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.
15.3
Chargeback
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
Duplicate processing
15.4
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
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
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
SBI
ICICI Bank
Axis Bank
Corporation Bank
15.10
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
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
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
17.1
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
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
1.
2.
3.
4.
18.1
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.
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.
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.
18.2
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
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
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
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:
18.7
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
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
18.8
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:
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.
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
18.9
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
18.10
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
1. Customer mobile number
2. Amount
3. Payment reference
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.
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
18.11
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.
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.
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
18.12
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.
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.
Upon successful transaction confirmation, an SMS will go to customer as well as merchant.
Page 40
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
19.3
Financial configuration
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
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
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.
1.
2.
3.
4.
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
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.
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.
Description
ISO8583
Response Code
Technical
decline
Business
decline
08
IU
08
08
PROCESSOR DOWN
91
M0
MO
M1
M2
M3
M3
M4
NRE ACCOUNT
M4
M5
ACCOUNT CLOSED
M5
M6
M6
86
92
00
TRANSACTION APPROVED
00
00
TRANSACTION APPROVED
(during verification processing
code will be 032)
00
M1
M2
Page 45
INVALID TRANSACTION
12
05
12
07
20
39
UNABLE TO PROCESS
96
MA
Merchant error
MA
MC
MC
MK
ML
MF
MK
ML
MF
M9
M9
MZ
OTP expired
MZ
MH
MH
MG
MG
51
30
57
18
30
28
No action taken
21
50
68
08
91
96
10
14
61
19
Security violation
63
20
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
65
24
01
40
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Page 46
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