DESC:FIELD
[0001] Various embodiments of the present disclosure relate generally to payment modes. More particularly, various embodiments of the present disclosure relate to porting of a payment mode.
BACKGROUND
[0002] Payment modes such as transaction cards are utilized to perform financial transactions associated with a payment account of a user. A payment mode is typically issued by an issuer of the payment account. The payment mode is associated with a payment network service provider. When a user requests for the payment mode from the issuer, limited options of payment modes may be provided to the user. Further, the user typically lacks awareness of the various types of payment modes available to the user and thus opts for a particular type of the payment mode associated with a corresponding payment network as suggested by the issuer. Additionally, if the user wishes to discontinue the usage of the payment mode with a current payment network, the payment mode remains with the user thereby increasing the carbon footprint of the payment mode.
[0003] In light of the foregoing, there is a need for a technical solution that solves the above-mentioned problem.
SUMMARY
[0004] Method and system for porting a payment mode associated with a payment network to another payment network is provided substantially as shown in and described in connection with, at least one of the figures, as set forth more completely in the claims.
[0005] In an embodiment of the present disclosure, a method is provided. The method comprises receiving, by a server, from a terminal device, a selection indicative of porting a payment mode associated with a first payment network, wherein a first application associated with a first payment network is installed on the payment mode, and wherein the selection is inputted in the terminal device by a user of the payment mode. The method comprises initiating, by the server, based on the reception of the first selection, mutual authentication between the server and the payment mode, and generating, by the server, upon the mutual authentication being successful, a removal request indicative of removal of the first application associated with the first payment network from the payment mode. The method comprises selecting, by the server, based on the removal of the first application from the payment mode, a second application associated with a second payment network such that the second application associated with the second payment network is installed on the payment mode.
[0006] In some embodiments, the first payment network is different from the second payment network, and the payment mode is at least one of a credit card, a debit card, and a prepaid card.
[0007] In some embodiments, the method comprises replacing, by the server, a first set of instructions associated with the first payment network to a second set of instructions associated with the second payment network in a memory associated with the server upon the installation of the second application on the payment mode.
[0008] In some embodiments, the method comprises identifying, by the server, a plurality of card types associated with a plurality of payment networks for the user, wherein the plurality of payment networks are different from the first payment network and include the second payment network, wherein a card type of the plurality of card types is associated with a corresponding application of a payment network of the plurality of payment networks, and wherein the plurality of card types are determined based on eligibility of the user to avail the porting of the payment mode. The method comprises communicating, by the server, the plurality of card types as options to the user by way of the terminal device, to receive the selection.
[0009] In some embodiments, the method comprises verifying by the server, based on the reception of the selection, the user to avail the porting of the payment mode.
[0010] In some embodiments, the method comprises generating, by the server, first authentication data to initiate the mutual authentication between the server and the payment mode, wherein the first authentication data is associated with authentication of the server. The method comprises transmitting, by the server, the first authentication data to the payment mode by way of the terminal device and receiving, by the server, second authentication data based on processing of the first authentication data by the payment mode from the terminal device, wherein the server is authenticated by the payment mode based on the first authentication data. The second authentication data is generated by the payment mode upon the authentication of the server by the payment mode, and the second authentication data is associated with authentication of the payment mode. The method comprises detecting, by the server, upon the reception of the second authentication data, that the payment mode has successfully authenticated the issuer and authenticating the payment mode based on the second authentication data, wherein the authentication of the payment mode indicates completion of the mutual authentication between the server and the payment mode, and wherein based upon the completion of the mutual authentication, the removal request is generated.
[0011] In some embodiments, the method comprises creating, by the server, personalization script based on the installation of the second application in the payment mode, wherein the personalization script is created based on details of the payment mode, details of the second payment network, and a type of the payment mode.
[0012] In some embodiments, the method comprises transmitting load data associated with the selection of the second application, by the server to the payment mode by way of the terminal device, wherein upon reception of the load data, the second application is loaded into the payment mode.
[0013] In some embodiments, the method comprises generating by the server, an installation request to indicate installation of the second application on the payment mode, based on the selection of the second application. The method comprises, receiving by the server, installation response from the payment mode by way of the terminal device, and detecting by the server, successful installation of the second application on the payment mode based on the installation response.
[0014] In another embodiment of the present disclosure, a server is provided. The server comprises a processor. The processor is configured to receive from a terminal device, a selection indicative of porting a payment mode associated with a first payment network, wherein a first application associated with the first payment network is installed on the payment mode, and wherein the selection is inputted in the terminal device by a user of the payment mode. The processor is further configured to initiate, based on the reception of the first selection, mutual authentication between the server and the payment mode. The processor is further configured to generate, upon the mutual authentication being successful, a removal request indicative of removal of the first application associated with the first payment network from the payment mode, and select, based on the removal of the first application from the payment mode, a second application associated with a second payment network such that the second application associated with the second payment network is installed on the payment mode.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The accompanying drawings illustrate the various embodiments of systems, methods, and other aspects of the disclosure. It will be apparent to a person skilled in the art that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of one element may be implemented as an external component in another, and vice versa.
[0016] Various embodiments of the present disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements:
[0017] FIG. 1 is a block diagram that illustrates a system environment for facilitating porting of payment modes, in accordance with an embodiment of the present disclosure;
[0018] FIGS. 2A-2G collectively represent a process flow diagram that illustrates an exemplary method of facilitating the porting of payment modes of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
[0019] FIGS. 3A and 3B, is a schematic diagram that illustrates UI screens, that are rendered at a terminal device of the system environment of FIG. 1, in accordance with an embodiment of the present disclosure;
[0020] FIGS. 4A-4C, collectively, represent a flow chart that illustrates the method for facilitating porting of the payment modes of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
[0021] FIG. 5 represents a high-level flowchart that illustrates a method (or process) for facilitating porting of the payment modes of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure; and
[0022] FIG. 6 is a block diagram that illustrates a system architecture of a computer system, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
[0023] The present disclosure is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
[0024] References to ““an embodiment”, “another embodiment”, “yet another embodiment”, “one scenario”, “another scenario”, “yet another scenario”, one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s), scenario(s), or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment, scenario, or example necessarily includes that particular feature, structure, characteristic, property, element, or limitation. Furthermore, repeated use of the phrase “in an embodiment” or “in another embodiment” does not necessarily refer to the same embodiment or the same alternative embodiment.
OVERVIEW
[0025] Generally, users use payment modes such as credit cards and debit cards, to perform various transactions such as payments to merchants and cash withdrawals, at terminal devices such as ATMs. Each payment mode of the user is associated with a corresponding payment network. In an example, a user may request an issuer to provide the user with a credit card. The issuer typically selects the payment network for the credit card based on eligibility of the user to avail the credit card. Thus, the user generally does not have an option to select the payment network service provider for the credit card. Additionally, the issuer identifies the type of credit card for the user based on the requirements disclosed by the user. Thus, the user typically lacks awareness of the various credit cards with different benefits that would have been available to the user. Furthermore, until the expiry of the credit card, if the user discontinues the usage of the current credit card and opts for another credit or debit card from a different payment network, the old credit card remains with the user thereby increasing the carbon footprint of such credit cards.
[0026] Various embodiments of the present disclosure provide a method and a system that solves the above-mentioned problem by facilitating porting between payment networks at the terminal device. Initially, the first application associated with the first payment network is installed on the payment mode of the user. To port the payment mode to a new payment network, the server receives a selection from the user by way of a terminal device indicating porting from a first payment network to a second payment network. The server upon receiving the selection, initiates a mutual authentication between the server and the payment mode such that both the server and the payment mode authenticate each other. Once the mutual authentication is successful, the server generates a removal request. The removal request indicates the removal of the old application, i.e., the first application associated with the first payment network from the payment mode. The server further selects a second application (i.e., extracts load data of the second application) associated with the second payment network upon receiving a removal response indicating that the first application has been removed from the payment mode. The server transmits the load data to the payment mode by way of the terminal device. The payment mode on receiving the load data of the second application, installs the second application, and provides an installation response to the server. The server creates the personalization script such that the user details are updated upon the receipt of the installation response from the payment mode by way of the terminal device. The payment mode of the user is thus ported to the second payment network.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
[0027] Payment mode is a medium that facilitates access to a payment account maintained at a financial institution utilized to make financial transaction such as payments from the payment account. Examples of the payment mode may include but are not limited to, a payment card or the like. Examples of the payment card may include but are not limited to, a credit card, a debit card, a prepaid card, or the like.
[0028] Server is a physical or cloud data processing system on which a server program runs. A server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server is implemented as a computer program that is executed on programmable computers, such as personal computers, laptops, or a network of computer systems. The server may correspond to a secure server, an acquirer server, a payment network server, or an issuer server.
[0029] An issuer server ensures payment for approved transactions in accordance with various payment network regulations and local legislation. In addition, the issuer server facilitates the porting of the payment mode from the first payment network to the second payment network.
[0030] Issuer is associated with a financial institution, such as a bank, where accounts of several users are established and maintained. The issuer maintains the issuer server. In one embodiment, the issuer issues the payment mode to the user.
[0031] A first application refers to a specific software application associated with the first payment network. The first application is intended for use in financial transactions and related activities within the first payment network. The first application may include cryptographic data pertaining to the first payment network.
[0032] A second application refers to another distinct software application associated with the second payment network. The second application is designed for use in financial transactions and related activities within the second payment network. The second application may include cryptographic data pertaining to the second payment network.
[0033] Mutual authentication, also known as two-way authentication or two-step authentication or two-factor authentication, is a security process in which both parties in a communication or transaction verify each other's identity. Mutual authentication is commonly used in various secure communication protocols, such as Secure sockets layer/Transport layer security (SSL/TLS) for secure web connections, Virtual Private Networks (VPNs), and secure email systems. It helps prevent man-in-the-middle attacks and enhances overall security by ensuring that both sides of the communication are trusted and verified.
[0034] The first authentication data refers to the data generated by the issuer server during the mutual authentication between the issuer server and the payment mode. The first authentication data is utilized by the payment mode to authenticate the issuer server. The first authentication data includes information or cryptographic parameters necessary to confirm the identity and legitimacy of the issuer.
[0035] The second authentication data refers to the data generated by the payment mode after successfully authenticating the issuer server using the first authentication data. The second authentication data is used for the authentication of the payment mode by the issuer server which includes information or cryptographic parameters that confirm the identity and legitimacy of the payment mode.
[0036] An initialization request refers to a message or packet sent by one party in a communication protocol to initiate the setup or initialization of a connection or session. The initialization request typically includes information or parameters necessary to establish the connection and often includes details such as the desired communication settings, security parameters, or any other relevant data needed to configure the connection.
[0037] An initialization response is a message or packet sent in response to an initialization request. The initialization response acknowledges the receipt of the request and provides the necessary information or parameters to complete the initialization of the connection or session. The response may also include status information, confirmation of successful setup, or any required negotiation details.
[0038] A selection refers to the initial choice or action made by the user, through a user interface on the terminal device, in response to a set of options presented to them. In context of the disclosure, when the user interacts with the UI displayed on the display screen of the terminal device, the user is presented with a set of options, and the option selected by the user is termed as the selection.
[0039] Payment network acts as an intermediate entity between the acquirer and the issuer to process the transactions. In an embodiment, payment card associations are the payment networks. Examples of various payment card associations include MasterCard®, American Express®, VISA®, Discover®, Diners Club®, and the like.
[0040] A payment network server is operated by a payment network. The payment network server settles transactions between various acquirer banks and issuer banks.
[0041] A card type is associated with a corresponding application of a payment network of the plurality of payment networks. A card type may refer to various brands or types of the payment mode such as a credit card, debit card, a prepaid card, or the like.
[0042] Verification request is a message sent to the user, which may include an OTP, to confirm the identity of the user and ensure the secure transfer of a payment mode between payment networks.
[0043] First content refers to specific information related to how a user conducts financial transactions, particularly in the context of a payment network. The information is typically stored in the user data within the memory associated with the issuer server.
[0044] Load data refers to code information, authentication data, and configurations that are necessary to install, set up, and ensure the normal functioning of a specific application.
[0045] Porting of payment networks refers to the process of transferring or migrating a current payment mode of a user from one payment network to another payment network. The method can include moving payment methods, such as credit or debit cards, and associated payment details from one payment network to a different one.
[0046] A removal request is a communication or message initiated by the issuer server, indicating the intention to remove the first application associated with the first payment network from the payment mode. The removal request serves as a command to remove or delete the specified application from the payment mode.
[0047] An installation request is a communication or message generated by the issuer server, indicating the intention to install the second application on the payment mode. The installation request prompts the payment mode to install the specified application, which may involve storing the load data, and preparing the application for use. The request may contain the necessary parameters, data, and instructions for the installation process.
[0048] Installation response is a confirmation message generated by the payment mode indicating that the second application has been successfully installed and activated on the payment mode and the data associated with the second application is stored in a memory of the payment mode.
[0049] A personalization script refers to a set of instructions or data created by the issuer server to customize and configure the second application on the payment mode. The purpose of this script is to personalize the application, tailoring it to the specific requirements and parameters of the payment mode and network to which it has been ported.
[0050] FIG. 1 is a block diagram that illustrates a system environment 100 for porting of payment modes, in accordance with an embodiment of the present disclosure. The system environment 100 includes a user 102, a user device 104, a payment mode 106, a terminal device 108, an issuer server 110, a first payment network server 114, and a second payment network server 116. In the presently preferred embodiment, the payment mode 106 is ported from a first payment network associated with the first payment network server 114 to a second payment network associated with the second payment network server 116. The user device 104, the payment mode 106, the terminal device 108, the issuer server 110, the first payment network server 114, and the second payment network server 116 may communicate with each other by way of a communication network 118.
[0051] The user 102 is an account holder of at least one financial account. In one embodiment, the financial account is maintained by a financial institution, such as a bank (i.e., an issuer of the financial account; hereinafter, “issuer”). Examples of the financial account include, but are not limited to, a checking account (i.e., account for withdrawals or deposits), a savings account (i.e., a deposit account), or an e-wallet account.
[0052] The user device 104 may refer to a computing device of the user 102. The user 102 may own the user device 104. Examples of the user device 104 may include a mobile phone, a laptop, a smartphone, a tablet, a computer, a phablet, a wearable device such as a smart watch, or the like. The user device 104 may include suitable logic, circuitry, interfaces, and/or code to enable the user 102 to perform various operations such as establishing communication with various devices by way of audio/video calls, sending/receiving short message services (SMSs), instant messages (IMs), and voice-over-IP (VoIP) messages, performing payments, or the like. In an exemplary embodiment, the user 102 may use the user device 104 to read a one-time password (OTP) sent on a registered mobile number of the user device 104 or a registered email of the user 102.
[0053] The payment mode 106 may be associated with the financial account of the user 102. In one embodiment, the payment mode 106 is a medium that facilitates the user 102 to access the financial account maintained at the financial institution. The payment mode 106 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry to facilitate payments and switch between payment networks. The payment mode 106 may include a first memory 119, a first interface 124, and a first processor 126. The first memory 119, the first interface 124 and the first processor 126 may communicate with each other via a first communication bus 128. The first communication bus 128 may be configured to allow data such as electrical signals and electromagnetic signals to be transferred between the first memory 119, the first interface 124, and the first processor 126. Examples of the first communication bus 128 may include, but are not limited to a data bus, an address bus, and a control bus.
[0054] In one embodiment, the payment mode 106 is issued to the user 102 by the financial institution such as a bank. The payment mode 106 is associated with an identifier that serves as an identification of the payment mode 106. The identifier may be a numeric value, an alphanumeric value, or an alphabetic value. The payment mode 106 may be used by the user 102 to make payments for availing services such as purchase of a product, transferring funds, and the like. In an embodiment, the payment mode 106 is a payment card. Further, the payment card may be either a physical payment card or a virtual payment card. In the presently preferred embodiment, it is assumed that the payment mode 106 is a physical card. Examples of the payment mode 106 include, but are not limited to, a credit card, a debit card, a prepaid card, a gift card, a rewards card, a loyalty points card, a frequent flyer miles card, or the like. In another embodiment, the payment mode 106 is issued to the user 102 by another financial institution such as a credit card service provider.
[0055] The first memory 119 includes suitable logic, circuitry, and/or interfaces to store a set of instructions associated with a payment network. The payment network may be associated with one of the first payment network server 114 or the second payment network server 116. The first memory 119 is configured to store payment application data 120 associated with the first payment network when the payment mode 106 is associated with the first payment network. The payment application data 120 may include details associated with the first payment network. The details associated with the first payment network may include a first set of instructions and cryptographic data associated with the first payment network, as well as an identifier of the first payment network. The first memory 119 may be further configured to store first content 122. The first content 122 may include at least one of an identifier of the payment mode 106, a bank identification number associated with the payment mode 106, an expiry date of the payment mode 106, a card verification value of the payment mode 106, a name of the user 102 associated with the payment mode 106, a personal identification number (PIN), a password, or the like. When the payment mode 106 is ported from the first payment network to the second payment network (e.g., the payment mode 106 is associated with the second payment network), the first memory 119 erases the details associated with the first payment network and stores details associated with the second payment network. The payment application data 120 thus corresponds to the details associated with the second payment network upon porting. The porting of the payment mode 106 from the first payment network to the second payment network is explained in the foregoing description. The details associated with the second payment network may include a second set of instructions and cryptographic data associated with the second payment network, as well as an identifier of the second payment network. Examples of the first memory 119 may include a random-access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), a flash memory, or the like.
[0056] The first interface 124 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to transmit and receive data over the communication network 118 using one or more communication protocols. The first interface 124 transmits and receives communication requests and responses from the terminal device 108 and the issuer server 110 to enable communication between the payment mode 106 and the terminal device 108 and the issuer server 110. Examples of the first interface 124 may include but are not limited to, an antenna, a radio frequency network interface, a wireless network interface, a Bluetooth network interface, an ethernet port, a Universal Serial Bus (USB) port, and the like.
[0057] The first processor 126 may include suitable logic circuitry, interfaces, and/or code executable by the circuitry that may be configured to perform one or more operations. The operations may include processing various requests received from the issuer server 110 by way of the terminal device 108 and generate and provide responses based on the processing of the requests to the issuer server 110 by way of the terminal device 108. Based on the received requests, the first processor 126 may be configured to at least one of select a card manager of the payment mode 106, execute authentication of the issuer server 110, generate authentication data of the payment mode 106 and transmit to the issuer server 110, remove a first application of the first payment network from the payment mode, load and install the second application of the second payment network to port the payment mode 106 from the first payment network to the second payment network, store the details associated with the second payment network 116 in the first memory 119 upon the porting, and the like. The various requests and responses are shown and explained in detail in the foregoing description as well as in FIGS. 2A-2G. The first processor 126 is further configured to communicate with the terminal device 108 by way of the first interface 124 responses based on the processing of the received requests. Examples of the first processor 126 may include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a field programmable gate array (FPGA), a central processing unit (CPU), or a microprocessor.
[0058] The issuer server 110 is a server arrangement that includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for executing various operations. The issuer server 110 is operated by the issuer of the payment mode 106. The issuer is a financial institution that manages one or more payment accounts of various users such as the user 102. Details of the payment accounts established with the issuer are stored as account profiles (not shown) in the second memory 130 associated with the issuer server 110. The account profile of the user 102 may be indicative of a payment transaction history of the user 102, first content 122, a contact information of the user 102, or the like. The first content 122 refers to specific information related to how a user conducts financial transactions, particularly in the context of a payment network. The information is typically stored in user data 138 within the memory (the second memory 130) associated with the issuer server 110. The contact information of the user 102 may include a contact number and/or an email address of the user 102. The issuer server 110 includes the second memory 130, a second processor 136, and a second interface 139. The second memory 130, the second processor 136, and the second interface 139 may communicate with each other via a second communication bus 140. The second communication bus 140 may be configured to allow data such as electrical signals and electromagnetic signals to be transferred between the second memory 130, the second interface 139, and the second processor 136. Examples of the second communication bus 140 may include, but are not limited to a data bus, an address bus, and a control bus.
[0059] The second processor 136 may include suitable logic circuitry, interfaces, and/or code executable by the circuitry that may be configured to perform one or more operations for porting the payment mode 106. The second processor 136 is configured to receive from the terminal device 108, a first selection indicative of porting the payment mode 106 associated with the first payment network (i.e., the porting of the payment mode 106 from the first payment network to the second payment network). In one embodiment, the first payment network and the second payment network are different from each other. The second processor 136 receives the first selection when the user 102 inserts the payment mode 106 into the terminal device 108 and selects an option of porting rendered on a user interface (UI) of a display screen of the terminal device 108. The various UIs rendered on the terminal device 108 are shown later in FIGS. 3A-3B. In one embodiment, the second processor 136 is further configured to authenticate the user 102 based on a PIN of the payment mode 106. The option of porting may be displayed upon the authentication of the payment mode 106. Examples of the second processor 136 may include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a field programmable gate array (FPGA), a central processing unit (CPU), or a microprocessor.
[0060] The second processor 136 is further configured to verify the user 102 to avail the porting of the payment mode 106 from the first payment network to the second payment network by way of a verification request, based on the reception of the first selection. The verification request is a message transmitted to the user device 104, which may include a one-time password (OTP), to confirm the identity of the user 102 and ensure the secure transfer of the payment mode 106 between payment networks. The verification request may include details associated with the OTP. The terminal device 108 may further render an option indicating the user 102 to enter the OTP. The option to enter the OTP may be rendered based on the reception of the first selection on the terminal device 108. The user 102 may thus enter the OTP on the terminal device 108. The OTP may be transmitted to the second processor 136 by way of the terminal device 108 by way of a verification response. The second processor 136 may verify the user 102 based on the entered OTP in the verification response.
[0061] Upon receipt of the verification response, the second processor 136 may be further configured to match the received OTP with the OTP transmitted on the user device 104. The second processor 136 is further configured to initiate a mutual authentication between the issuer server 110 and the payment mode 106 based on a successful match between the received OTP and the transmitted OTP. It will be understood by a person skilled in the art that the generation of OTP serves as a two-step authentication process to verify the user 102. In another embodiment, the user 102 may avail the option of porting based on the PIN without entering the OTP on the terminal device 108. The second processor 136 is further configured to transmit a verification notification to the user device 104 and the terminal device 108 indicating a successful verification of the user 102 to avail the porting.
[0062] For the sake of simplicity of explaining and without deviating from the scope of the disclosure, it is assumed that the payment mode 106 is associated with VISA® before porting, i.e., the first payment network and the first payment network server 114 are associated with VISA®. Further, the second payment network and the second payment network server 116 are associated with MasterCard®, and the porting of the payment mode 106 occurs from the first payment network to the second payment network.
[0063] In one embodiment, the second processor 136 is configured to identify a plurality of card types associated with a plurality of payment networks for the user 102 based on the reception of the first selection. In another embodiment, based on the reception of the first selection, the second processor 136 may provide options pertaining to the plurality of payment networks on the terminal device 108 such that the user 102 selects one of the payment networks from the plurality of payment networks that is different from the first payment network. The options pertaining to the plurality of payment networks are independent of the card types. The card type is associated with a corresponding application of a payment network of the plurality of payment networks. A card type may refer to various brands or types of the payment mode 106 such as a credit card, debit card, a prepaid card, or the like. In an example, the terminal device 108 may display the options as Diners Club®, MasterCard®, and American Express®. Thus, the issuer server 110 receives a selection from the user 102 that is indicative of the payment network. In the above example, the issuer server 110 may receive the selection as MasterCard®. The issuer server 110 may further identify the card types based on the selection of the payment network and provide the card types to the user 102 by way of the terminal device 108. In the above example, the issuer server 110 may identify the card types such as a credit card, a debit card, or a prepaid card with the payment network as MasterCard® based on the eligibility of the user 102.
[0064] For the sake of simplicity of the ongoing description and without deviating from the scope of the disclosure, it is assumed that the second processor 136 identifies the plurality of card types associated with the plurality of payment networks for the user 102 based on the reception of the selection indicative of porting the payment mode 106, based on the reception of the first selection. In an example, a first card type is a credit card associated with Diners Club®, a second card type is a debit card associated with Diners Club®, a third card type is a credit card associated with MasterCard®, and a fourth card type is a gift card associated with American Express®. Further, a card type of the plurality of card types is associated with a corresponding application of a payment network of the plurality of payment networks. In the above example, the corresponding application associated with the first card type is an application of Diners Club®, the corresponding application associated with the second card type may be the same or another application of Diners Club®, the corresponding application associated with the third card type is an application of MasterCard®, and the corresponding application associated with the fourth card type is an application of American Express®. It will be understood by a person skilled in the art that the issuer server 110 may identify additional card types or a lower number of card types apart from the card types stated above based on the eligibility of the user 102 to avail the card types for porting the payment mode 106.
[0065] In one scenario, the second processor 136 may identify the plurality of card types in real-time based on selection of the porting option received from the user 102 by way of the terminal device 108. In another scenario, the second processor 136 may identify the plurality of card types periodically. In an example, the second processor 136 may identify the plurality of card types on a monthly basis and communicate the identified plurality of card types to the user device 104. The user 102 may thus consider the option to port based on the reception of the identified plurality of card types on the user device 104. The user 102 may further visit a location of the terminal device 108 to port the payment mode 106. In yet another scenario, the second processor 136 may be configured to receive a porting request from the user 102 by way of an application associated with the issuer and installed on the user device 104 and determine the eligibility of the user 102 based on the porting request within a time interval say minutes, hours, or days. On determining the eligibility, the second processor 136 may transmit a communication response to the user device 104 indicating whether the user 102 is eligible to avail the porting of the payment mode 106. The communication response is transmitted at an end of the time interval thereby reducing a wait time of the user 102 at the terminal device 108 and saving time of the user 102 at the terminal device 108 if the user 102 is deemed ineligible.
[0066] The plurality of payment networks associated with the identified plurality of card types are different from the first payment network and include the second payment network. Further, the plurality of card types are determined based on an eligibility of the user to avail the porting of the payment mode 106 to at least one of the determined card types. In addition, the eligibility of the user 102 to avail a specific card type may be determined based on a type of the financial account of the user 102 maintained at the issuer, transaction history associated with the financial account, a credit score of the user 102, and the like. In an example, if the transaction history of the user 102 indicates that the number of transactions are below a certain threshold, the user 102 may be deemed eligible for a credit card, a debit card, or a prepaid card but may not be deemed eligible for a frequent flyers card.
[0067] The second processor 136 is further configured to communicate the plurality of card types as options to the user 102 by way of the terminal device 108, to receive a selection. Thus, each of the plurality of card types are displayed to the user 102 on the terminal device 108. In an example, the terminal device 108 displays the plurality of card types along with their specific features (Feature-1 through Feature-5). The features of the plurality of card types may include Feature-1 as low annual fee, Feature-2 as global acceptance, Feature-3 as travel rewards, Feature-4 as airport lounge rewards, and Feature-5 as discounts at partner merchants. The comprehensive suite of features aims to meet the varied needs of the users, such as the user 102. The needs may be related to cost-efficiency, global usability, travel perks, airport comfort, or savings opportunities with the merchant partners. In the above example, the user 102 may select the field of MasterCard® credit card to port the payment mode 106. The user 102 may select MasterCard® credit card based on the features offered by MasterCard® credit card over other card types. The second processor 136 receives the selection based on the porting option selected by the user 102.
[0068] In another embodiment, the user 102 identifies a specific card type of a payment network and provides the porting request by way of the user device 104, to the issuer server 110 to determine eligibility of the user 102 to port the payment mode 106 to the specific card type. In an example, the user 102 may be travelling abroad and may wish to opt for a frequent flyer card associated with one of the payment networks. The issuer server 110 determines the eligibility of the user 102 based on the received request and communicates a response indicating success or failure of eligibility of the user 102 or unavailability of the application associated with the payment network to the user 102. If the response indicates success, the user 102 may thus avail the porting of the payment mode 106 to the specific card type by way of the terminal device 108.
[0069] In the present embodiment, it is assumed that the issuer server 110 identifies the plurality of card types for the user 102.
[0070] The second processor 136 is configured to generate and transmit a selection request indicative of selecting a card manager of the payment mode 106 by way of the terminal device 108. In response, the second processor 136 is configured to receive a selection response indicating that a card manager of the payment mode 106 has been selected by the payment mode 106. The selection response is transmitted to the second processor 136 from the payment mode 106 by way of the terminal device 108. Upon the reception of the selection response, the mutual authentication is initiated.
[0071] The mutual authentication, often referred to as two-way authentication, is a security process in which two parties, such as a client (the payment mode 106) and a server (such as the issuer server 110), authenticate each other's identities. The mutual authentication is commonly used in secure communication protocols and systems to ensure that both sides of a transaction or interaction trust each other. The mutual authentication is initiated by generating an initialization request by the second processor 136 to establish a secure channel for data exchange between the issuer server 110 and the payment mode 106 by way of the terminal device 108. The initialization request refers to a message or packet sent by one party in a communication protocol to initiate the setup or initialization of a connection or session. The initialization request typically includes information or parameters necessary to establish the connection and often includes details such as the desired communication settings, security parameters, or any other relevant data needed to configure the connection. The second processor 136 may generate and transmit the initialization request to the payment mode 106 by way of the terminal device 108. In response to the initialization request, the second processor 136 may receive an initialization response from the payment mode 106 by way of the terminal device 108. The initialization response is a message or packet sent in response to an initialization request. The initialization response acknowledges the receipt of the initialization request and provides the necessary information or parameters to complete the initialization of the connection or session. The initialization response may also include status information, confirmation of successful setup, or any required negotiation details. The initialization response may indicate that the secure channel has been established. Further, the initialization response may include cryptographic data associated with the payment mode 106 that may be utilized for the mutual authentication.
[0072] The second processor 136 may generate first authentication data that includes first cryptographic details (i.e., information or cryptographic parameters necessary to confirm the identity and legitimacy of the issuer) pertaining to the authentication of the issuer server 110 and the terminal device 108 based on the reception of the initialization response. The second processor 136 is further configured to transmit the first authentication data to the payment mode 106 by way of the terminal device 108. The first authentication data refers to the data generated by the issuer server 110 during the mutual authentication between the issuer server 110 and the payment mode 106. The first authentication data is utilized by the payment mode 106 to authenticate the issuer server 110.
[0073] The second processor 136 is further configured to receive second authentication data based on processing of the first authentication data by the payment mode 106 from the terminal device 108. The second authentication data includes second cryptographic details (i.e., information or cryptographic parameters that confirm the identity and legitimacy of the payment mode 106) pertaining to the authentication of the payment mode 106. The second authentication data refers to the data generated by the payment mode 106 after successfully authenticating the issuer server 110 using the first authentication data. The second authentication data is used for the authentication of the payment mode 106 by the issuer server 110. On receiving the second authentication data, the second processor 136 is further configured to detect that the payment mode 106 has successfully authenticated the issuer server 110 (i.e., the issuer). The second processor 136 is further configured to authenticate the payment mode 106 based on the second authentication data. The authentication of the payment mode 106 indicates completion of the mutual authentication between the issuer server 110 and the payment mode 106. The issuer server 110 forbids the user 102 from availing the porting based on at least one of indication of failure of authentication in the initialization response and failure of reception of the second authentication data.
[0074] The second processor 136 is further configured to generate, upon successful mutual authentication between the issuer server 110 and the payment mode 106, a removal request indicative of removal of the first application associated with the first payment network from the payment mode 106. The second processor 136 transmits the removal request to the payment mode 106 by way of the terminal device 108. The issuer server 110 generates and transmits a removal notification to the user device 104 indicating deletion of the first application from the payment mode 106. Additionally, the terminal device 108 receives the removal notification and displays the removal notification. In an example, the payment mode 106 is installed with the first application of VISA®, thus after successful mutual authentication, the removal request indicates removal of the first application of VISA®. On reception of the removal request, the payment mode 106 removes/erases the payment application data 120 associated with the first application from the first memory 119 and generates a removal response. The removal response is transmitted to the issuer server 110 by way of the terminal device 108.
[0075] The second processor 136 is further configured to select, based on the removal of the first application from the payment mode 106, i.e., on reception of the removal response, a second application associated with the second payment network (e.g., extracts the load data 134 of the second application from the second memory 130) such that the second application associated with the second payment network is installed on the payment mode 106. In an example, the second application associated with the second payment network is an application of Mastercard®. The load data 134 refers to code information, authentication data, and configurations that are necessary to install, set up, and ensure the normal functioning of a specific application
[0076] The load data 134 includes parameters and cryptographic data associated with the second application. The load data 134 may further include information or configuration settings required to install and setup the second application. The load data 134 ensures that the second application functions as intended and may include parameters indicative of default settings or initial configuration. In an example, the load data 134 may include parameters related to application dependencies, application permissions, or the like. The second processor 136 is further configured to transmit the load data 134 of the second application to the payment mode 106 by way of the terminal device 108.
[0077] The payment mode 106 receives the load data 134. Upon reception of the load data 134, the second application is loaded into the payment mode 106. The payment mode 106 generates a load response based on the loading of the second application that is transmitted to the issuer server 110 by way of the terminal device 108. The second processor 136 is further configured to determine based on reception of the load response from the payment mode 106 by way of the terminal device 108, that the second application is successfully loaded into the payment mode 106.
[0078] Upon loading the second application, the second processor 136 is further configured generate an installation request to indicate installation of the second application on the payment mode 106. Based on the installation request, the payment mode 106 installs the second application thereby storing the load data 134 associated with the second application as the payment application data 120 in the first memory 119. The payment mode 106 may further generate and transmit an installation response to the second processor 136 by way of the terminal device 108. The second processor 136 may be configured to detect, successful installation of the second application into the payment mode 106 based on the installation response. The installation response is a confirmation message generated by the payment mode 106 indicating that the second application has been successfully installed and activated on the payment mode 106 and the data associated with the second application is stored in a memory of the payment mode 106.
[0079] The second processor 136 is further configured to update, the user data 138 associated with the first payment network to the second payment network in the second memory 130 upon the installation of the second application associated with the second payment network on the payment mode 106.
[0080] The second processor 136 is further configured to create a personalization script based on successful installation of the second application in the payment mode 106. The personalization script is created based on the first content 122, details of the second payment network, and a type of the payment mode 106 such as the selected card type for the payment mode 106. In other words, the personalization script refers to the process of customizing the services offered by the issuer to cater to the specific needs and requirements associated with the second application and the payment mode 106. The personalization script may involve thus creating unique encryption data associated with the payment mode 106 and the second payment network that may be used for transactions, adding security features associated with the second application, and the like. The personalization script would further include linking of the second application to a type of financial account. In a scenario, upon installation of the second application associated with Mastercard®, the personalization includes linking of the second application associated with the Mastercard® with the type of the financial account such as a credit account. Additionally, tailor-made benefits or rewards may be created or added during the personalization script and stored in the user data 138.
[0081] The second processor 136 is further configured to generate and transmit a personalization request indicative of the personalization script to the payment mode 106 by way of the terminal device 108. On configuring the payment mode 106 with the personalization script, a personalization response is received by the second processor 136 from the payment mode 106 by way of the terminal device 108 indicative of the personalization of the second application on the payment mode 106. Based on the reception of the personalization response, the second processor 136 may generate and transmit a porting notification to the terminal device 108 and the user device 104 indicating successful porting of the payment mode 106 to the second payment network. The user 102 may further activate the payment mode 106 associated with the second payment network by setting a PIN of the payment mode 106 upon the porting.
[0082] The second memory 130 includes suitable logic, circuitry, and/or interfaces to store a set of instructions complying with at least one of the first payment network server 114 or the second payment network server 116, and porting of the payment mode 106 from the first payment network to the second payment network. The second memory 130 is configured to store application data (not shown) associated with the first payment network and the second payment network. The application data associated with the first payment network may include the first set of instructions and the cryptographic data associated with the first payment network, as well as the identifier of the first payment network. Further, the application data associated with the second payment network may include the second set of instructions and the cryptographic data associated with the second payment network, as well as the identifier of the second payment network. The second memory 130 may be further configured to store the user data 138. The user data 138 may be associated with the first content 122, the first set of instructions associated with the first application, or the like. The first set of instructions refer to specific information related to how users such as the user 102 conduct financial transactions, particularly in the context of a payment network. The information is typically stored in the user data 138 within the second memory 130. When the payment mode 106 is ported from the first payment network to the second payment network (e.g., the payment mode 106 is associated with the second payment network), the second memory 130 replaces the first set of instructions associated with the first application with the second set of instructions associated with the second application. In other words, the issuer server 110 is configured to replace the first set of instructions with the second set of instructions in the user data 138 of the second memory 130 upon porting of the payment mode 106 from the first payment network to the second payment network. The second processor 136 may replace the first set of instructions with the second set of instructions by removing (i.e., deleting or erasing) the first set of instructions in the second memory 130 upon the reception of the removal response and storing the second set of instructions in the second memory 130 upon the personalization of the payment mode 106. The user data 138 thus corresponds to the second set of instructions associated with the second application upon porting. Examples of the first memory 119 may include a random-access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), a flash memory, or the like.
[0083] The terminal device 108 is an electronic machine that aids customers, such as the user 102, in performing various operations. The operations may include, but are not limited to performing transactions (such as a cash withdrawal, a cash deposit, transfer of funds, a payment of utility bills, insurance, or income tax, and the like) by using a financial account of the user 102 or availing porting of the payment mode 106. In one example, the user 102 may insert the payment mode 106 that is associated with the financial account of the user 102 in the terminal device 108 to perform the porting of the payment mode 106.
[0084] The terminal device 108 is maintained by a financial institution such as a bank. The terminal device 108 renders a user interface (UI) screen and presents an option on the UI for availing porting facility on transactions initiated at the terminal device 108. The UI screen is rendered based on the eligibility of the user 102, for availing the porting facility when the user 102 selects the porting option on the terminal device 108. The terminal device 108 further presents, on the UI screen, one or more porting options that the user 102 can avail when the user 102 chooses to avail the porting facility. Examples of the terminal device 108 may include but are not limited to ATM, financial kiosk, card dispensing machines maintained by issuer banks, and the like. The various UIs rendered on the terminal device 108 are shown in FIGS. 3A-3B.
[0085] Each of the first payment network server 114 and the second payment network server 116 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry that may be configured to perform one or more operations for processing financial transactions initiated at the terminal device 108 or a point-of-sale device (not shown). The first payment network server 114 and the second payment network server 116 is operated by a payment card network, such as the first payment network and the second payment network, respectively. Examples of various payment card networks include MasterCard®, American Express®, VISA®, Discover®, Diners Club®, and the like. The first payment network server 114 and the second payment network server 116 represent an intermediate entity between the issuer server 110 and an acquirer server (not shown) for processing the financial transactions. In an example, the first payment network server 114 receives first financial transaction initiation details (an encrypted version of the first content 122 and a first purchase amount) from the acquirer server for a first transaction initiated by the user 102 by way of the payment mode 106 before porting (e.g., when the payment mode 106 is associated with the first payment network). The first payment network server 114 may identify the issuer associated with the first financial transaction initiation details and provide the first financial transaction initiation details to the issuer server 110. Upon the porting of the payment mode 106 from the first payment network to the second payment network, the second payment network server 116 receives second financial transaction initiation details (an encrypted version of the first content 122 and a second purchase amount) from the acquirer server for a second transaction initiated by the user 102 by way of the payment mode 106 (e.g., when the payment mode 106 is associated with the second payment network). The second payment network server 116 may identify the issuer associated with the second financial transaction initiation details and provide the second financial transaction initiation details to the issuer server 110. The issuer server 110 may be configured to store the application data (that may include the load data 134) associated with each of the first payment network and the second payment network.
[0086] The communication network 118 may be a medium through which content and messages are transmitted between the user device 104, the issuer server 110, the first payment network server 114, and the second payment network server 116, and other entities that are pursuant to one or more standards for the interchange of financial transaction requests, such as the ISO8583 standard. Examples of the communication network 118 may include, but are not limited to, a wireless fidelity (Wi-Fi) network, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, and combinations thereof. Various entities in the system environment 100 may connect to the communication network 118 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof.
[0087] Examples of the issuer server 110, the first payment network server 114, and the second payment network server 116 may include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that may execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
[0088] Although it is described that system environment 100 includes one user such as the user 102, the scope of the disclosure is not limited to it. In other embodiments, various users may avail the option of porting, without deviating from the scope of the present disclosure.
[0089] Although it is described that one payment mode such as the payment mode 106 is associated with the user 102, the scope of the present disclosure is not limited to it. In other embodiments, multiple payment modes may be associated with the user 102 and the user 102 may avail porting on any of the multiple payment modes, without deviating from the scope of the present disclosure.
[0090] It will be understood by a person skilled in the art that the various responses and requests are generated based on Application Protocol Data Unit (APDU) commands.
[0091] In operation, the user 102 travels to a location of the terminal device 108 to port the payment mode 106 from the first payment network to the second payment network. The user 102 thus inserts the payment mode 106 in the terminal device 108. The terminal device 108 renders a User Interface (UI) (shown in FIG. 3A) on a display screen of the terminal device 108 indicating the user 102 to enter the PIN of the payment mode 106. The received PIN is communicated to the issuer server 110 by the terminal device 108. The issuer server 110 may authenticate the payment mode 106 based on a match between the received PIN and a stored PIN associated with the payment mode 106 in the user data 138 of the second memory 130. The issuer server 110 may communicate an authentication response to the terminal device 108. On receiving the authentication response, the terminal device 108 may render another UI to display a first set of options (shown in FIG. 3A) on the display screen of the terminal device 108. The first set of options may include various fields pertaining to ‘Checking Savings account balance’, ‘Cash withdrawal’, and ‘Porting’. The user 102 may select the field of ‘Porting’ to port the payment mode 106 from the first payment network to the second payment network. The terminal device 108 thus receives a first selection indicating ‘Porting’ of the payment mode 106 and transmits the first selection to the issuer server 110. The issuer server 110 receives the first selection and generates an OTP to verify the user 102 to avail the porting.
[0092] The OTP is transmitted by the issuer server 110 to the user device 104 by way of a verification request. Further, the terminal device 108 renders another UI (shown in FIG. 3A) indicating the user 102 to enter the OTP on receiving the first selection. The user 102 enters the OTP received on the user device 104 on the UI. The terminal device 108 thus communicates the entered OTP to the issuer server 110 by way of a verification response. The issuer server 110 verifies the user 102 based on a match between the OTP transmitted on the user device 104 and the OTP received by way of the terminal device 108. The issuer server 110 transmits the verification notification to the user device 104 and the terminal device 108 indicating the successful verification of the user 102 to avail the porting. Additionally, the issuer server 110 identifies the plurality of card types based on the eligibility of the user 102 to avail the porting of the payment mode 106 to any of the plurality of card types. The plurality of card types are communicated to the terminal device 108 by the issuer server 110. The terminal device 108 renders a UI (shown in FIG. 3B) to display the plurality of card types along with the specific features of each of the card types as a second set of options to the user 102.
[0093] The issuer server 110 generates the selection request to indicate the selection of the card manager by the payment mode 106. The selection request is transmitted to the payment mode 106 by way of the terminal device 108. The payment mode 106 selects the card manager based on the reception of the initialization request and generates the selection response indicating the selection. The selection response is transmitted by the payment mode 106 to the issuer server 110 by way of the terminal device 108.
[0094] The issuer server 110 initiates the mutual authentication between the issuer server 110 and the payment mode 106 to establish a secure communication channel based on the reception of the selection response by generating the initialization request indicating data for establishing a secure channel. The issuer server 110 transmits the initialization request to the payment mode 106 by way of the terminal device 108. The payment mode 106 receives the initialization request and generates the initialization response indicative of the cryptographic data to be utilized for the mutual authentication. The payment mode 106 provides the initialization response to the issuer server 110 by way of the terminal device 108. Upon reception of the initialization response, the issuer server 110 generates the first authentication data associated with the authentication of the issuer by the payment mode 106. The first authentication data is transmitted to the payment mode 106 by way of the terminal device 108. Upon reception of the first authentication data, the payment mode 106 authenticates the issuer and generates the second authentication data associated with the authentication of the payment mode 106 by the issuer server 110. The issuer server 110 receives the second authentication data from the terminal device 108. On receiving the second authentication data, the issuer server 110 detects that the payment mode 106 has successfully authenticated the issuer. The issuer server 110 authenticates the payment mode 106 based on the second authentication data. The authentication of the payment mode 106 indicates completion of the mutual authentication between the issuer server 110 and the payment mode 106.
[0095] The issuer server 110 generates, upon the successful mutual authentication between the issuer server 110 and the payment mode 106, the removal request indicative of removal of the first application associated with the first payment network from the payment mode 106. The issuer server 110 transmits the removal request to the payment mode 106 by way of the terminal device 108. On reception of the removal request, the payment mode 106 erases the payment application data 120 associated with the first application from the first memory 119 and generates and transmits the removal response to the issuer server 110 by way of the terminal device 108. On receiving the removal response, the issuer server 110 identifies that the first application has been removed from the payment mode 106.
[0096] The issuer server 110 generates and transmits a removal notification to the user device 104 indicating deletion of the first application from the payment mode 106. Additionally, the terminal device 108 receives the removal notification and displays the removal notification (shown in FIG. 3B). The issuer server 110 further selects the second application (e.g., extracts the load data 134 of the second application) from the second memory 130 associated with the issuer server 110 and transmit the load data 134 of the second application to the payment mode 106 by way of the terminal device 108. The load data 134 refers to the information and configurations necessary to install, set up, and ensure the proper functioning of a specific application.
[0097] The payment mode 106 receives the load data 134. Upon the reception of the load data 134, the second application is loaded into the payment mode 106. The payment mode 106 generates the load response based on the loading of the second application that is transmitted to the issuer server 110 by way of the terminal device 108. The issuer server 110 determines based on reception of the load response from the payment mode 106 by way of the terminal device 108, that the second application is successfully loaded into the payment mode 106.
[0098] The issuer server 110 further generates the installation request to indicate installation of the second application on the payment mode 106. Based on the installation request, the payment mode 106 installs the second application thereby storing the load data 134 associated with the second application as the payment application data 120 in the first memory 119. The payment mode 106 may further generate and transmit the installation response to the issuer server 110 by way of the terminal device 108. The issuer server 110 may detect, successful installation of the second application on the payment mode 106 based on the installation response. The second processor 136 may replace the first set of instructions with the second set of instructions by removing (i.e., deleting or erasing) the first set of instructions in the second memory 130 upon reception of the removal response and storing the second set of instructions in the second memory 130 upon the personalization of the payment mode 106.
[0099] The issuer server 110 creates the personalization script indicative of the personalization of the first content 122, the second application, and the card type on the payment mode 106 based on the successful installation of the second application in the payment mode 106. The personalization request indicative of the personalization script is transmitted to the payment mode 106 by way of the terminal device 108. The personalization response is received by the issuer server 110 from the payment mode 106 by way of the terminal device 108 indicative of the personalization of the second application and the selected card type on the payment mode 106. Based on the reception of the personalization response, the issuer server 110 may generate and transmit the porting notification to the terminal device 108 and the user device 104 indicating successful porting of the payment mode 106 to the second payment network. The user 102 may further activate the payment mode 106 associated with the second payment network by setting a PIN of the payment mode 106 upon the porting.
[00100] FIGS. 2A-2G collectively represent a process flow diagram 200 that illustrates an exemplary method of facilitating the porting of payment modes of the system environment 100 of FIG. 1, in accordance with an exemplary embodiment of the present disclosure.
[00101] Referring to FIG. 2A, the user 102 inserts the payment mode 106 issued by the financial institution into the terminal device 108 for availing the porting from the first payment network to the second payment network (as shown by arrow 201). The terminal device 108 displays the first set of options on the display screen of the terminal device 108 (as shown by arrow 202). The first set of options may include various ATM services such as porting of payment network, cash withdrawal, balance inquiry, and the like. The user 102 inputs the first selection indicating porting of the payment network on the payment mode 106 (as shown by arrow 203). The issuer server 110 is notified by the terminal device 108 with the first selection made by the user 102 (as shown by arrow 204). The issuer server 110 upon getting notified with the first selection of the user 102, generates the OTP to verify the user 102 (as shown by arrow 205). The issuer server 110 transmits the generated OTP to the user device 104 to verify the user 102 by way of a verification request (as shown by arrow 206).
[00102] The terminal device 108 displays the option to enter the OTP to the user 102 (as shown by arrow 207). The user 102 enters the received OTP into the terminal device 108 (as shown by arrow 208). The terminal device 108 communicates the entered OTP to the issuer server 110 for verification by way of the verification response (as shown by arrow 209). The issuer server 110 verifies the received OTP (as shown by arrow 210) by comparing the received OTP from the terminal device 108 with the transmitted OTP to the user device 104. Based on a successful match between the received OTP and the transmitted OTP, the issuer server 110 notifies the terminal device 108 by way of the verification notification indicating successful verification of the user 102 (as shown by arrow 211). The issuer server 110 further notifies the user 102 by transmitting the verification notification to the user device 104 (as shown by arrow 212). The issuer server 110 identifies the plurality of card types for the user 102 (as shown by arrow 213). For the sake of simplicity of explaining FIGS. 2A-2G, it is assumed that the plurality of card types are identified in real-time based upon the transmission of the verification notification and the eligibility of the user 102 to avail the porting of the payment mode 106 to at least one of the plurality of card types. Further, the issuer server 110 communicates the plurality of card types to the terminal device 108 (as shown by arrow 214).
[00103] Now, referring to FIG. 2B, the terminal device 108 displays the plurality of card types on the display screen by way of the second set of options (as shown by arrow 215). In an example, the first card type is displayed as the first option and the second card type is displayed as the second option. The terminal device 108 receives the second selection when the user 102 selects one of the card types displayed on the display screen of the terminal device 108 (as shown by arrow 216). The terminal device 108 further provides the second selection to the issuer server 110 (as shown by arrow 217).
[00104] Upon receiving the second selection indicating the card type for porting the payment mode 106, the issuer server 110 generates the selection request and transmits the selection request to the terminal device 108 (as shown by arrows 218 and 219). The terminal device 108 further provides the selection request to the payment mode 106 (as shown by arrow 220). The payment mode 106, upon receipt of the selection request, selects the card manager and generates the selection response (as shown by arrow 221). The payment mode 106 further provides the selection response to the terminal device 108 (as shown by arrow 222). Further, the terminal device 108 transmits the selection response to the issuer server 110 (as shown by arrow 223). The issuer server 110, upon receipt of the selection response from the terminal device 108, generates the initialization request indicating data for establishing a secure channel with the payment mode 106 (as shown by arrow 224). The initialization request is transmitted to the terminal device 108 (as shown by arrow 225). Further, the initialization request is provided to the payment mode 106 (as shown by arrow 226). The payment mode 106 generates the initialization response (as shown by arrow 227).
[00105] Referring to FIG. 2C, the payment mode 106 provides the initialization response to the terminal device 108 (as shown by arrow 228), and the terminal device 108 transmits the initialization response to the issuer server 110 (as shown by arrow 229). The issuer server 110 upon receipt of the initialization response, generates the first authentication data (as shown by arrow 231) and transmits the first authentication data to the terminal device 108 (as shown by arrow 232). The terminal device 108 provides the first authentication data to the payment mode 106 (as shown by arrow 233). The payment mode 106 authenticates the issuer server 110 on receipt of the first authentication data generated by the issuer server 110 (as shown by arrow 234). The payment mode 106 generates the second authentication data and provides the second authentication data to the terminal device 108 (as shown by arrows 235 and 236). The terminal device 108 transmits the second authentication data to the issuer server 110 (as shown by arrow 237). Further, the issuer server 110 receives the second authentication data and detects that the payment mode 106 has successfully authenticated the issuer (as shown by arrows 238 and 239). The issuer server 110 authenticates the payment mode 106 based on the second authentication data (as shown by arrow 240).
[00106] Referring now to FIG. 2D, the issuer server 110 generates the removal request upon the successful mutual authentication between the issuer server 110 and the payment mode 106 (as shown by arrow 242). The issuer server 110 transmits the removal request indicating removal of the first application from the payment mode 106, to the terminal device 108 (as shown by arrow 243). The terminal device 108 provides the removal request to the payment mode 106 (as shown by arrow 244). The payment mode 106 further generates the removal response upon the successful removal of the first application, and provides the removal response to the terminal device 108 (as shown by arrows 245 and 246). The terminal device 108 transmits the removal response to the issuer server 110 (as shown by arrow 247). The issuer server 110 generates the removal notification (as shown by arrow 249) and transmits the removal notification to the terminal device 108 (as shown by arrow 250a) such that the terminal device 108 may display the removal notification and further to the user device 104 indicating successful deletion of the first application from the payment mode 106 to the user 102 (as shown by arrow 250b).
[00107] Referring now to FIG. 2E, the issuer server 110 selects the second application associated with the second payment network (e.g., extracts the load data 134 of the second application) from the second memory 130 associated with the issuer server 110 to load the second application into the payment mode 106 (as shown by arrow 252). The issuer server 110 further transmits the load data 134 to the terminal device 108 (as shown by arrow 253). The terminal device 108 further provides the load data 134 to the payment mode 106 (as shown by arrow 254). The payment mode 106 generates the load response on receipt of the load data 134 indicative of the loading of the second application into the payment mode 106 (as shown by arrow 255). The payment mode 106 provides the load response to the terminal device 108 (as shown by arrow 256). The terminal device 108 transmits the load response to the issuer server 110 (as shown by arrow 257). The issuer server 110 upon receipt of the load response from the payment mode 106 determines that the second application associated with the second payment network is successfully loaded into the payment mode 106 (as shown by arrow 258).
[00108] Referring now to FIG. 2F, the issuer server 110 upon the determination of the successful loading of the second application into the payment mode 106, generates the installation request (as shown by arrow 259). The issuer server 110 transmits the installation request to the terminal device 108 (as shown by arrow 260). The terminal device 108 provides the installation request to the payment mode 106 (as shown by arrow 261). The payment mode 106 on receipt of the installation request, generates the installation response upon installing the second application, and provides the installation response to the terminal device 108 (as shown by arrows 262 and 263). The terminal device 108 further transmits the installation response to the issuer server 110 (as shown by arrow 264). The issuer server 110 upon receipt of the installation response from the payment mode 106 by way of the terminal device 108, detects that the second application has been successfully installed on the payment mode 106 (as shown by arrow 265).
[00109] Referring to FIG. 2G, upon detecting that the second application associated with the second payment network server 116 has been successfully installed, the issuer server 110 replaces the first set of instructions with the second set of instructions (as shown by arrow 266). In other words, when the payment mode 106 is ported from the first payment network to the second payment network, the second memory 130 replaces the first set of instructions associated with the first application with the second set of instructions associated with the second application. The user data 138 thus corresponds to the second set of instructions associated with the second application upon porting. The issuer server 110 generates the personalization request based on the creation of the personalization script indicating personalizing the payment mode 106 with details of the second application, the first content 122, and the selected card type and transmits the personalization request to the terminal device 108 (as shown by arrows 268 and 270). The terminal device 108 further provides the personalization request to the payment mode 106 (as shown by arrow 272). The payment mode 106 on receipt of the personalization request, generates the personalization response indicative of the personalization of the payment mode 106 with the second application and the card type, and provides the personalization response to the terminal device 108 (as shown by arrows 274 and 276). The terminal device 108 transmits the personalization response to the issuer server 110 (as shown by arrow 278). The issuer server 110 further processes the personalization response and generates the porting notification (as shown by arrows 280 and 282). The issuer server 110 transmits the porting notification to the terminal device 108 where the notification may be displayed on the display screen of the terminal device 108 (as shown by arrow 284a). The issuer server 110 further transmits the porting notification to the user device 104 (as shown by arrow 284b).
[00110] FIGS. 3A and 3B, is a schematic diagram 300 that, illustrates UI screens 302-312, that are rendered at the terminal device 108, in accordance with an embodiment of the present disclosure.
[00111] In a scenario, the user 102, who is a customer of Bank A, approaches the terminal device 108 such as an ATM maintained by Bank A, to initiate the porting of the payment mode 106 such as a transaction card. Upon inserting the transaction card into the terminal device 108, the terminal device 108 renders the UI screen 302, prompting the user 102 to enter the PIN of the payment mode 106 by way of a first field 313 on the UI screen 302. The UI screen 302 further includes a first submit button 314. The user 102 thus enters the PIN ‘****’ in the first field 313 and clicks on the first submit button 314. The first content 122 is thus transmitted from the terminal device 108 to the issuer server 110. The issuer server 110 authenticates the user 102 based on stored authentication information (such as comparing the received PIN with the stored PIN in the user data 138 of the second memory 130). The issuer server 110 transmits the authentication response that includes a result of the authentication to the terminal device 108. If the authentication is a failure, the terminal device 108 may display a message, indicating an authentication failure (not shown). If the authentication is successful, the terminal device 108 renders the UI screen 304.
[00112] The UI screen 304 displays the first set of options that includes first through fourth selectable options 316-322. The first through fourth selectable options 316-322 represent ‘Porting, ‘Withdrawal’, ‘PIN Change’, and ‘Balance Inquiry’, respectively. For the sake of simplicity and without deviating from the scope of the disclosure, it is assumed that the user 102 selects the first selectable option 316 (i.e., ‘Porting’). In various other embodiments, the user 102 may select any of the second, third, or fourth selectable option i.e., 318, 320 or 322.
[00113] The terminal device 108 renders the UI screen 306 when the user 102 selects the first selectable option 316 indicative of porting (i.e., the first selection). The UI screen 306 prompts the user 102 to enter the OTP in a first field 324a received on the user device 104. The UI screen 306 includes a second field 324b for the user 102 to enter the OTP. The user 102 thus enters the OTP ‘****’ in the second field 324b. The UI screen 306 further includes a second submit button 324c. The user 102 selects the second submit button 324c after entering the OTP in the second field 324b. When the user 102 selects the second submit button 324c, the terminal device 108 transmits the OTP entered by the user 102 to the issuer server 110.
[00114] The issuer server 110 determines the eligibility of the user 102 to avail the porting. The eligibility of the user 102 may be determined based on a type of the financial account of the user 102 maintained at the issuer, transaction history associated with the financial account, a credit score of the user 102, and the like. The issuer server 110 identifies the plurality of card types based on the eligibility of the user 102 and communicates the plurality of card types to the terminal device 108 along with the applicable features, thereby requesting the terminal device 108 to display the UI screen 308 screen. On the UI screen 308, the user 102 is presented with a choice to select one of the plurality of card types. The UI screen 308 includes fifth through eighth selectable options 326-332 for the user 102 which includes a first card type, a second card type, a third card type, and a fourth card type, respectively, along with their specific features. In an example, the first card type is a credit card associated with Diners Club®, the second card type is a debit card associated with Diners Club®, the third card type is a credit card associated with MasterCard®, and the fourth card type is a gift card associated with American Express®. The features of the plurality of card types may include Feature-1 as low annual fee, Feature-2 as global acceptance, Feature-3 as travel rewards, Feature-4 as airport lounge rewards, and Feature-5 as discounts at partner merchants. Thus, the first card type may offer the Feature-2 and Feature-3. The second card type may offer the Feature-1 and Feature-2. The third card type may offer the Feature-1 Feature-2, Feature-3, Feature-4, and Feature-5. The fourth card type may offer the Feature-1 Feature-2, and Feature-3. Thus, the user 102 may select that card type that offers the features that caters to the needs of the user 102. The comprehensive suite of features aims to meet the varied needs of the users that include cost-efficiency, global usability, travel perks, airport comfort, or savings opportunities with the merchants. In one embodiment, the user 102 selects the third card type to port the payment mode 106 by clicking on the seventh selectable option 330 as the second selection. The second selection is thus transmitted to the issuer server 110 and the first application is removed from the payment mode 106.
[00115] Upon removal of the first application from the payment mode 106, the terminal device 108 renders the UI screen 310. The UI screen 310 displays a field 334 indicating removal of the first application. If the first application is associated with VISA®, the user 102 is thus aware that the first application associated with VISA® is removed. Further, on personalization of the second application on the payment mode 106, the terminal device 108 renders the UI screen 312. The UI screen 313 displays a field 336 indicating installation of the second application on the payment mode 106. The user 102 is thus aware that the payment mode 106 is ported to MasterCard® and an application associated with MasterCard® is installed on the payment mode 106.
[00116] FIGS. 4A-4C, collectively, represent a flow chart 400 that illustrates the method for facilitating porting of the payment modes of the system environment 100 of FIG. 1, in accordance with an exemplary embodiment of the present disclosure.
[00117] Referring to FIG. 4A, the process may start at step 402. At step 402, the issuer server 110 receives the first content 122 when the user 102 inserts the payment mode 106 in the terminal device 108. To receive the first content 122, the terminal device 108 renders a UI on a display screen of the terminal device 108 indicating the user 102 to enter the PIN of the payment mode 106. The received PIN is communicated to the issuer server 110 by the terminal device 108 and the PIN is authenticated by the issuer server 110. The terminal device 108 displays the first set of options on the display screen of the terminal device 108. The first set of options may include various fields pertaining to ‘Checking Savings account balance’, i.e., ‘Balance Inquiry’, ‘Cash withdrawal’, i.e., ‘Withdrawal’, ‘PIN change’, and ‘Porting’. The user 102 may select the field of ‘Porting’ to port the payment mode 106 from the first payment network to the second payment network. The terminal device 108 thus receives the option of porting as the first selection and communicates the first selection to the issuer server 110. At step 404, the issuer server 110 receives the first selection indicating the option to port the payment mode 106.
[00118] At step 406, the issuer server 110 upon receiving the first selection, generates an OTP to verify the user 102 to avail the porting of the payment mode 106. At step 408, the OTP is transmitted by the issuer server 110 to the user device 104. The user 102 enters the received OTP on the terminal device 108. The terminal device 108 thus communicates the entered OTP to the issuer server 110. At step 410, the issuer server 110 verifies the user 102 based on a match between the OTP transmitted on the user device 104 and the OTP received by way of the terminal device 108. In an event of a mismatch between the transmitted OTP to the user device 104 and the received OTP from the terminal device 108, the issuer server 110 communicates with the terminal device 108 to display a denial notification indicative of denial of porting the payment mode 106, on the terminal device 108
[00119] At step 412a, the issuer server 110 identifies the plurality of card types based on the eligibility of the user 102. At step 412b, the issuer server 110 communicates the plurality of card types to the terminal device 108. The terminal device 108 displays the plurality of card types as the second set of options to the user 102. The user 102 may select a card type such as a credit card of Mastercard® as a second selection. The terminal device 108 thus receives the second selection. The second selection is provided to the issuer server 110 by the terminal device 108. At step 414, the issuer server 110 generates the selection request indicative of selecting the card manager of the payment mode 106, based on the reception of the second selection. At step 416, the issuer server 110 receives the selection response indicative of selection of the card manager by the payment mode 106, by way of the terminal device 108.
[00120] Referring to FIG. 4B, at step 418a, the issuer server 110 generates the initialization request and transmits to the payment mode 106 by way of the terminal device 108. At step 418b, the issuer server 110 receives the initialization response may indicate that the secure channel has been established for porting, by way of the terminal device 108.
[00121] At step 420, the issuer server 110 generates the first authentication data. The first authentication data is transmitted to the payment mode 106 by way of the terminal device 108. Upon reception of the first authentication data, the payment mode 106 authenticates the issuer (e.g., the issuer server 110) and generates the second authentication data associated with the authentication of the payment mode 106 by the issuer server 110.
[00122] At step 422, the issuer server 110 receives the second authentication data from the terminal device 108. On receiving the second authentication data, the issuer server 110 detects that the payment mode 106 has successfully authenticated the issuer. The issuer server 110 authenticates the payment mode 106 based on the second authentication data. The authentication of the payment mode 106 indicates the completion of the mutual authentication between the issuer server 110 and the payment mode 106.
[00123] At step 424a, the issuer server 110 generates, upon the successful mutual authentication between the issuer server 110 and the payment mode 106, the removal request indicative of removal of the first application associated with the first payment network from the payment mode 106. The issuer server 110 transmits the removal request to the payment mode 106 by way of the terminal device 108. On reception of the removal request, the payment mode 106 erases the payment application data 120 associated with the first application from the first memory 119. At step 424b, the issuer server 110 receives, based on the removal of the first application associated with the first payment network from the payment mode 106, the removal response from the payment mode 106 by way of the terminal device 108.
[00124] At step 426, the issuer server 110 generates the removal notification, upon receipt of the removal response from the payment mode 106. At step 428, the issuer server 110 transmits the removal notification to the terminal device 108 to display the removal of the first application and the user device 104. At step 430a, the issuer server 110 selects the second application (e.g., extracts the load data 134 of the second application) from the second memory 130 associated with the issuer server 110.
[00125] Now referring to FIG. 4C, at step 430b, the issuer server 110 transmits the load data 134 of the second application to the payment mode 106 by way of the terminal device 108. At step 431, the issuer server 110 receives the load response indicative of the successful loading of the second application in the payment mode 106, from the terminal device 108. At step 432, the issuer server 110 determines based on the reception of the load response from the payment mode 106 by way of the terminal device 108, that the second application is successfully loaded into the payment mode 106.
[00126] At step 434, the issuer server 110 generates the installation request to indicate installation of the second application on the payment mode 106. Based on the installation request, the payment mode 106 installs the second application thereby storing the load data 134 associated with the second application as the payment application data 120 in the first memory 119. The payment mode 106 may further generate and transmit the installation response to the issuer server 110 by way of the terminal device 108. At step 436, the issuer server 110 detects, successful installation of the second application on the payment mode 106 based on the installation response. At step 438, the issuer server 110 further replaces the first set of instructions with the second set of instructions in the user data 138 of the second memory 130. The replacing of the first set of instructions with the second set of instructions indicates erasing the first set of instructions based on the reception of the removal response and storing the second set of instructions based on the reception of the installation response.
[00127] At step 440, the issuer server 110 creates the personalization script based on the first content 122, details of the second payment network, and a type of the payment mode 106, such as the selected card type, based on the successful installation of the second application in the payment mode 106. At step 442, the issuer server 110 transmits the personalization request indicative of the personalization script to the payment mode 106 by way of the terminal device 108. At step 444, the personalization response is received by the issuer server 110 from the payment mode 106 by way of the terminal device 108 indicative of the personalization of the second application and the card type on the payment mode 106.
[00128] At step 446, the issuer server 110 may generate and transmit the porting notification to the terminal device 108 and the user device 104 indication successful porting of the payment mode 106 to the second payment network, based on the reception of the personalization response.
[00129] FIG. 5 represents a high-level flowchart 500 that illustrates a method (or process) for facilitating porting of the payment modes in accordance with an exemplary embodiment of the present disclosure.
[00130] At step 502, the issuer server 110 receives the first selection indicative of porting the payment mode 106 associated with the first payment network. The first application associated with the first payment network is installed on the payment mode 106. Further, the first selection is inputted in the terminal device 108 by the user 102 of the payment mode 106. At step 504, the issuer server 110 initiates the mutual authentication between the issuer server 110 and the payment mode 106 based on the reception of the first selection.
[00131] At step 506, the issuer server 110 generates upon the successful mutual authentication between the issuer server 110 and the payment mode 106, the removal request indicative of removal of the first application associated with the first payment network from the payment mode 106. At step 508, the issuer server 110 selects based on the removal of the first application from the payment mode 106, the second application associated with the second payment network such that the second application is installed on the payment mode 106.
[00132] FIG. 6 is a block diagram that illustrates system architecture of a computer system 600, in accordance with an embodiment of the present disclosure. An embodiment of the present disclosure, or portions thereof, may be implemented as computer-readable code on the computer system 600. In one example, the payment mode 106, the terminal device 108, the issuer server 110, the first payment network server 114, and the second payment network 116 of FIG. 1 may be implemented in the computer system 600 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of 4A-4C and 5.
[00133] The computer system 600 includes a third processor 602 that may be a special purpose or a general-purpose processing device. The third processor 602 may be a single processor, multiple processors, or combinations thereof. The third processor 602 may have one or more processor “cores.” Further, the third processor 602 may be connected to a communication infrastructure 604, such as a bus, a bridge, a message queue, the communication network 118, multi-core message-passing scheme, and the like. The computer system 600 further includes a main memory 606 and a secondary memory 608. Examples of the main memory 606 may include RAM, ROM, and the like. The secondary memory 608 may include a hard disk drive or a removable storage drive (not shown), such as a floppy disk drive, a magnetic tape drive, a compact disc, an optical disk drive, a flash memory, and the like. Further, the removable storage drive may read from and/or write to a removable storage device in a manner known in the art.
[00134] The computer system 600 further includes an I/O interface 610 and a communication interface 612. The I/O interface 610 includes various input and output devices that are configured to communicate with the third processor 602. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 612 may be configured to allow data to be transferred between the computer system 600 and various devices that are communicatively coupled to the computer system 600. Examples of the communication interface 612 may include a modem, a network interface, i.e., an Ethernet card, a communications port, and the like. Data transferred via the communication interface 612 may be signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art. The signals may travel via a communications channel, such as the communication network 118 which may be configured to transmit the signals to the various devices that are communicatively coupled to the computer system 600. Examples of the communication channel may include, but are not limited to, a cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, a wireless link, and the like.
[00135] Computer program medium and computer usable medium may refer to memories, such as the main memory 606 and the secondary memory 608, which may be a semiconductor memory such as dynamic RAMs. These computer program mediums may provide data that enables the computer system 600 to implement the method illustrated in FIGS. 4A-4C and FIG. 5. In an embodiment, the present disclosure is implemented using a computer implemented application. The computer implemented application may be stored in a computer program product and loaded into the computer system 600 using the removable storage drive or the hard disc drive in the secondary memory 608, the I/O interface 610, or the communication interface 612.
[00136] A person having ordinary skill in the art will appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device. For instance, at least one processor, such as the third processor 602, and a memory, such as the main memory 606 and the secondary memory 608, implement the described embodiments. Further, the operations may be described as a sequential process, however some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multiprocessor machines. In addition, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
[00137] Embodiments in the present disclosure provide the system environment 100 and method for porting a payment mode 106 such as a transaction card, between payment networks. The porting is carried out at the terminal device 108 such as ATMs. The ATMs renders various User Interfaces (UIs) to the user 102 that provide an option for porting the payment mode 106 of the user 102. Further, the UIs render various options pertaining to the card types and associated payment networks that are different form the current payment network of the payment mode 106. Thus, the issuer server 110 provides by way of the terminal device 108, various available options to the user 102 with information associated with various card types of different networks, thereby allowing the user 102 to make more informed choices. This increased awareness empowers the user 102 to select a card type that aligns with the needs and preferences of the user 102. Additionally, when the user 102 wishes to discontinue the usage of the payment mode 106 with the current payment network, the user 102 may opt for a new payment network on the payment mode 106 thereby reducing the carbon footprint of payment modes that remain with the user 102 when the user 102 discontinues the usage of such payment modes. the requirement for the user 102 to avail cards for another payment network is eliminated as the payment mode 106 is reissued for another payment network. The two-step authentication (PIN and OTP) offered by the issuer server 110 to verify the payment mode 106 and the identity of the user 102 provides enhanced security during porting of the payment mode 106.
[00138] Techniques consistent with the present disclosure provide, among other features, systems, and methods for porting a payment mode 106 between payment networks.
[00139] In the claims, the words ‘comprising’, ‘including’, and ‘having’ does not exclude the presence of other elements or steps than those listed in a claim. The terms “a” or “an,” as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures may not be used to advantage.
[00140] While various embodiments of the present disclosure have been illustrated and described, it will be clear that the present disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present disclosure, as described in the claims.
,CLAIMS:We claim:
1. A method, comprising:
receiving, by a server (110), from a terminal device (108), a selection indicative of porting a payment mode (106) associated with a first payment network, wherein a first application associated with the first payment network is installed on the payment mode (106), and wherein the selection is inputted in the terminal device (108) by a user (102) of the payment mode (106);
initiating, by the server (110), based on the reception of the selection, mutual authentication between the server (110) and the payment mode (106);
generating, by the server (110), upon the mutual authentication being successful, a removal request indicative of a removal of the first application associated with the first payment network from the payment mode (106); and
selecting, by the server (110), based on the removal of the first application from the payment mode (106), a second application associated with a second payment network such that the second application associated with the second payment network is installed on the payment mode (106).
2. The method as claimed in claim 1, wherein the first payment network is different from the second payment network, and the payment mode (106) is at least one of a credit card, a debit card, and a prepaid card.
3. The method as claimed in claim 1, comprising replacing, by the server (110), a first set of instructions associated with the first payment network to a second set of instructions associated with the second payment network in a memory (130) associated with the server (110) upon the installation of the second application on the payment mode (106).
4. The method as claimed in claim 1, comprising:
identifying, by the server (110), a plurality of card types associated with a plurality of payment networks for the user (102), wherein the plurality of payment networks are different from the first payment network and include the second payment network, wherein a card type of the plurality of card types is associated with a corresponding application of a payment network of the plurality of payment networks, and wherein the plurality of card types are determined based on eligibility of the user (102) to avail the porting of the payment mode (106); and
communicating, by the server (110), the plurality of card types as options to the user (102) by way of the terminal device (108), to receive the selection.
5. The method as claimed in claim 1, comprising verifying by the server (110), based on the reception of the selection, the user (102) to avail the porting on the payment mode (106).
6. The method as claimed in claim 1, comprising:
generating, by the server (110), first authentication data to initiate the mutual authentication between the server (110) and the payment mode (106), wherein the first authentication data is associated with authentication of the server (110);
transmitting, by the server (110), the first authentication data to the payment mode (106) by way of the terminal device (108);
receiving, by the server (110), second authentication data based on processing of the first authentication data by the payment mode (106) from the terminal device (108), wherein the server (110) is authenticated by the payment mode based on the first authentication data, wherein the second authentication data is generated by the payment mode (106) upon the authentication of the server (110) by the payment mode (106), and wherein the second authentication data is associated with authentication of the payment mode (106);
detecting, by the server (110), upon the reception of the second authentication data, that the payment mode (106) has successfully authenticated the server (110); and
authenticating the payment mode (106) based on the second authentication data, wherein the authentication of the payment mode (106) indicates completion of the mutual authentication between the server (110) and the payment mode (106), and wherein based upon the completion of the mutual authentication, the removal request is generated.
7. The method as claimed in claim 1, comprising creating, by the server (110), personalization script based on successful installation of the second application in the payment mode (106), wherein the personalization script is created based on details of the payment mode (106), details of the second payment network, and a type of the payment mode (106).
8. The method as claimed in claim 1, comprising transmitting load data (134) associated with the selection of the second application, by the server (110) to the payment mode (106) by way of the terminal device (108), wherein upon reception of the load data (134), the second application is loaded into the payment mode (106).
9. The method as claimed in claim 1, comprising:
generating by the server (110), an installation request to indicate installation of the second application on the payment mode (106), based on the selection of the second application;
receiving by the server (110), installation response from the payment mode (106) by way of the terminal device (108); and
detecting by the server (110), successful installation of the second application on the payment mode (106) based on the installation response.
10. A server (110), comprising:
a processor (136) configured to:
receive from a terminal device (108), a selection indicative of porting a payment mode (106) associated with a first payment network, wherein a first application associated with the first payment network is installed on the payment mode (106), and wherein the selection is inputted in the terminal device (108) by a user (102) of the payment mode (106);
initiate, based on the reception of the selection, mutual authentication between the server (110) and the payment mode (106);
generate, upon the mutual authentication being successful, a removal request indicative of removal of the first application associated with the first payment network from the payment mode (106); and
select, based on the removal of the first application from the payment mode (106), a second application associated with a second payment network such that the second application associated with the second payment network is installed on the payment mode (106).