IMPS Merchant Payments For Banks and Merchants. Version 1.0

(1)

IMPS Merchant Payments

For Banks and Merchants

Version 1.0

June, 2012

(2)

Page 2

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. Mobile top-up / DTH top-up

2. Insurance premium payment 3. Online shopping

4. Over-the-counter payments

5. Fees payments to schools / colleges / universities 6. Utility Bill payments

7. Travel & Ticketing

The key features of IMPS merchant payments service are as follows: 1. Instant confirmation to sender and receiver

2. Convenient and time-saving 3. Anytime, anywhere service 4. Safe & secure

5. 24*7*365 availability

6. 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.

(6)

Page 6

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 Bank’s 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. Merchant mobile number 2. Merchant MMID

3. Amount 4. M-PIN

5. 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 Bank’s 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:

(7)

Page 7 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 Bank’s 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. Insurance premium payment 2. Mobile / DTH Recharge 3. Fee payments

4. Credit card payments 5. Utility Bill payments

6. Over-the-counter payments

7. 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.

(8)

Page 8 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 doesn’t 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. Mobile POS

2. Merchant aggregators

3. Retailers, FMCG, Food chains

4. E-commerce, movies, classified, courier 5. Travel & Ticketing, Radio Taxi

6. Mutual Funds 7. Insurance

8. Utility Bill Payments 9. Mobile / DTH recharge 10. Trading / NBFC 11. Credit Cards 12. Fees payments 13. 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. Enterprise agent has mobile POS application on the phone 2. Opens up form ‘Receive payment from customer’

3. Enters payment reference, amount

4. Asks customer to enter mobile number, MMID and OTP

5. Agents mobile number (through which payment is initiated) is linked with merchant account 6. Merchant account is credited and customer account is debited

7. Customer and agent get confirmation SMS

8. 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.

(9)

Page 9 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. Number of mobile users is lot more. Mobile number can be linked to bank account for everyone 2. Replacement of cash

3. Remote payments – via website, IVR, mobile application 4. Mobile POS

5. No investment on POS machine for receiving payment via IMPS 6. 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.

(10)

Page 10

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 Contact

person

Designation Phone Email

Axis Bank Shri Vinay Vasudev

AVP Internet Banking

022 43256376 vinay.vasudev@axisbank.com

Canara Bank Shri Vishal Sr Manager 9611100524 vishal@canarabank.com

Corporation Bank Shri K Ramachandran DGM 0824-2426443, 9880622361 kram@corpbank.co.in Dombivli Nagari Sahakari Bank Shri Milind Varerkar Shri Pratik Gadgil DGM – IT Officer – IT 9833362823 9730356553 milindvarerkar@dnsb.co.in pratikgadgil@dnsb.co.in Greater Bombay Bank Shri Milind Mahadik Sr Manager 9820178334 Milind.mahadik@greaterbank.com

HSBC Shri Vijay Lulla Shri Devendra Verma Sr Vice President Vice President 022-66696360 022-67465623 vijaylulla@hsbc.co.in devendraverma@hsbc.co.in

ICICI Bank Shri Salil Chugh Shri Saurabh Jain DGM Chief Manager 022-26536050 9820087940 salil.chugh@icicibank.com Saurabh.jai@icicibank.com Kotak Mahindra Bank Shri Yogesh Verma Product Manager 9833900529 Yogesh.n.verma@kotak.com Standard Chartered Bank Shri Sachin Tiwari Associate Director, Transaction Banking 9004333123, 022-61157719 Sachin.tiwari@sc.com State Bank of India New Business Department, State Bank Bhavan, Madame Cama Road, Nariman Point, Mumbai 022-22741218, 022-22741206 Union Bank of India Shri Gyan S Narayan Sr Manager (Marketing) 022-22892561 gyannarayan@unionbankofindia.com

Yes Bank Shri Anand Bajaj

EVP 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:

(11)

Page 11 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:

(12)

Page 12 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 Acquirer’s 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 Provider’s 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.

(13)

Page 13 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 Provider’s 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 merchant’s 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 Provider’s environment and the merchant’s own local network are implemented

5.9. It is the merchant’s 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?

(14)

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 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?

(15)

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?

(16)

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 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?

(17)

mobile number, Amount, M-PIN, Payment reference

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

6) Acquiring Bank sends the ‘Payment Reference’ information viz. policy number and amount to the merchant back-end system

(18)

Page 18 8) Acquiring bank credits the merchant account, and sends SMS to merchant

9) Acquiring bank sends the transaction response to NPCI, with response code ‘00’ 10) NPCI forwards the transaction response to Issuing Bank

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?

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

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

13.6 What if acquiring bank rejects transaction?

(19)

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?

(20)

mobile number, Amount, M-PIN, Payment reference in the person-to-merchant form

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

person-to-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

(21)

Page 21 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

During Debit – Between Issuing Bank and its CBS. Reversal will be generated by Issuing Bank system to 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

1

2

3

(22)

Page 22 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

(23)

Page 23

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?

(24)

Page 24 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

communication failure?

(25)

Page 25 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 may send SMS to merchant mobile number

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’ 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?

(26)

Page 26 1. Merchant application sends request to acquiring bank. This information includes customer mobile

number, customer MMID, amount, OTP, merchant mobile number, merchant MMID.

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?

(27)

Page 27 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 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 may send SMS to merchant mobile number

14.8 What if NPCI does not forward response to Acquiring Bank after receiving

the financial message from Issuing Bank, due to communication failure?

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

(28)

Page 28

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

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

14.10 What if acquiring bank does not receive response from CBS, after sending

message to CBS for merchant credit, due to communication failure?

(29)

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

14.11 What if Acquiring Bank is not able to respond to merchant due to

communication failure?

(30)

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

6. The issuing bank sends this financial response to NPCI 7. Issuing bank sends SMS to customer with transaction status 8. NPCI forwards this financial response to the acquiring bank 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

(31)

Page 31 IMPS offers Dispute Management System (DMS) to member banks for handling disputes in the transactions. Following facilities are available through DMS system:

1. Debit adjustment

2. Credit adjustment (Refund) 3. Chargeback

4. Re-presentment 5. Pre-arbitration

6. Pre-arbitration accept / decline 7. Arbitration

8. 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. Non-receipt of goods/services

2. Not as described or defective merchandise 3. Cancelled / Returned goods/services 4. Incorrect transaction amount

5. Duplicate processing 6. Incorrect payment reference

(32)

Page 32 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. Acquiring bank can raise credit adjustment

2. Credit adjustment can be raised for successful transactions 3. Credit adjustment can be raised within 60 days of transaction date

4. Credit adjustment cannot be raised if chargeback is already raised for this record

5. 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. Bank adjustment reference

2. Transaction date 3. Adjustment amount 4. RRN

5. 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 Reason description Documentation required

102 Customer account is

debited, merchant account is not credited, and reversal of

customer debit is not processed

 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

(33)

Page 33 107 Duplicate processing 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

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 Re-presentment reason Documentation required 102 - Customer account is debited, merchant account is not credited, and reversal of customer debit is not processed 201 - See corresponding documentation / chargeback remedied

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 204 – Credit

previously issued

The acquirer needs to provide the date that it processed the credit to the customer’s account

107 – Duplicate processing 201 - See corresponding documentation / chargeback remedied

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 customer’s account

15.5 Pre-arbitration

1. If the chargeback was valid and acquirer failed to remedy the dispute properly, the issuer may continue the chargeback through parbitration procedure. Parbitration can be raised within 30 days of re-presentment

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

(34)

Page 34 must be dated after the presentment and specifically address the rebuttal provided with the re-presentment

3. Disputes satisfying the validation process will be processed by DMS Online system

4. Acquiring Bank has to respond to the arbitration raised by Issuing Bank within 15 days from the pre-arbitration 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.

IMPS Merchant Payments For Banks and Merchants. Version 1.0