Study of RUPAY Purchase Transaction

Report of Work done at IDRBT during Summer Internship – 2018

By- Itishree Nayak, B.Tech, 4th year, IT IIIT Bhubaneswar, Bhubaneswar

Under the Guidance of Dr. N. V. Narendra Kumar CERTIFICATE

This is to certify that the summer internship project report entitled “Study of RuPay Purchase Transaction” submitted to Institute for Development and Research in Banking Technology (IDRBT), Hyderabad is a bonafide record of work done by Itishree Nayak, B.Tech (IT), IIIT Bhubaneswar, Bhubaneswar from 10-05-2018 to 03-07- 2018 under my supervision.

Project Guide Dr. N. V. Narendra Kumar Asst. Professor IDRBT, Hyderabad CONTENTS

ACKNOWLEDGMENT ABSTRACT 1. INTRODUCTION...…………………………………6 1.1. Objective of RuPay 1.2. Structure of the Report

2. RUPAY.………………………………...……………9 2.1. Advantages of RuPay Card 2.2. Features of RuPay Card

3. NPCI………………………………………………..12 3.1. Role of NPCI

4. ECOSYSTEM OF RUPAY………………………...14 4.1. Participants in the RuPay Transaction 4.2. Roles and Responsibilities of Participants 4.3. Transaction Flow 4.3.1. Iframe Flow 4.3.2. Redirection Flow 4.4. API Specifications

5. SECURITY SCENARIOS………………………….42

6. CONCLUSION……………………………………..47 REFERENCES

ACKNOWLEDGMENT

Behind every achievement lies an unfathomable sea of gratitude to those who activated it, without whom it would ever have come into existence. To them, I lay the words of gratitude imprinted with me. I would like to thank IDRBT for giving an opportunity and the necessary facilities and also the staff of admin and library for their support. I would thank my guide Dr. N. V. Narendra Kumar, for his timely valuable guidance and suggestions for this report. I would like to thank all who have been inspiring guides and committed caretakers and who have given me the moral support in every situation of my internship career. This encouragement and support by them, especially in carrying out this report motivated me to complete this study. My sincere thanks to, IIIT Bhubaneswar and also my friends who encouraged me to pursue this internship.

ABSTRACT

This report studies RuPay, an effort to promote the cause of financial inclusion in the country, launched a few years back. RuPay is Indian’s own domestic payment network developed on the lines of international payment networks like Visa, MasterCard, Discover etc. In a market that has been dominated thus far by international card payment networks, the RuPay card has been gaining much popularity lately. The main advantage of RuPay cards is that they are flexible with product platforms. Affordable lower cost faster transaction, customized product offering, protection of information are some of its benefits. We have studied some of the transactions permitted by RuPay with the objective of analyzing protocol level security aspects and identified potential scenarios. Further technical analysis is needed to ensure that the RuPay network is secure against these scenarios. Such an analysis requires detailed information about the implementation. Keywords: RuPay, NPCI, API, Security.

1. INTRODUCTION

“RuPay”, the word itself has a sense of nationality in it. “RuPay” has been coined from 2 words, which are Rupee and Payment. RuPay is the first-of-its-kind domestic Debit and Credit Card payment network of India, with wide acceptance at ATMs, POS devices and e-commerce websites across India. It is a highly secure network that protects against anti-phishing. It is our answer to international payment networks, expressing pride over our nationality. RuPay fulfills RBI’s vision of initiating a ‘less cash’ economy. This could be achieved only by encouraging every Indian bank and financial institute to become tech-savvy and engage in offering electronic payments.

1.1. Objective of RuPay RuPay, a new card payment scheme launched by the National Payments Corporation of India (NPCI), has been conceived to fulfill RBI’s vision to offer a domestic, open- loop, multilateral system which will allow all Indian banks and financial institutions in India to participate in electronic payments. Few of its objectives are as follows.

 The vision of NPCI being able to provide citizens of our country anytime, anywhere payment services which are simple, easy to use, safe, and secure, fast and also cost- effective.  NPCI aims to operate for the benefit of all the member banks and the common man at large.  The core objective was to consolidate and integrate the multiple systems with varying service levels into nation-wide uniform and standard business process for all retail payment systems. This led to the formation of National Payments Corporation of India, (NPCI).

1.2. Structure of the Report This particular report studies the following concepts 1. In section 2 we study about RuPay, its advantages, benefits, and applications of RuPay. 2. In section 3 we study the role of NPCI and its involvement in the RuPay. 3. In section 4 we study about the different transaction types, transacting parties, transaction flow and the API’s involved in the transaction. 4. Section 5 talks about the potential scenarios in which the system can fail. 5. Section 6 concludes the report.

2. RUPAY

RuPay is an Indian domestic card scheme conceived and launched by the National Payments Corporation of India (NPCI) on 26 March 2012, the umbrella organization that powers retail payments in the country. The provision under the Payment and Settlement Systems Act, 2007, empowered the Reserve Bank of India (RBI) and the Indian Banks’ Association (IBA) to create a secure electronic payment and settlement system in India. RuPay Cards are accepted at 97% of all PoS terminals in India. RuPay has partnered 39 PoS Acquiring Banks in India to accept their cards at PoS terminals located at different merchant locations. The nature of NPCI’s initiatives and objectives includes it under the “Not for Profit Company” under the provisions of Section 25 of the Companies Act 1956 and more recently under the Section 8 of the Companies Act 2013. This was an initiative to build the necessary banking infrastructure required to propel India towards a ‘less cash’ economy. NPCI recognizes the need for tech-driven innovations in the retail payments system to drive operational efficiencies among a larger Indian audience.

2.1. Advantages of RuPay Card The Indian market offers huge potential for cards penetration despite the challenges. RuPay Cards will address the needs of the Indian consumers, merchants, and banks. The benefits of RuPay debit card are the flexibility of the product platform, high levels of acceptance and the strength of the RuPay brand-all of which will contribute to an increased product experience 1. Lower cost and affordability: Since the transaction processing will happen domestically, it would lead to lower cost of clearing and settlement for each transaction. This will make the transaction cost affordable and will drive usage of cards in the industry.

2. Customized product offering: Customized product offering: RuPay, being a domestic scheme is committed towards the development of customized product and service offerings for Indian consumers.

3. Provide electronic product options to untapped/ unexplored consumer segment: There are under- penetrated/untapped consumers segments in rural areas that do not have access to banking and financial services. Right pricing of RuPay products would make the RuPay cards more economically feasible for banks to offer to their customers. In addition, relevant product variants would ensure that banks can target the hitherto untapped consumer segments.

4. Inter-operability between payment channels and products: RuPay card is uniquely positioned to offer complete inter-operability between various payments channels and products. NPCI currently offers varied solutions across platforms including ATMs, mobile technology, cheques etc and is extremely well placed in nurturing RuPay cards across these platforms.

2.2. Features of RuPay Card 1. Complimentary Lounge Access Program – Domestic & International 2. 24X7 Concierge Services 3. Earn Cashback time after time 4. Comprehensive Insurance Cover 5. Exclusive Merchant Offers

3. NPCI

National Payments Corporation of India (NPCI), an umbrella organization for operating retail payments and settlement systems in India, is an initiative of Reserve Bank of India (RBI) and Indian Banks’ Association (IBA) under the provisions of the Payment and Settlement Systems Act, 2007, for creating a robust Payment & Settlement Infrastructure in India. The ten core promoter banks are State Bank of India, Punjab National Bank, Canara Bank, Bank of Baroda, and Union Bank of India, Bank of India, ICICI Bank, HDFC Bank, Citibank N. A., and HSBC. In 2016 the shareholding was broad-based to 56 member banks to include more banks representing all sectors.

3.1. Role of NPCI As a part of the RuPay Switching Service, 1. The ‘NPCI Network’ will collect transactions from a trusted source (an acquirer) and deliver it to a trusted destination (an issuer).

2. The trusted destination will use this information to validate the transaction to the cardholder’s account and further authenticate the transaction back to the trusted source through ‘NPCI Network’.

3. ‘NPCI Network’ further facilitates the process of clearing a valid authenticated transaction and provides the settlement service.

4. A settlement service is a facility within which funds are exchanged between members and NPCI to settle transactions and fee amounts.

5. The RuPay Switching Service will facilitate POS and ATM transactions among all member banks participating in the ‘NPCI network’.

6. It supports both single message system (SMS) and dual Messaging Systems (DMS). Transaction flow for SMS and DMS are described below.

7. The RuPay Switching Service operates on a continuous basis, ensuring that cardholders in India can use their card anytime and that Acquirers and Issuers in India always have access to NPCI RuPay Switch. 4. ECOSYSTEM OF RUPAY

4.1. Participants of RuPay Transaction The RuPay e-Commerce architecture involves the following constituents:

4.1.1. Cardholder: Cardholder means any customer in possession of a payment card (RuPay Debit cards and Credit Cards)

4.1.2. Merchant: The merchant website which has online shopping feature enabled i.e. the website permit customers to purchase goods/products/services online and accepts payments in an electronic manner using debit cards, credit cards, net banking etc.

4.1.3. Acquirer Bank Payment Gateway: A payment gateway facilitates the transfer of information between a payment portal (such as a website, mobile phone or IVR service) and the Front End Processor or acquiring a bank. Payment gateways protect card details by encrypting sensitive information, such as card numbers etc., to ensure that information is passed securely between the customer and the merchant and also between merchant and the payment gateway

4.1.4. Issuer Authentication Server: The IAS (Issuer Authentication Server) will be responsible to confirm the cardholder authenticity. For the e-Commerce solution, the customer is re-directed to Issuer bank’s IAS (Issuer Authentication Server) module maintained and managed completely by Issuing bank for the authentication purpose. The issuing bank will use any authentication method defined as per bank policy. NPCI recommends using dynamic OTP to authenticate the cardholder. The issuer bank would be responsible for properly authenticating the identity of the cardholder and confirming the correct status of authentication back to NPCI.

4.1.5. Issuer Switch: Customer’s information along with a tag to indicate successful authentication/PIN Captured will be shared with the Issuing bank to be routed to the bank’s switch wherein the bank uses this information to authorize/decline the transaction according to pre-defined rules.

4.1.6. NPCI PaySecure System: This forms the core of the whole NPCI e-Commerce solution. This module is responsible for activities such as receiving card information from the payment gateway, providing the mechanism for re-directing customer to issuer page for authentication etc.

4.1.7. NPCI Switch: The switch is maintained and operated by NPCI for all electronic transactions ATM, POS etc. For e-Commerce purposes, the switch would be required for routing information from NPCI to Issuing Banks. 4.2. Roles and Responsibility of Participants 4.2.1. Role of Merchant  Perform integration with the acquirer using acquirer’s API.  Send the purchase and card related information to the acquirer.  Redirect/Transfer browser control to the acquirer to complete the authentication process.  Receive authorization response information from Acquirer.  Present the receipt page to the customer and deliver the goods/service upon confirmation of payment from the acquirer.

4.2.2. Role of Acquirer  Acquirer needs to integrate their system to PaySecure System using NPCI’s API. SOAP (Simple Object Access Protocol) web services will be used for messaging between Acquirer and PaySecure system.  Acquirer to integrate merchant to acquirer’s system using Acquirer’s API.  To perform merchant authentication before sending the data to NPCI.  Guide merchants on the best practices that need to be adopted.  Settlement and reporting with the merchants.

4.2.3. Role of Issuer  Issuer verifies the card/cardholder as per the current authentication and authorization process.  Decrypts & Parse the ISO block received in the ISO 8583 message from NPCI to check the presence of authentication tag and other data elements.  Issuer to authorize or decline the transaction.  Park the funds related to the authorized transactions and service fees/charges, if any, in the settlement account.  Liability of all e-Commerce fraud transactions lies with the issuer.  Issuer authenticates the cardholder.  It is recommended to decline/drop the financial transaction if a customer clicks the back button or reload (F5) during the authentication process.

4.2.4. Role of the Cardholder  To identify and select the goods or service on the merchant website  To fill in the purchase form (customer name, phone number, email id, delivery address etc.)  To select the payment option  Upon prompt, enter the card number, expiry date and cvd2 on the payment page.  Cardholder to Authenticate with Issuer  Enter the credentials (OTP/PIN) which he/she will prompt by Issuer/PaySecure page on authentication page.

4.2.5. Role of NPCI  NPCI will certify acquiring and issuing banks system for exchanging data between the bank and NPCI over web services calls.  NPCI will establish a secure communication link between acquirers and issuers for processing the E-Commerce transaction.  Form ISO 8583 message packet post receiving Authorize API call along-with tag element (indicating successful authentication)  To route authorization request message with Tag elements to the issuer  Guide acquiring banks on merchant certification process, merchant authentication best practices.  Guide acquiring banks on the best practices that the merchant can follow.  To perform Geolocation on the Cardholder’s IP address.  Conducts Clearing & Settlement amongst various stakeholder  Coordinates for disputes for transactions processed using NPCI system.

4.3. Transaction Flow There are different types of transactions possible using RuPay such as financial and non-financial. But for the purpose of this report, we are only considering only financial transactions through RuPay. In the PaySecure system, transactions can be processed in two different approaches which are purely dependent on Issuer Bank’s requirement and Policy.

High-Level Transaction Flow a) Iframe Approach

i. PaySecure accepts “CheckBIN2” API call, to determine if the BIN is enrolled for e-commerce transactions by Issuing bank. ii. PaySecure accepts “Initiate” API Call to submit complete transaction request. iii. Via JavaScript function call, it displays a modal Iframe which is hosted by NPCI PaySecure system. iv. PaySecure gives control to Issuing bank that loads the IAS page, send the OTP if OTP is authentication method and authenticates the customer. The result is shared with NPCI. v. The acquirer is supplied a response from modal dialog as it closes indicating that OTP was authenticated successfully and the transaction is ready for authorization. vi. PaySecure accepts “Authorize” API call for authorization of transaction by Issuing bank.

b) Redirection Approach

i. PaySecure accepts “CheckBIN2” API call, to determine if the BIN is enrolled for eCommerce transactions by Issuing bank. ii. PaySecure accepts “Initiate2” API Call to submit complete transaction request. iii. Complete browser redirection to Issuer/PaySecure using POST method. iv. Complete authentication and return control back to the acquirer, to submit for authorization. v. Acquirer submits an authorization request to PaySecure via a SOAP-based web service call that creates the ISO message, adds the successful authentication tags and sends to the issuer for authorization. The response is routed back to the merchant through the acquirer.

4.3.1. Iframe Flow

Parameters: 1. Cardholder: C 2. Merchant: M 3. Acquirer Payment Gateway: A 4. PaySecure: P 5. NPCI: N 6. Issuer Authentication Server: I 7. Issuer Switch: S Steps for Iframe Flow:

1. C M: Cardholder logs on to the merchant website, select the goods he wants to purchase and add it to the shopping cart. Then the cardholder moves to the checkout process, where the merchant website allows the cardholder to enter his car details or Payment data. Such as Card Type, Card number, Expiry date, Card Verification Data 2 (CVD2). The process id further continued after cardholder clicks on the submit button.

2. M A: Merchant sends the complete payment data to Acquirer.

3. A P: Acquirer sends the first 9 digits of the card number (called BIN) to PaySecure in Check Bin API call, to determine if the card is eligible for e-commerce transaction or not.

4. P A: Upon successful BIN check PaySecure responds to the acquirer. According to which Acquirer should follow Redirection Flow if TRUE or Iframe Flow if FALSE. Based on BIN, PaySecure identifies transaction flow.

5. A P: Acquirer system sends Initiate API call, which contains the payment data, to PaySecure System.

6. P I: PaySecure sends Auth_Initiate API call, the request for authentication server for the verification of card number and mobile number availability.

7. I P: PaySecure receives a response from issuer authentication server.

8. P A: PaySecure responds to Initiate API call with transaction details allowing the Acquirer to continue with the payment process.

9. A P: Acquirer substantiates the PaySecure Iframe overtop of their payment page for Consumer interactions with PaySecure. PaySecure now has direct communications and control of the consumer browser.

10. P C: PaySecure system redirects to issuer OTP Page. The Issuer now has direct communications and control of the consumer browser.

11. C I: Issuer provides the cardholder with authentication option.  Enter OTP  Cardholder enters OTP on issuer OTP page.

12. I C: Transaction Success or Failure message. Issuer validates OTP as entered on OTP page.

13. C P: Issuer passes the control of Iframe and cardholder back to the PaySecure system.

14. P I: PaySecure server query’s IAS via Auth_Result API call.

15. I P: Issuer Authentication Server confirms the result and method of cardholder authentication.

16. P A: Iframe closed, Acquirer is notified by PaySecure through the browser only if OTP authentication status is successful.

17. A P: Acquirer completes any pre- authorization steps and sends Authorize_API request to PaySecure.

18. P N: PaySecure creates ISO message, as per RuPay specifications with mandatory tag elements and will send the authorization message to NPCI Server.

19. N S: Authorization message sent to issuer switch for authorization.

20. S N: Issuer Switch validates ISO message and will accept/decline the transaction. The issuer will send the response back to NPCI.

21. N P: NPCI Switch will send the response to the PaySecure system.

22. P A: PaySecure system sends the response back to the acquirer.

23. A M: Acquirer sends the response to the merchant website.

24. M C: Merchant displays an appropriate message to the cardholder.

4.3.2. Redirection Flow

Parameters: 1. Cardholder: C 2. Merchant: M 3. Acquirer Payment Gateway: A 4. PaySecure: P 5. NPCI: N 6. Issuer Authentication Server: I 7. Issuer Switch: S

Steps for Redirection Flow:

1. C M: Cardholder logs on to the merchant website, select the goods he wants to purchase and add it to the shopping cart. Then the cardholder moves to the checkout process, where the merchant website allows the cardholder to enter his car details or Payment data. Such as Card Type, Card number, Expiry date, Card Verification Data 2 (CVD2). The process id further continued after cardholder clicks on the submit button.

2. M A: Merchant sends the completer payment data to Acquirer.

3. A P: First 9 digits of card-number sent to PaySecure in Checkbin2 API call to determine card eligibility for an e-commerce transaction.

4. P A: Based on BIN the PaySecure identifies the flow. According to which Acquirer should follow Redirection Flow if TRUE or Iframe Flow if False.

5. A P: To transmit the payment data to the PaySecure system, acquirer sends Initiate2_API.

6. P I: To transmit a request for authentication of Issuer Authentication Server, PaySecure sends Auth_Initiate API. [Card_no, Card_exp_date, CVD2, Hash key]

7. I P: Issuer Authentication Server responds with authentication status. [Issuer GUID, Unique value, Cardholder ID]

8. P A: PaySecure responds to Initiate2_API with transaction details along with Issuer OTP Page URL and Cardholder ID allowing Acquirer to continue with the payment procedure.

9. A I: Acquirer redirects to the Issuer OTP Page URL received in Initiate2 API response for cardholder allowing the Acquirer to continue with the payment process.

10. I C: Cardholder is provided with available authentication options. For Example: “Enter OTP”.

11. C I: Enter OTP on issuer OTP page.

12. I A: Issuer validates the OTP as entered by the cardholder on OTP page. The issuer then redirects cardholder browser back to acquirer system along with authentication status of the cardholder.

13. A P: Acquirer completes any pre- authorization steps and sends Authorisation_API request to PaySecure. [transation_ID, PAN, Tran_amount, card_exp_date, CVD2, Currency and order_ID]

14. P I: PaySecure server queries Issuer Authentication Server via Auth_Result API call to securely confirm the result of cardholder authentication.

15. I P: On the successful response of Auth_Result API from IAS, PaySecure will create the ISO message with mandatory tag elements.

16. P N: PaySecure sends the ISO message to NPCI Switch.

17. N S: Authorization message sent to Issuer Switch for authorization.

18. S N: Issuer Switch validates the ISO message and will approve/decline the transaction. The issuer will then send the response back to NPCI switch.

19. N P: Response of sent to PaySecure.

20. P A: Response of Authorisation API sent to Acquirer along with Approval code.

21. A M: Acquirer sends the response back to the merchant website.

22. M C: Merchant displays an appropriate message to the cardholder.

4.4. API Specifications

The API like Checkbin and Initiate are used in Iframe flow whereas the APIs like Checkbin2 and Initiate2 are used in Redirection Flow. Rests of the APIs are common in both the flows. All the APIs mentioned below have multiple input and output field involved, but for our work we have chosen few mandatory fields.

Details about few of the fields mentioned are: 1. Card bin – First 9 digits of a valid card. 2. BIN – Bank Identification Number 3. Qualified_internetpin – Identifies BIN eligibility for RuPay e-commerce transactions 4. Auth_amount – The transaction authorization amount in base units 5. Cvd2 – Card Verification Data 6. Tid – Card acceptor terminal ID 7. Tran_id – A unique ID assigned by PaySecure to successful the transaction and remains constant throughout the lifecycle of the transaction. 8. Guid – A unique ID assigned to the successful transaction and used during the PIN capture processes. 9. Apprcode – Approval code, populated from DE38 as received from the Issuer.

1. Checkbin – API call: used by an acquirer to determine whether Issuer bank enabled e-commerce service based on BIN (first 9 digits of the card number). Mandatory Fields Involved: As Input - i. card_bin

As Output - i. status ii. Error code iii. Qualified_internetpin iv. Error message

2. Checkbin2 – API call: The Checkbin API and Checkbin2 API are similar in terms of core functionality of checking the eligibility of the BIN for e-commerce transactions. The only difference is that Checkbin2 API response contains “Redirect” Tag which confirms the type of flow supported by the respective Issuing bank and is followed by the acquirer to complete that particular transaction. If Redirect tag is “TRUE” the acquirer should follow Redirect flow and if the Redirect tag is “FALSE” then acquirer should follow Iframe flow. Mandatory Fields Involved: As Input- i. card_bin

As Output- i. status ii. Error code iii. Qualified internet_pin iv. Error message

3. Initiate – API call: It is used to securely exchange necessary information related to the card and transaction between Acquirer and PaySecure. All the necessary elements required for ISO message block is received from acquirer bank payment gateway in this API call. Further card number is supplied to PaySecure. PaySecure will return a tran_ID (transaction ID) that is unique to the transaction and will be used throughout the lifecycle of the transaction including authentication, authorization, and refunds. This transaction is also part of ISO message block and send to the issuer in the online message to the issuer i.e. Transaction ID is available to both acquirers and issuers. Additionally, PaySecure will provide a GUID, Modulus, and Exponent that are related to the security of the Iframe and must be passed unaltered to the consumer’s browser during the loading of the Iframe. Mandatory Field Involved: As Input - i. Card_no ii. Card_exp_date iii. Auth_amount iv. CVD2 v. Tid As Output – i. Tran_id ii. GUID iii. Status iv. Error code v. Error message

4. Initiate2 – API call: This API is functionally same as that to Initiate API call. On comparing “Initiate” API call with “Initiate2”, 3 new tags have been added in request i.e. Browser User Agent, IP Address, and HTTP Accept. Additionally, PaySecure will provide a GUID, h-key & Redirect URL in “Initiate2” response back to Acquirer, to which the URL of cardholder needs to be redirected to initiate the authentication process. Mandatory Field Involved: As Input - i. Card_no ii. Card_exp_date iii. Auth_amount iv. CVD2 v. Tid As Output – i. Tran_id ii. GUID

5. Auth_Initiate - API call: used for checking card details provided by the cardholder. Mandatory Fields involved: As Input – i. Card_no ii. Card_exp_date iii. CVD2 As Output – i. Issuer GUID ii. URL ID iii. Unique value iv. Cardholder ID

6. Auth_Result – API call: After the Issuer returns the control of Iframe to PaySecure upon successful OTP validation, PaySecure will securely validate with the IAS server to know the result of the authentication and mode of authentication. Mandatory Fields involved: As Input – i. Issuer GUID ii. Tran_id As Output – i. Result of authentication ii. The method used to authenticate the cardholder.

7. Authorize – API call: It is initiated by the Acquirer Payment Gateway once the PIN is captured by PaySecure or authentication is successfully completed and validated by the IAS and successful response for the same has been to Acquirer Payment Gateway.

The authorize API call is used to initiate the authorization message. Authorize API call triggers the creation of ISO message block by the PaySecure system. Upon receipt of Authorize API call PaySecure collects all the transaction details along with a tag element (including successful authentication validation confirmation by IAS) to create ISO message block and sends it to NPCI switch which in turn forwards to the respective Issuer switch.

The Authorize API call is used to authorize a transaction for which authentication was successfully validated. Only for one authorization is allowed per initialized transaction. 1. Acquirer Payment gateway performs all internal business pre-authorization processes 2. Acquirer Payment gateway calls authorize API call passing in Transaction Id, PAN, Transaction Amount, card Expiry Date, CVD2, currency, and other custom fields such as order Id to the acquiring bank payment gateway. 3. PaySecure combines the authorization information with tag element and requests authorization confirmation from issuing bank via NPCI switch. 4. Issuing bank sends the response to NPCI switch; NPCI switch in turn sends the response back to PaySecure. 5. PaySecure sends a successful response along with approval code to the acquiring bank payment gateway. 6. Merchant displays receipt page to the cardholder. Mandatory Fields involved: As Input – i. Tran_id ii. Auth_amount As Output – i. Status ii. Error code iii. Error message iv. Apprcode

5. SECURITY ANALYSIS SCENARIOS

The properties we are looking for here are: 1. Each entity receiving the data should know, which step is being asked for. 2. Each entity should know that all the previous steps have been successfully performed. 3. No two entities/stakeholders should believe that they are at different stages of the transaction.

If any of the steps have not been allowed, the transaction should not move forward.

Some of the scenarios are as follows. 1. Checkbin request and response skipped  Mischief Needed: possible only if the card is initially eligible for an e-commerce transaction  Detection Possibility: Not Possible

2. Checkbin, Initiate, Auth_Intiate request and response skipped  Mischief Needed: Acquirer somehow has the Issuer_GUID and Trand_ID. Not necessarily of that particular transaction  Detection Possibility: Possible as Auth_Result requires Issuer_GUID, Tran_ID to implement further steps, which are missed at Auth_Initiate.

3. Directly Authorize_API is performed after payment data is acquired by the Acquirer.  Mischief Needed: Tran_ID is available somehow, card initially eligible for e-commerce transactions.  Detection Possibility: Authorize_API require Tran_ID to proceed.

4. Checkbin requested, but replied responded with response of Initiate API  Mischief Needed: False details provided by PaySecure.  Detection Possibility: GUID missing (from the response of Auth_Initiate), Iframe/Redirection flow not identified (response of Checkbin), URL ID missing (from the response of Auth_Initiate)

5. After Checkbin response Initiate and Auth_Initiate steps are skipped.  Mischief Needed: Issuer Authentication Server Faulty  Detection Possibility: Auth_Result requires Issuer_GUID, Tran_ID which are only generated as the response of Auth_Initiate. 6. Checkbin response is directly followed by Authorize API.  Mischief Needed: Tran_ID provided, not necessarily of that transaction and card initially eligible for an e-commerce transaction.  Detection Possibility: Tran_ID missing when Authorize API is performed.

7. Initiate API is responded without Auth_Initiate being called.  Mischief Needed: Somehow card number and mobile number availability verification sent.  Detection Possibility: GUID missing (From Auth_Initiate step), URL ID missing without which Cardholder cannot be provided with URL page to enter OTP.

8. After the Auth_Initiate request, IAS responds with the response of Auth_Result.  Mischief Needed: IAS faulty.  Detection Possibility: GUID missing which should be provided in the response to Auth_Initiate.

9. After the response of Auth_Initiate directly cardholder is asked to enter OTP.  Mischief Needed: PaySecure doesn’t work properly.  Detection Possibility: Tran_ID missing.

10. After the response of Initiate API, directly Authorize API called  Mischief Needed: OTP provided and authenticated successfully.  Detection Possibility: Not Possible. Because Authorize API has Tran_ID to proceed with the transaction.

11. Authorize API directly followed by step 22 without the steps involving NPCI Switch and Issuer Switch  Mischief Needed: IAS ruptured somehow and false OTP provided and accepted.  Detection Possibility: At OTP verification step.

12. After step 16, 23 and 24 are followed without the money being actually credited from the Issuer Bank.  Mischief Involved: Apprcode provided.  Detection Possibility: Missing Apprcode.

13. After Acquirer asks for Authorize API, PaySecure replies with a successful response without actually asking NPCI Switch and Issuer Switch.  Mischief Needed: PaySecure Faulty.  Detection Possibility: Apprcode missing, that is to be provided by Issuer Switch.

14. After Cardholder entering the OTP true or false, it is not verified with IAS, and the success message is forwarded to Acquirer Payment Gateway  Mischief Needed: PaySecure Faulty and provided Acquirer with successful OTP authentication message.  Detection Possibility: Not Possibility.

These are some of the potential scenarios according to our theoretical analysis. But the robustness of the RuPay network can be verified with further research on the operational aspect of RuPay.

6. CONCLUSION

RuPay being a domestic card scheme required Government efforts to promote financial inclusion to make it stand out among its international peers. The payment gateway has surely helped the government achieve its social objective. It profits by costing 23% less processing fees than VISA/Master card. We have studied some of the transactions permitted by RuPay with the objective of analyzing protocol level security aspects and identified potential scenarios. Further technical analysis is needed to ensure that the RuPay network is secure against these scenarios. Such an analysis requires detailed information about the implementation.

REFERENCES

1. RuPay - Online Switching Interface Specification, 2017

2. RuPay Acquirer Integration Guide, 14 May 2018 https://www.npci.org.in/sites/default/files/circular/ RuPay%20Acquirer%20Integration%20Guide%20 v1.5.pdf

3. RuPay PaySecure Issuer Integration Guide, 14 May 2018 https://www.npci.org.in/sites/default/files/circular/ RuPay%20PaySecure%20Issuer%20Integration%2

0Guide%20v1.6.pdf