IMPS Merchant Payments For Banks and Merchants. Version 1.0

Transcription

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

2 Contents 1. What is IMPS merchant payments service? What are the pre-requisites for availing the service? How does it work? Customer initiated transaction (P2M PUSH) Merchant initiated transaction (P2M PULL) What are the use cases for P2M PUSH transactions? How does customer make face-to-face payment using IMPS P2M PUSH? What are the use cases for P2M PULL transactions? What is Mobile POS application? What are the advantages for payment via IMPS? What are the amount limits for transactions through IMPS merchant payments? How can the merchant get on-boarded on IMPS merchant payments? Who are the contact persons in the Banks to get on-boarded on IMPS merchant payments? What are the merchant on-boarding process guidelines for Acquirer Bank? For Customer initiated transaction (P2M PUSH), what is the transaction message flow? What if there is an error in payment reference and amount entered by customer? What if acquiring bank is not able to send payment reference verification request to merchant? What if there is no response from merchant to payment reference verification request? What if payment reference online verification is successful, but merchant back-end system is not updated successfully? What if there is no online interface with merchant? What if acquiring bank rejects transaction? What if customer wants to make payment to individual beneficiary, but uses person-to-merchant form on mobile banking application? What if customer wants to make payment to merchant, but uses person-to-person form on mobile application by mistake? What if there is time-out in the transaction flow? For Merchant initiated transaction (P2M PULL), what is the transaction message flow? What if there is rejection at Issuing Bank? What if there is rejection at NPCI? What if Acquiring Bank cannot forward message to NPCI due to communication failure? What if NPCI cannot forward the financial message to Issuing Bank due to communication failure? What if Issuing Bank cannot forward the financial message to its CBS due to communication failure? What if Issuing Bank does not receive response from its CBS after sending the financial message due to communication failure? What if Issuing Bank does not respond to NPCI after sending the financial message due to communication failure? What if NPCI does not forward response to Acquiring Bank after receiving the financial message from Issuing Bank, due to communication failure? 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? What if acquiring bank does not receive response from CBS, after sending message to CBS for merchant credit, due to communication failure? What if Acquiring Bank is not able to respond to merchant due to communication failure? What if there is time-out to the reversal advice message? What is the dispute management process for IMPS merchant payments? Page 2

3 15.1 Debit adjustment Credit adjustment (Refund) Chargeback Re-presentment Pre-arbitration Pre-arbitration decline Pre-arbitration Accept Arbitration What are the procedures for handling arbitration in the IMPS network? What is the Penalty for non-compliance of Settlement Guidelines What are the Good-faith guidelines for IMPS transactions? What are the guidelines for handling customer complaints in IMPS network? What are the features required in merchant acquiring platform? How does merchant get integrated with Acquiring Bank? For push transactions For pull transactions What are the various interfaces through which merchant can receive payment via IMPS merchant payments PULL transaction? Web application for integration with merchant web site WAP application for integration with merchant WAP site IVR application Merchant mobile handset application SMS based application for customer SMS based application for merchant Reminder SMS based application Merchant server application USSD based application STK based application WAP based application Internet based application What is the merchant configuration required at the acquiring bank platform? Merchant set-up Merchant configuration Financial configuration What facility is required for transaction status verification for merchant? What MIS facility may be provided by Acquiring Bank to the merchant? What is the reconciliation procedure between Bank and Merchant? What is the refund procedure between Bank and Merchant? What are the security guidelines for acquiring Bank and merchants? What are the guidelines for settlement of payments for electronic payment transactions involving intermediaries? What are the risk management guidelines at Acquiring Bank? What are the risk management guidelines at Issuing Bank? What is the list of response codes in the IMPS system? What are the reconciliation files and reports that IMPS provides to the member banks? Page 3

4 Page 4

5 1. What is IMPS merchant payments service? IMPS Merchant Payments For Banks and Merchants 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. Page 5

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: a. Visit merchant application such as web site, mobile application, or WAP site Page 6

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

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

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 / / 312 DPSS.CO.PD.No / / 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 / / 511 DPSS.CO.No / / 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 For list of services available on IMPS merchant payments, please visit This includes services available through merchant aggregators. Page 9

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 Designation Phone person Axis Bank Shri Vinay AVP Internet Vasudev Banking Canara Bank Shri Vishal Sr Manager Corporation Shri K DGM , kram@corpbank.co.in Bank Ramachandran Dombivli Nagari Shri Milind Varerkar DGM IT Officer IT milindvarerkar@dnsb.co.in pratikgadgil@dnsb.co.in Sahakari Bank Shri Pratik Gadgil Greater Bombay Bank Shri Milind Mahadik Sr Manager Milind.mahadik@greaterbank.com HSBC ICICI Bank Kotak Mahindra Bank Standard Chartered Bank State Bank of India Union Bank of India Yes Bank 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 Sr Vice President Vice President DGM Chief Manager Product Manager Associate Director, Transaction Banking vijaylulla@hsbc.co.in devendraverma@hsbc.co.in salil.chugh@icicibank.com Saurabh.jai@icicibank.com Yogesh.n.verma@kotak.com , , Sachin.tiwari@sc.com Sr Manager gyannarayan@unionbankofindia.com (Marketing) EVP anand.bajaj@yesbank.in 12. What are the merchant on-boarding process guidelines for Acquirer Bank? The merchant on-boarding process is as follows: An Acquiring bank should ensure to carry out due diligence before on boarding any merchant to ensure that Page 10

11 the fraudulent merchant set-ups, fly by night operators are not boarded 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 An Acquiring bank should enter into an agreement with the merchant An Acquiring bank must ensure that the payment to the merchant if enrolled through TPP should follow the RBI guidelines (RBI/ /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 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 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: Content Products Privacy policy Refund policy Cancellation policy Terms & conditions Website data security Data storage SSL payment options over the internet Links to other sites 1.2. Ensure that the merchant does not process any illegal transaction (e.g.: pornography, rape, terrorism, gambling in goods or services, illegal goods or services) 1.6. It is imperative for acquirers to make sure that mobile payments are as secure as possible. NPCI recommends following guidelines for acquirers so as to ensure the safety of mobile payments. Acquirers should: 1. Check if vendor is able to provide assurance that the code within a payment application has not Page 11

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 Identify each Processor and designate the activities that it is authorized to perform on the Acquirer s behalf Guarantee that the Acquirer and its Processors will comply with the NPCI requirements for the use of Agents 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. Page 12

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, 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 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 Ensure that a compromise of one of the Shared Hosting Provider s customers will not pose a risk to the data of other customers Merchants should ask their Shared Hosting Provider about the specific controls that they use to assure proper segmentation between customer environments Extra scrutiny should be placed on shared resources including, but not limited to, the management network, disk storage systems, and virtual environment hypervisors 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? Page 13

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? The transaction flow in this case is as follows: Page 14

15 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

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? The transaction flow in this case is as follows: Page 16

17 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

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 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, 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 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 What if acquiring bank rejects transaction? The transaction flow in this case is as follows: Page 18

19 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

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

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 to 1 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. 2 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 3 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 ). 4 After Debit between Acquiring Bank switch and CBS This transaction is responded by time-out Page 21

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

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

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

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

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