Description:[001] The present disclosure relates to methods and systems for authenticating a payment transaction and, more particularly to, electronic methods and systems for facilitating the authentication of a cardholder.
BACKGROUND
[002] Nowadays, in the payment ecosystem, digital payments have taken over the bulk of payment transactions taking place between cardholders and merchants. A majority of these payment transactions are performed using payment cards such as credit cards, debit cards, and the like. Further, a significant portion of these payment transactions is being performed during e-commerce between a digital platform hosted by the merchant and the cardholder. For instance, a cardholder may perform a payment transaction on a merchant’s application installed on their smartphone to purchase goods or pay for services by entering various credentials related to their payment card on a payment gateway associated with the merchant on the merchant application. Such transactions, where the physical payment card is not required for performing the payment transaction are known as Card Not Present (CNP) transactions. As may be understood, while performing CNP transactions, it becomes crucial to authenticate the identity of the cardholder before the transaction can be processed to avoid a fraudulent payment transaction from taking place. To that end, various authentication techniques have been developed for authenticating a cardholder’s identity and thus, preventing fraud. A widely used authentication process is known as Multi-factor Authentication. An example of a Multi-factor Authentication process is a Two-Factor Authentication (2FA) or a Two-Step Authentication (2SA). It is noted that in some countries, regulations have been created that mandate the use of at least 2FA for authenticating any payment transaction. In 2FA, the identity of the cardholder is authenticated by two different factors or methods. For instance, the cardholder may be required to provide a Card Verification Value (CVV) and a Personal Identification Number (PIN) associated with a payment card being used to perform a payment transaction for authenticating the cardholder’s identity. In another instance, the cardholder may be required to provide a Card Verification Value (CVV) and a One-time Password (OTP) that is dynamically generated for each payment transaction and shared with the cardholder on a cardholder’s device (via Short Message Service (SMS) or Electronic Mail (E-mail)) for authenticating their identity.
[003] However, it has been observed that these conventional techniques for performing 2FA are not always secure and are regularly subjected to fraud as well. For instance, the CVV and the PIN associated with the cardholder may be stolen or hacked by a fraudster to perform a fraudulent transaction. In another instance, the OTP meant for the cardholder’s device (such as a mobile phone) may be intercepted and used by the fraudster to perform a fraudulent transaction. Additionally, there are other drawbacks to these conventional techniques for performing 2FA as well. For instance, the cardholder has to remember a PIN associated with their payment card which might become difficult for the cardholder if he/she has a plurality of payment cards. In some examples, to avoid this hassle, the cardholder may use the same PIN for all of his/her payment cards, which makes it inherently insecure and substantially increases the likelihood of fraud. In another instance, since a new OTP has to be generated for each new payment transaction, it might become cumbersome for the cardholder to provide the OTP again and again to the payment gateway while performing multiple transactions. Further, it is noted that OTP is generally only valid for a predefined time window and the same gets generated and transmitted to the cardholder over a network. Therefore, there exists an inherent lag or delay between the generation and transmission of the OTP to the receipt of the same by the cardholder. If this delay is higher than the predefined time window then, the cardholder will be unable to authenticate their identity. Thus, leading to the payment transaction being declined which may cause unnecessary inconvenience to the cardholder.
[004] Hence, there is a technological need for providing methods and systems for facilitating the authentication of a cardholder through a 2FA process while addressing the various disadvantages of the conventional techniques for performing 2FA described earlier.
SUMMARY
[005] Various embodiments of the present disclosure provide electronic methods and systems for facilitating authentication of the cardholder.
[006] In an embodiment, a computer-implemented method is disclosed. The method performed by a server system includes receiving a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on the electronic device associated with the cardholder. The user input indicates a payment card to be used for performing the payment transaction. The method further includes accessing stored card-linked biometric information of the cardholder from a database associated with the server system. Herein, the stored card-linked biometric information indicates at least one specific biometric template of the cardholder linked with the payment card. The method further includes generating and transmitting a biometric request for card-specific biometric information associated with the payment card to the issuer application. Upon receiving the card-specific biometric information, the method includes performing an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. Further, upon successful authentication, the method includes facilitating the transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application. The payment authentication request message includes a card-specific token. Herein the card-specific token is accessed from the issuer application by the server system. Furthermore, upon successful authentication by the corresponding issuer server, the method includes receiving and transmitting a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.
[007] In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on the electronic device associated with the cardholder. The user input indicates a payment card to be used for performing the payment transaction. The server system is further caused to access stored card-linked biometric information of the cardholder from a database associated with the server system. Herein, the stored card-linked biometric information indicates at least one specific biometric template of the cardholder linked with the payment card. The server system is further caused to generate and transmit a biometric request for card-specific biometric information associated with the payment card to the issuer application. Upon receiving the card-specific biometric information, the server system is caused to perform an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. Further, upon successful authentication, the server system is caused to facilitate the transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application. The payment authentication request message includes a card-specific token. Herein, the card-specific token is accessed from the issuer application by the server system. Furthermore, upon successful authentication by the corresponding issuer server, the server system is caused to receive and transmit a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.
[008] In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on the electronic device associated with the cardholder. The user input indicates a payment card to be used for performing the payment transaction. The method further includes accessing stored card-linked biometric information of the cardholder from a database associated with the server system. Herein, the stored card-linked biometric information indicates at least one specific biometric template of the cardholder linked with the payment card. The method further includes generating and transmitting a biometric request for card-specific biometric information associated with the payment card to the issuer application. Upon receiving the card-specific biometric information, the method includes performing an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. Further, upon successful authentication, the method includes facilitating the transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application. The payment authentication request message includes a card-specific token. Herein the card-specific token is accessed from the issuer application by the server system. Furthermore, upon successful authentication by the corresponding issuer server, the method includes receiving and transmitting a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.
[009] As may be understood, the foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the figures/drawings and the following detailed description.
BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates an example representation of an environment, related to at least some embodiments of the present disclosure;
[0012] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0013] FIG. 3 represents a sequence flow diagram for onboarding a cardholder by an issuer application, in accordance with an embodiment of the present disclosure;
[0014] FIG. 4 represents a sequence flow diagram for enabling a frictionless payment authentication option on a payment card of the cardholder, in accordance with an embodiment of the present disclosure;
[0015] FIGS. 5A and 5B, collectively, represent a sequence flow diagram for authenticating a payment transaction, in accordance with an embodiment of the present disclosure;
[0016] FIGS. 6A, 6B, and 6C, collectively, represent a sequence flow diagram for authenticating a payment transaction using the existing 3DS payment architecture, in accordance with another embodiment of the present disclosure;
[0017] FIGS. 7A-7D, collectively, represent various exemplary Graphical User Interfaces (GUIs) that are implemented on an electronic device for generating a card-specific token, in accordance with various embodiments of the present disclosure;
[0018] FIG. 8 illustrates a process flow diagram depicting a method for facilitating an authentication of a cardholder, in accordance with an embodiment of the present disclosure; and
[0019] FIG. 9 shows a simplified block diagram of an electronic device capable of implementing the various embodiments of the present disclosure.
[0020] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0021] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0022] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification does not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0023] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0024] The term "issuer", used throughout the description, refers to a financial institution normally called an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server called “issuer server” throughout the description.
[0025] Further, the term "acquirer", refers to a financial institution (e.g., a bank) that processes financial transactions for merchants. In other words, this can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., the shopping cart platform providers and the in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0026] The term "payment account", used throughout the description, refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction" or “transaction”). Examples of the payment account include, but are not limited to, a savings account, a credit account, an e-wallet account, a checking account, and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0027] The term "payment network", used throughout the description, refers to a network or collection of systems used for the transfer of funds through the use of cash substitutes. Payment networks may use a variety of protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be operated to perform transactions via cash substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard®.
[0028] The term “payment card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment cards include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in the form of data (e.g., a digital token) stored in a user device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0029] The term “merchant”, used throughout the description, may include a merchant that has a relationship with the payment processing network. The merchant may receive the proceeds from a purchase when the purchase is settled. The merchant is the company that is ultimately responsible for the financial transaction.
[0030] The terms “three domain secure”, “3D secure” or “3DS” interchangeably used through the description, refer to an authentication process used to authenticate a cardholder during card-not-present (CNP) transactions such as e-commerce transactions. The three domains of the 3DS authentication process include the issuer domain, the interoperability domain, and the acquiring domain. The issuer domain includes issuer banks that deploy an Access Control Server (ACS) for receiving 3D secure XML messages to authenticate the cardholder. The acquiring domain includes the merchants that deploy a Merchant Plug-in (MPI) to initiate a payment transaction. The interoperability domain includes a Directory Server (DS) deployed by a payment processor in a payment network to authenticate and allow communication between the MPI and the ACS.
[0031] The term “3DS program” or “3DS service” interchangeably used through the description, refers to the optional service provided to a cardholder by his/her issuer through which the cardholder may engage in CNP payment transactions with the 3DS authentication process. In various non-limiting examples, the cardholder may be required to voluntarily enroll in the 3DS program or a regulating entity may mandate the 3DS service for all payment transactions. Further, the term “3DS payment network” refers to a payment network or architecture within which payment transactions are authenticated using the 3DS authentication process. It is noted that during the 3DS authentication process, the ACS authenticates the identity of the cardholder by transmitting an OTP to the cardholder and further receiving the OTP from the cardholder through a payment gateway that may be associated with the DS. Further, the ACS compared the received OTP with the transmitted OTP to validate the identity of the cardholder. If the comparison is successful, then the ACS requests the issuer to approve the transaction. Otherwise, the ACS requests the issuer to decline the transaction. In both these scenarios, the ACS informs the DS whether the transaction status is approved or declined. Further, the DS is configured to inform the merchant through MPI of the transaction status.
[0032] The term "merchant application", used throughout the description, may refer to a software application associated with a particular merchant or may be associated with a number of different merchants. The merchant application may be capable of identifying a particular merchant (or multiple merchants) that is participating in a transaction with a cardholder. For instance, the merchant application may store information identifying a particular merchant server computer that is configured to provide a purchase environment in which the merchant server computer is capable of processing remote transactions initiated by the cardholder on the merchant application. Further, the merchant application may also include a general-purpose browser or other software-designed application configured to interact with multiple merchant server computers as long as the browser is configured to identify the merchant server computer and process a payment transaction. The merchant application may be installed on the general-purpose memory of an electronic device of the cardholder. To that end, the merchant application is configured to allow a cardholder to perform a payment transaction with a merchant in exchange for goods or services.
[0033] The term "issuer application", used throughout the description, may refer to a software application associated with a particular issuer or a number of different issuers. The issuer application may be capable of identifying a particular issuer (or multiple issuers) that is associated with a cardholder who is involved in a payment transaction with a merchant. For instance, the issuer application may store information identifying a particular issuer server that is configured to provide a payment environment in which the issuer server is capable of authenticating and processing payment transactions initiated by the cardholder with a merchant (e.g., on a merchant application). Further, the issuer application may also include a general-purpose browser or other software-designed application that is configured to interact with multiple issuers as long as the browser is configured to identify the issuer server and process a payment transaction. The issuer application may be installed on the general-purpose memory of an electronic device of the cardholder. To that end, the issuer application is configured to allow the cardholder to authenticate an ongoing payment transaction with a merchant.
[0034] The term "payment service provider", may include an entity that contracts with an acquirer for the purpose of providing acceptance to a merchant, the merchant then contracts with a payment service provider to obtain payment services.
OVERVIEW
[0035] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for facilitating the authentication of a cardholder.
[0036] In an embodiment, the server system is configured to receive a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on the electronic device associated with the cardholder. The user input may indicate a payment card to be used for performing the payment transaction. To receive the user input, the server system may be configured to receive a selection of the issuer application from one or more issuer applications on a merchant application associated with the merchant by a cardholder from the merchant application installed on the electronic device. The issuer applications are installed on the electronic device and each issuer application is associated with the corresponding issuer server. Further, the server system is configured to facilitate a display of a first GUI on the issuer application. Herein, the first GUI is configured to prompt the cardholder to select the payment card from one or more payment cards for performing the payment transaction. It may be noted that the one or more payment cards are eligible for a frictionless payment transaction. Further, the server system is configured to receive a selection of the payment card from the issuer application. In an embodiment, the server system is either a payment server or an issuer server.
[0037] In another embodiment, the server system is configured to access stored card-linked biometric information of the cardholder from a database associated with the server system. The stored card-linked biometric information may include at least one specific biometric template of the cardholder linked with the payment card. In particular, at first, the server system a frictionless payment enablement request for the payment card from the issuer application from one or more issuer applications installed on the electronic device. Then, the server system receives a selection of a new card-specific biometric information from one or more biometric information by the cardholder corresponding to the payment card on the issuer application. Then, the server system assigns the new card-specific biometric information to the payment card. Upon assigning the new card-specific biometric information to the payment card, the server system generates the card-specific token, wherein, the card-specific token is generated based, at least in part, on the new card-specific biometric information and the payment card. Furthermore, the server system stores the new card-specific biometric information assigned to the payment card as the stored card-linked biometric information in the database. Then, the server system facilitates the issuer application to store the card-specific token in the electronic device and transmits the card-specific token to the corresponding issuer server of the issuer application.
[0038] In an embodiment, the server system generates and transmits a biometric request for card-specific biometric information associated with the payment card to the issuer application. Further, the server system upon receiving the card-specific biometric information, performs an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information.
[0039] In particular, performing the authentication of the cardholder includes at first determining at least one provided biometric template based, at least in part, on the card-specific biometric information. Then, determining the cardholder identity based, at least in part, on comparing the at least one specific biometric template with the at least one provided biometric template. In some scenarios, to determine the cardholder identity, the server system may request a Fast Identity Online (FIDO) server to authenticate the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. Herein, the FIDO server is configured to compare the card-specific biometric information with the stored card-linked biometric information to authenticate the cardholder's identity. Then, the server system performs one of (1) determining that the authentication of the cardholder identity is successful based, at least in part, on a successful comparison, and (2) determining that the authentication of the cardholder identity is unsuccessful based, at least in part, on an unsuccessful comparison.
[0040] In another embodiment, upon successful authentication, the server system is configured to facilitate the transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application. The payment authentication request message may include a card-specific token. It is noted that herein the card-specific token is accessed from the issuer application by the server system. It is noted that at least one specific biometric template associated with each payment card of the one or more payment cards is unique. On the other hand, upon unsuccessful authentication of the cardholder identity, the server system is configured to generate and transmit a payment failure message to the issuer application.
[0041] In another embodiment upon successful authentication by the corresponding issuer server, the server system is configured to receive and transmit a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant. On the other hand, upon unsuccessful authentication corresponding issuer server, the server system is configured to receive and transmit a payment authorization message indicating an unsuccessful transaction to the acquirer server.
[0042] In another embodiment, the server system is configured to facilitate a display of a second GUI on the issuer application, where the second GUI is configured to prompt the cardholder to configure one or more settings associated with the payment card. Herein, the one or more settings include at least a token expiration time, wherein the token expiration time indicates the time period for which the card-specific token is valid. Further, the one or more settings associated with the payment card include a transaction amount limit and a transaction mode. Herein, the transaction amount limit indicates the maximum amount for the payment transaction and the transaction mode is the mode for the payment transaction.
[0043] In another embodiment, the server system is configured to transmit the card-specific token to a merchant application associated with the merchant installed on the electronic device. Herein, the merchant application is configured to generate and transmit the payment authentication request message to the corresponding issuer server.
[0044] Various embodiments of the present disclosure provide multiple advantages and technical effects while addressing technical problems such as how to authenticate a payment transaction initiated by a cardholder securely and effortlessly. Various embodiments described herein address this technical problem by allowing the cardholder to authenticate their identity by providing at least one specific biometric template linked with the payment card through which the payment transaction is being conducted and authenticating the transaction based on that alongside a card-specific token. It is noted that since the biometric template of every individual is unique, therefore, the chances of the biometric identity being stolen are very minimal, unlike PINs and OTPs. Further, since the card-specific token is generated using the biometric information for a particular card, the same is also secure. Thus, the present approach provides superior security when compared with the conventional 2FA techniques. Further, the cardholder can configure one or more settings associated with the card-specific token thus, allowing the cardholder to control the authentication process with ease. Furthermore, the issuer application can directly share the card-specific token with the merchant application upon successful authentication, thereby making the transaction authentication process effortless for the cardholder. Additionally, since the card-specific token can only be valid for a specific time period (wherein the specific time period may be freely altered by the cardholder using the one or more settings), the cardholder may perform multiple transactions with different merchant apps using the same card-specific token, thereby reducing the processing resources required at the issuer’s end to authenticate the transaction while also saving time for the cardholder. Furthermore, since the cardholder does not have to wait for an OTP, the transaction authentication process is expedited as well.
[0045] Various embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 9.
[0046] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, implementing a process for authenticating payment transactions performed by a cardholder in a frictionless manner using multi-factor authentication. The environment 100 generally includes a server system 102, a cardholder 104, an electronic device 106 associated with the cardholder 104, a merchant 108, an acquirer server 120, a payment network 110 including a payment server 112, a Fast Identity Online (FIDO) server 122, and a database 114, each coupled to, and in communication with (and/or with access to) a network 116. The network 116 may include, without limitation, 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, a virtual network, and/or another suitable public and/or private network capable of supporting communication among the entities illustrated in FIG. 1, or any combination thereof.
[0047] Various entities in the environment 100 may connect to the network 116 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, any combination thereof or any future communication protocols. For example, the network 116 may include multiple different networks, such as a private network or a public network (e.g., the Internet, etc.) through which the server system 102, the issuer server 118, the acquirer server 120, the FIDO server 122, and the payment server 112 may communicate.
[0048] In an embodiment, the cardholder (e.g., the cardholder 104) may be any individual, representative of a corporate entity, non-profit organization, or any other person who is presenting payment account details or payment card details during an electronic payment transaction. The cardholder (e.g., the cardholder 104) may have a payment account issued by an issuing bank (not shown in figures) and may be provided a payment card with financial or other account information encoded onto the payment card such that the cardholder (i.e., the cardholder 104) may use the payment card associated with a payment account at the issuing bank to initiate and complete a payment transaction. Generally, the term “payment transaction” refers to an agreement that is carried out between a buyer and a seller to exchange assets for a form of payment (e.g., cash, currency, etc.). For example, the cardholder 104 may enter details of the payment card on an e-commerce platform to buy goods or products. In an example, the cardholder (e.g., the cardholder 104) may transact at the merchant 108.
[0049] The cardholder 104 may be associated with the electronic device 106 and may use the electronic device 106 to access a mobile application or a website associated with the issuing bank, a merchant 108, or any third-party payment application to perform a transaction. In an instance, the electronic device 106 may be equipped with the necessary sensor or array of sensors for gathering the required biometric information from the cardholder 104. For instance, the electronic device 106 may include a capacitive fingerprint scan sensor, an ultrasound fingerprint scan sensor, an iris scanner, camera modules, a 3D face scan sensor array, a heartbeat sensor, and the like for gathering biometric information of the cardholder 104.
[0050] In various non-limiting examples, the electronic device 106 may include any portable communication devices such as a smartphone, tablet, personal digital assistant (PDA), phablet, wearable device, smart watch, laptop computer, an augmented reality (AR) headset, a virtual reality (VR) headset, and the like. In some other examples, the electronic device 106 may include any fixed communication device such as a desktop, mainframe computer, workstation, and the like. In one exemplary implementation, the electronic device 106 may be equipped with one or more applications (such as an instance of an issuer application 124, a merchant application associated with the merchant 108 described later on) for communicating with the server system 102 over the network 116. In particular, one or more applications may be installed on the electronic device 106 by the cardholder 104. Further, the one or more applications may be capable of communicating with the server system 102. In various non-limiting examples, the one or more applications may correspond to a web browser, an application associated with the issuer server 118, an application associated with the merchant 108, an application programming interface (API) associated with the issuer server 118, an application associated with the server system 102, an API associated with the server system 102, and the like.
[0051] In one scenario, the cardholder 104 may use their corresponding payment card to conduct payment transactions with the merchant 108. In an example, the cardholder 104 may enter payment card details on a mobile device to perform an online payment transaction. In another example, the cardholder 104 may utilize a payment card to perform an offline payment transaction.
[0052] In one embodiment, the cardholder 104 may be associated with an issuer server such as issuer server 118. In one embodiment, the issuer server 118 is associated with a financial institution normally called an "issuer bank", "issuing bank" or simply "issuer", in which a cardholder (e.g., the cardholder 104) may have a payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder (e.g., the cardholder 104). In another embodiment, the issuing bank may also provide an issuer application 124 that may be installed by a cardholder 104 on their electronic device 106. The issuer application 124 may provide a plurality of banking-related facilities to the cardholder 104. In particular, the issuer application 124 may enable the cardholder 104 to avail various services offered by the issuer through the issuer server 118. For instance, the cardholder 104 may use the issuer application 124 to check their account balance and account statements and manage their payment account and their one or more payment cards provided by the issuer.
[0053] The term "issuer application 124", used throughout the description, may refer to a software application associated with a particular issuer or may be associated with a number of different issuers and may be capable of identifying a particular issuer (or multiple issuers) that is associated with a cardholder 104 who is involved in a payment transaction with a merchant 108. For instance, the issuer application 124 may store information identifying a particular issuer server that is configured to provide a payment environment in which the issuer server 118 is capable of authenticating and processing remote transactions initiated by the cardholder 104 with a merchant 108 (e.g., on a merchant application). Further, the issuer application 124 may also include a general-purpose browser or other software-designed application that is configured to interact with multiple issuers serves as long as the browser is configured to identify the issuer server 118 and process a payment transaction. The issuer application 124 may be installed on the general-purpose memory of an electronic device 106 of the cardholder 104. To that end, the issuer application 124 is configured to allow the cardholder 104 to authenticate an ongoing payment transaction with a merchant 108 in exchange for goods or services.
[0054] In an embodiment, the merchant 108 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where cardholders visit to perform the financial transaction in exchange for any goods and/or services or any financial transactions. In another embodiment, the merchant 108 may provide a merchant application that may be installed by a cardholder 104 on their electronic device 106. The merchant application may enable the cardholder 104 to perform a payment transaction in exchange for goods or services with the merchant 108. The merchant application may enable the cardholder 104 to perform the payment transaction through various methods such as using payment cards, net banking, Unified Payments Interface (UPI), Cash-on-Delivery (COD), and so on.
[0055] In an embodiment, the merchant 108 is associated with an acquirer server (e.g., the acquirer server 120). In one embodiment, the acquirer server 120 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, merchants (e.g., the merchant 108), or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0056] As described earlier, the conventional techniques for performing authentication of the cardholder are not always secure and are regularly subjected to fraud. Furthermore, the conventional techniques are slow and might be cumbersome for the cardholder 104 while performing multiple transactions. As may be understood, most payment transactions nowadays are performed on merchant applications associated with different merchants. It is noted that the conventional techniques do not provide an integrated approach to facilitate a faster and frictionless mode for performing such transactions. For instance, the cardholder 104 may have to manually add the OTP that is received on their electronic device 106 from the issuer (or the ACS) for authenticating their identity to complete the payment transaction. Although several approaches have been developed that fetch the OTP for the merchant application once it is received, in some scenarios, these approaches have to be manually enabled or may not be supported by the merchant application. However, even such approaches are unable to address the inherent disadvantages of using OTP based 2FA described earlier.
[0057] To that end, for overcoming the various technical problems and disadvantages described earlier, the present disclosure provides a server system 102 that is configured to perform one or more operations for addressing these technical problems.
[0058] In an embodiment, the one or more operations performed by the server system 102 facilitate the authentication of the cardholder 104 safely and securely. Further, the one or more operations performed by the server system 102 provide the issuer application 124 the capability to facilitate frictionless authentication of the cardholder 104.
[0059] In another embodiment, the server system 102 is configured to run an instance of an issuer application 124. In one embodiment, the server system 102 utilizes the issuer application 124 to authenticate payment transactions. In one embodiment, the issuer application 124 is an application/tool resting at the server system 102. In another embodiment, the issuer application 124 may be an application provided by an issuing bank or the issuer server 118, and the server system 102 is configured to provide the issuer application 124 with one or more functionalities using various Application Programming Interfaces (APIs). In particular, the server system 102 may communicate with the issuer application 124 installed on the electronic device 106 of the cardholder 104 using a plurality of API calls to provide these one or more functionalities. It should be noted that one or more functionalities provided by the server system 102 are not limited to a single application provided by a particular issuer. Instead, the one or more functionalities may be provided by the server system 102 to one or more issuer applications associated with different issuers or issuer servers.
[0060] It is noted that for the sake of simplicity, FIG. 1 depicts a single instance of the issuer application 124 however, the same should not be construed as a limitation of the various embodiments of the present disclosure. As described earlier, the server system 102 is capable of providing the one or more functionalities to one or more issuer applications associated with different issuers or issuer servers. Such that, each issuer application 124 corresponds to a particular issuer (or issuer server 118).
[0061] In an embodiment, the issuer application 124 may be configured to generate one or more graphical user interfaces in response to communication with the server system 102 for facilitating a Multi-Factor Authentication (such as 2FA) of a cardholder (such as cardholder 104).
[0062] In one embodiment, the electronic device 106 is communicably coupled with the server system 102 through the network 116 and the electronic device 106 is capable of interacting with the issuer application 124 associated with the server system 102 through a web browser or an application programming interfaces (APIs) installed on the electronic device 106. In other words, the electronic device 106 of the cardholder 104 is capable of performing one or more operations using the issuer application 124. In one implementation, the issuer application 124 utilizes communication APIs to communicate back and forth with the electronic device 106. In an example, the issuer application 124 utilizes various distribution methods for sharing one or more messages, requests, or responses with the electronic device 106 of the cardholder 104, the merchant application, the issuer server 118, the server system 102, the ACS, and the like. In various non-limiting examples, the distribution methods may include short message service (SMS), electronic mail (email), communication APIs, embeddable widgets, and the like. In an example, the issuer application 124 utilizes communication APIs to share the results of their various operations (described later on) with the server system 102, the merchant application, or the electronic device 106. Herein, it is understood that the term “API” generally refers to a set of programming standards and/or instructions for web-based applications and tools. For instance, “communication APIs” refer to APIs specifically designed to enable communication (e.g., voice calls, e-mail functionality, third-party messaging functionality, other communication functionality, etc.).
[0063] In some scenarios, the issuer application 124 may include a mobile application or “app”. Herein, in various examples, the electronic device 106 may be an Android®-based smartphone, an iOS®-based iPhone®, iPadOS®-based iPad®, a Windows®-based computer, a macOS®-based computer, an augmented reality (AR) device, a virtual reality (VR) device, and the like. The issuer application 124 may also include a “plug-in” or an “extension” to another application, such as a pre-existing application (i.e., a third-party application) or API associated with the third-party application. In an implementation, the issuer application 124 is managed, hosted, or executed by the server system 102. In another implementation, the issuer application 124 is managed, hosted, or executed by a communication device (not shown in figures) associated with the issuer server 118. In this scenario, the issuer application 124 is able to communicate with the server system 102 to perform various operations (described later on).
[0064] In an embodiment, the server system 102 is associated with a database such as database 114. In various non-limiting examples, the database 114 may include one or more hard disk drives (HDD), solid-state drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a redundant array of independent disks (RAID) controller, a storage area network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 114. In one implementation, the database 114 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 114.
[0065] In an embodiment, the server system 102 is configured to receive a frictionless payment enablement request for a payment card from the issuer application 124 from one or more issuer applications installed on the electronic device 106. It is noted that the frictionless payment enablement request may indicate that the cardholder 104 wishes to enable a frictionless payment option for a particular payment card. Herein, the frictionless payment option may refer to a facility offered by different issuing banks to authenticate a payment transaction using an issuer application such as issuer application 124 associated with the corresponding issuer. In response, the server system 102 is configured to prompt the cardholder 104 using the issuer application 124 to select a new card-specific biometric information from one or more biometric information. It is noted the term ‘new card-specific biometric information’ indicates at least one specific biometric template of the cardholder 104 that can be linked with the payment card by the cardholder 104. The term ‘biometrics template’ refers to a template associated with specific biometric information of the cardholder 104. For instance, a biometric template may include a facial image of the cardholder 104. In various non-limiting examples, the biometric template may include any biometric information related to the cardholder 104 such as, but not limited to, a facial image, a fingerprint image of one or more fingers of the cardholder 104, a three-dimensional (3D) facial scan of the cardholder 104, a 3D fingerprint of one or more fingers of the cardholder 104, an audio print or voice print of the cardholder 104, heart rhythm of the cardholder 104, a retina scan, etc., among any other suitable biometric information that may be used to authenticate the cardholder 104.
[0066] Upon receiving the new card-specific biometric information from the issuer application 124, the server system 102 is configured to assign the new card-specific biometric information to the payment card. It is noted that, in an implementation, the new card-specific biometric information that may be assigned to the payment card may be unique. For instance, if for a first payment card, the cardholder 104 has assigned the fingerprint of his left thumb as the card-linked biometric information, then for a second payment card the cardholder 104 may assign any biometric information apart from the fingerprint of his left thumb as the card-linked or card-specific biometric information. Therefore, the selected biometric information can be specific to each payment card. Further, the server system 102 is configured to generate a card-specific token for the payment card based, at least in part, on the new card-specific biometric information and the payment card. In another embodiment, the server system 102 is configured to facilitate the issuer application 124 to generate a card-specific token for the payment card based, at least in part, on the new card-specific biometric information and the payment card. It is noted that the card-specific token is stored by the issuer application 124 on the electronic device 106. Thereafter, the server system 102 is configured to store the new card-specific biometric information assigned to the payment card as the stored card-linked biometric information in the database 114. Further, the server system 102 transmits the card-specific token to the corresponding issuer server 118 of the issuer application 124.
[0067] Now in one scenario, where a cardholder 104 is using a merchant application associated with the merchant 108 to perform a payment transaction to complete a purchase of goods or services. The merchant application may facilitate the cardholder 104 to complete the transaction with a frictionless payment option. Upon selecting this frictionless payment option, the merchant application may be configured to display a GUI to the cardholder 104 on the display of their electronic device 106. The GUI may be generated and configured to prompt the cardholder 104 to provide their user input to select an issuer application (such as issuer application 124) from one or more issuer applications installed on the electronic device 106 of the cardholder 104 for initiating a frictionless cardholder authentication process. In some instances, the server system 102 may be configured to facilitate the merchant application in the generation of the GUI for prompting the cardholder 104 for user input. In response to the selection of the issuer application 124, the merchant application may redirect the cardholder 104 to the selected issuer application 124 on their electronic device 106. In other words, once the cardholder 104 makes the selection of the issuer application 124, the merchant application may open the selected issuer application 124 on the electronic device 106.
[0068] It is noted that as described earlier each issuer application 124 is associated with a corresponding issuer server 118. In response to receiving the selection, the server system 102 is configured to facilitate a display of a first GUI on the issuer application 124. Further, the server system 102 may configure the first GUI to prompt the cardholder 104 to select the payment card from one or more payment cards for performing the payment transaction. It is noted that one or more payment cards are issued by the issuing bank associated with the issuing application 124. Furthermore, the one or more payment cards are those payment cards of the cardholder 104 which are eligible for the frictionless payment option. Once, the cardholder 104 selects a payment card on the issuer application 124, the server system 102 is configured to receive the selection of the payment card from the issuer application 124. It is noted that an API message may be shared by the issuer application 124 to the server system 102 for communicating the selection of the payment card.
[0069] The server system 102 is further configured to access stored card-linked biometric information of the cardholder 104 from the database 114 associated with the server system 102. As described earlier, the stored card-linked biometric information indicates at least one specific biometric template of the cardholder 104 linked with the payment card. Then, the server system 102 generates and transmits a biometric request for card-specific biometric information associated with the payment card to the issuer application 124. Upon receiving the biometric request, the issuer application 124 collects the card-specific biometric information from the cardholder 104 using the various sensors in the electronic device 106 (described earlier) and then, the issuer application 124 transmits the card-specific information to the server system 102.
[0070] In response to receiving the card-specific biometric information, the server system 102 is configured to perform an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. This authentication process may be performed by the server system 102 associated with the FIDO server 122 (described later). Upon successful authentication, the server system 102 is configured to facilitate the transmission of a payment authentication request message to a corresponding issuer server (i.e., issuer server 118) associated with the issuer application 124. The payment authentication request message may include at least a card-specific token. Herein, the card-specific token is accessed from the issuer application 124 by the server system 102. Upon receiving the payment authentication request message, the issuer server 118 may match the card-specific token for the payment card with the card-specific token received during the frictionless transaction enablement process. If the matching is successful, the issuer server 118 determines that the authentication is successful. Otherwise, the authentication is deemed to be unsuccessful by the issuer server 118.
[0071] Upon successful authentication by the corresponding issuer server 118, receiving and transmitting, a payment authorization message indicating a successful transaction to the acquirer server 120 associated with the merchant 108. Thus, completing the payment transaction. As may be understood, the frictionless payment technique described herein, implements the 2FA authentication process using biometrics of the cardholder 104 and the card-specific token while also ensuring a quick authentication process as well.
[0072] In an embodiment, the Fast Identity Online (FIDO) server 122 is associated with an institution that enables any online service provider to authenticate the identity of its users (such as cardholders) safely and securely. In particular, the FIDO server 122 is capable of registering, storing, and authenticating information related to the identity of different users. For instance, FIDO server 122 may register and store a digital identity of a cardholder using their biometric information (such as fingerprints, etc.). In another instance, the FIDO server 122 is also capable of validating or authenticating the identity of cardholder 104 based on comparing the registered biometric information with new biometric information received from the cardholder 104. For instance, if a cardholder 104 is registered using a first facial scan and then provides a second facial scan at a later instance, the FIDO server 122 is configured to perform various operations to compare the first facial scan and the second facial scan to determine if the second facial scan indeed belongs to the same cardholder or not. Upon determining that the second facial scan matches the first scan, the FIDO server 122 may authenticate the cardholder 104. Otherwise, the authentication may fail. In various scenarios, the server system 102 may utilize the FIDO server 122 to authenticate the identity of the cardholder 104 based, at least in part, on the card-specific biometric information and the stored card-linked biometric information. In other scenarios, the server system 102 itself may implement the functionalities of the FIDO server 122.
[0073] In one embodiment, the payment network 110 may be used by the payment card issuing authorities as a payment interchange network. Examples of payment interchange networks include but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of electronic payment transaction data between issuers and acquirers that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0074] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0075] Referring now to FIG. 2, a simplified block diagram of a server system 200 is illustrated, in accordance with an embodiment of the present disclosure. The server system 200 is an example of the server system 102. In one embodiment, the server system 200 is a part of the payment network 110 or integrated within the payment server 112. In another embodiment, the server system 200 can be integrated within the issuer server 118 as well. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
[0076] The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, and a storage interface 214 that communicate with each other via a bus 212.
[0077] In some embodiments, the database 204 is integrated within the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. A storage interface 214 is any component capable of providing the processor 206 with access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204. In one non-limiting example, the database 204 is configured to store credentials associated with the cardholders such as the cardholder 104 in FIG. 1. In one implementation, the database 204 is configured to include stored card-linked biometric information 224.
[0078] The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for performing authentication of the cardholder 104 in a frictionless manner via multi-factor authentication. Examples of the processor 206 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a graphical processing unit (GPU), a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
[0079] The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
[0080] The processor 206 is operatively coupled to the communication interface 210, such that the processor 206 is capable of communicating with a remote device 216 such as the acquirer server 120, or communicating with any entity connected to the network 116 (as shown in FIG. 1).
[0081] It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.
[0082] In one implementation, the processor 206 includes a cardholder registration module 218, an authentication module 220, and a Graphical User Interface (GUI) generation module 222. It should be noted that the components, described herein, such as the cardholder registration module 218, the authentication module 220, and the GUI generation module 222 can be configured in a variety of ways, including electronic circuitries, digital arithmetic and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
[0083] In an embodiment, the cardholder registration module 218 includes suitable logic and/or interfaces for receiving a frictionless payment enablement request for a payment card from the issuer application 124 from one or more issuer applications installed on the electronic device 106. In particular, the cardholder registration module 218 may at first facilitate the issuer application 124 to display a GUI prompting the cardholder 104 to select a payment card from one or more payment cards using the GUI generation module 222. For instance, a GUI shows a list of payment cards on which the frictionless payment option may be enabled. It is noted that the issuer may determine for which payment cards, a cardholder 104 may enable the frictionless payment option based on its internal policies. The cardholder 104 may then select a payment card from the list of one or more payment cards and in response, the issuer application 124 generates and transmits the frictionless payment enablement request to the cardholder registration module 218 of the server system 200.
[0084] In response to the frictionless payment enablement request, the cardholder registration module 218 is configured to facilitate the issuer application 124 to display a GUI prompting the cardholder 104 to select a new card-specific biometric information from one or more biometric information by the cardholder 104 corresponding to the payment card on the issuer application 124 using the GUI generation module 222. For instance, a list of biometric information options may be displayed to the cardholder 104. The cardholder 104 may select a desired option from this list of biometric information to provide new card-specific biometric information to the cardholder registration module 218. For example, issuer application 124 may display two biometric information options to the cardholder 104. The first option corresponds to “Fingerprint” and the second option corresponds to “Facial identity”. If the cardholder 104 selects the first option, then biometric information (i.e., the new card-specific biometric information) is transmitted or shared with the cardholder registration module 218. In a non-limiting implementation, the biometric information options may be more granular and provide option combinations as well. For example, different biometric information options may be provided for different fingers of the cardholder 104. In another example, different combinations of biometric information options may be shown as well such as an option for providing a fingerprint of a right-hand thumb and the facial identity of the cardholder 104. Thereafter, the cardholder registration module 218 is configured to receive the new card-specific biometric information by the cardholder 104 corresponding to the payment card on the issuer application 124. Such that herein, the new card-specific information is received in response to a selection of an option corresponding to new card-specific biometric information from one or more biometric information options by the cardholder 104. It is noted that the new card-specific information includes at least one specific biometric template of the cardholder 104 linked with the payment card. It is understood that the specific biometric template includes a biometric template of the cardholder 104, i.e., in accordance with the selected biometric information option by the cardholder 104. For example, if the cardholder 104 selects the second option, then a facial identity template is shared with the cardholder registration module 218. Upon receiving the new card-specific information, the cardholder registration module 218 assigns the same to the payment card from which the frictionless payment enablement request is received.
[0085] In some scenarios, the GUI may prompt the cardholder 104 to select new card-specific biometric information from a list of one or more available biometric information options by the cardholder 104 corresponding to the payment card on the issuer application 124. In such scenarios, if a first option from two options has been selected for a particular card by enabling the frictionless payment option. Then, for subsequent frictionless payment enablement requests for another payment card, only the second option will be available for the cardholder 104 to select. Effectively, in other words, at least one specific biometric template associated with each payment card of the one or more payment cards associated with the cardholder 104 for a particular issuer is unique.
[0086] Further, upon assigning the new card-specific biometric information to the payment card, the cardholder registration module 218 generates a card-specific token based, at least in part, on the new card-specific biometric information and the payment card. In particular, the card-specific token is linked to the payment card. Then, the cardholder registration module 218 stores the new card-specific biometric information assigned to the payment card as stored card-linked biometric information 224 in the database 204. Further, the cardholder registration module 218 facilitates the issuer application 124 to store the card-specific token in the electronic device 106. Further, the cardholder registration module 218 transmits the card-specific token to the corresponding issuer server 118 of the issuer application 124. In some scenarios, the cardholder registration module 218 may facilitate the issuer application 124 to configure one or more settings associated with the card-linked token generated for the payment card. In an implementation, the cardholder registration module 218 may facilitate a display of a GUI on the issuer application 124 using the GUI generation module 222. Herein, the GUI is configured to prompt the cardholder 104 to configure one or more settings associated with the payment card. In various non-limiting examples, the one or more settings may include at least a token expiration time, a transaction amount limit, a transaction mode, etc., among other suitable settings. The term ‘the token expiration time’ indicates the time period for which the card-specific token is valid. The term ‘the transaction amount limit’ indicates the maximum amount for the payment transaction that may be performed using the payment card. Further, the term ‘the transaction mode’ is the mode for the payment transaction.
[0087] In an embodiment, the authentication module 220 includes suitable logic and/or interfaces for a selection of the issuer application 124 from one or more issuer applications from a merchant application installed on the electronic device 106 for an ongoing payment transaction. This selection is made by the cardholder 104 on the merchant application associated with the merchant 108. As described earlier, the one or more issuer applications may be installed on the electronic device 106 and each issuer application 124 of the one or more issuer applications is associated with the corresponding issuer server 118. For instance, if issuer application A and issuer application B are installed on a mobile phone of the cardholder 104, then the merchant application may show options to select from these two issuer applications when a frictionless payment option is selected by the cardholder 104 to complete the ongoing payment transaction. Upon selecting the issuer application 124, the merchant application may redirect the cardholder 104 to the selected issuer application 124. Now, on this selected issuer application 124, the authentication module 220 may utilize the GUI generation module 222 to facilitate the issuer application 124 to display a first GUI on the electronic device 106. In particular, the first GUI may be configured to prompt the cardholder 104 to select a payment card from one or more payment cards for performing the payment transaction, wherein the one or more payment cards are eligible for a frictionless payment transaction. Then, upon determining that the cardholder 104 has selected a payment card, the authentication module 220 receives the selection of the payment card from the issuer application 124.
[0088] Thereafter, the authentication module 220 is configured to access the stored card-linked biometric information 224 of the cardholder 104 from the database 204. As described earlier, the stored card-linked biometric information 224 indicates at least one specific biometric template of the cardholder 104 linked with the payment card. Then, the authentication module 220 is configured to generate and transmit a biometric request for card-specific biometric information associated with the payment card to the issuer application 124. In response to receiving the biometric request, the issuer application 124 is configured to prompt the cardholder 124 to provide a biometric template linked to the payment card. For instance, the issuer application 124 may show the cardholder 104 a notification to provide their card-specific biometric information for the payment card. In some scenarios, a hint may be shown to the cardholder 104 specifying which biometric information they must provide for the selected payment card. For example, a hint may say “Please provide a fingerprint of your left-hand thumb to authenticate your identity”. Upon receiving this card-specific biometric information including at least one provided biometric template from the cardholder 104, the issuer application 124 transmits the same to the authentication module 220 of the server system 200.
[0089] Upon receiving the card-specific biometric information, the authentication module 220 is configured to perform an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information 224. In particular, the authentication module 220 determines at least one provided biometric template based, at least in part, on the card-specific biometric information. Then, the authentication module 220 determines the cardholder identity based, at least in part, on comparing the at least one specific biometric template with the at least one provided biometric template. In a non-limiting implementation, for determining the cardholder identity, the authentication module 220 may request a Fast Identity Online (FIDO) server 122 to authenticate the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information 224. Herein, upon receiving the request, the FIDO server 122 may be configured to compare the card-specific biometric information with the stored card-linked biometric information to authenticate the cardholder's identity.
[0090] Now, if the comparison is successful, then it is determined that the authentication of the cardholder identity is successful. On the other hand, if the comparison is unsuccessful, then it is determined that the authentication of the cardholder's identity is unsuccessful. Upon unsuccessful authentication of the cardholder identity, the authentication module 220 is configured to generate and transmit a payment failure message to the issuer application 124. In other words, the transaction fails if the authentication is unsuccessful.
[0091] Upon successful authentication of the cardholder identity, the authentication module 220 is configured to facilitate the transmission of a payment authentication request message to a corresponding issuer server 118 associated with the issuer application 124. In one example, the payment authentication request message may include a card-specific token accessed from the issuer application 124 by the authentication module 220. In various examples, the payment authentication request message may include other transaction related information as well. Once, the issuer server 118 receives the card-specific token, the issuer server 118 may be configured to check if the received card-specific token matches the card-specific token shared earlier with the issuer server 118 by the cardholder registration module 218. Now, if the card-specific token matches, then it is determined by the issuer server 118 that the authentication of the cardholder identity is successful. On the other hand, if the card-specific token does not match, then it is determined by the issuer server 118 that the authentication of the cardholder identity is unsuccessful.
[0092] In an embodiment, if the authentication by the corresponding issuer server 118 of the issuer application 124 is successful, then the issuer server 118 generates and transmits a payment authorization message indicating a successful transaction to the authentication module 220. Upon receiving this payment authorization message, the authentication module 220 transmits the same to the acquirer server 120 associated with the merchant 108. Then, the acquirer server 120 may share a payment successful message with the merchant 108. As may be understood, upon receiving the payment successful message, the merchant 108 may process the payment transaction to complete the purchase with the cardholder 104 on the merchant application. In an alternative embodiment, if the authentication by the corresponding issuer server 118 of the issuer application 124 is unsuccessful, then the issuer server 118 generates and transmits a payment authorization message indicating an unsuccessful transaction to the authentication module 220. Upon receiving this payment authorization message, the authentication module 220 transmits the same to the acquirer server 120 associated with the merchant 108. Then, the acquirer server 120 may share a payment unsuccessful message with the merchant 108. As may be understood, upon receiving the payment unsuccessful message the merchant 108 aborts the payment transaction thus, halting the purchase with the cardholder 104 on the merchant application.
[0093] In an embodiment, the Graphical User Interface (GUI) generation module 222 includes suitable logic and/or interfaces for generating various GUIs described throughout the present disclosure for both the one or more issuer applications and the merchant application.
[0094] FIG. 3 represents a sequence flow diagram 300 for onboarding a cardholder such as cardholder 104 by an issuer application such as issuer application 302, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 300, references may be made to elements described in FIGS. 1-2. It is noted the issuer application 302 and the FIDO server 304 are identical to the issuer application 124 and FIDO server 122 of FIG. 1, respectively. It is understood that the various steps of the sequence flow have already been explained with reference to FIGS. 1 and 2, therefore an explanation for the same is not repeated herein for the sake of brevity. The sequence flow begins at step 306.
[0095] At step 306, the cardholder 104 may install the issuer application 302 associated with an issuing bank via an issuer server 118 on their electronic device 106. In an example, the cardholder 104 may install the issuer application from a digital application distribution service offered by any suitable entity such as Google Play store® by Google®, App store® by Apple®, and so on.
[0096] At step 308, the cardholder 104 may log in to the issuer application 302 using the login credentials provided by the issuer while setting up their payment account with the issuer. In a scenario, where the cardholder 104 has not registered with the issuer application 302, then he/she may register with the issuer application 302 by transmitting a signup request with the issuer application 302. It is noted that any generic sign-up process may be followed to do the same. For instance, the cardholder 104 may register a user name and password with the issuer application 302 to login into their user account on the issuer application 302.
[0097] At step 310, the cardholder 104 may register for biometric authentication on the issuer application 302. To perform the biometric registration and authentication, the issuer application 302 may utilize a FIDO server 304 that is capable of facilitating the issuer application 302 in performing the biometric authentication. To that end, the issuer application 302 generates and transmits the FIDO registration request to the FIDO server 304. It is noted that the FIDO registration request may include biometric information (further including a biometric template of the cardholder 104) for registering the cardholder against the biometric information provided on the FIDO registration request.
[0098] At step 312, the FIDO server 304 performs the registration of the cardholder 104 against the biometric information provided on the FIDO registration request. It is noted that upon successful registration, the cardholder 104 may be required to provide the same biometric information on the issuer application 302 every time he/she wishes to log in to the issuer application 302.
[0099] At step 314, upon registering the cardholder 104, the FIDO server 304 transmits a FIDO registration response to the issuer application 302 indicating the completion of the FIDO registration process. Further, at step 316, the issuer application 302 shares a notification with the cardholder 104 indicating the successful FIDO registration.
[00100] FIG. 4 represents a sequence flow diagram 400 for enabling a frictionless payment authentication option on a payment card of the cardholder 104, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 400, references may be made to elements described in FIGS. 1-3. It is understood that the various steps of the sequence flow have already been explained with reference to FIGS. 1-3, therefore an explanation for the same is not repeated herein for the sake of brevity. The sequence flow begins at step 402.
[00101] At step 402, the cardholder 104 may select a frictionless payment authentication option for a payment card on the issuer application 124 installed on their electronic device 106. In response to the selection of the frictionless payment authentication option, the issuer application 124 transmits a frictionless payment enablement request for the payment card to the server system 200.
[00102] Subsequently, the issuer application 124 may prompt the cardholder 104 to provide new card-specific biometric information for the payment card. In an implementation, the issuer application 124 is configured to provide one or more biometric information options to the cardholder 104, at step 404.
[00103] Then, in response to a selection of an option corresponding to new card-specific biometric information from one or more biometric information options by the cardholder 104 at step 406, the issuer application 124 collects and transmits the new card-specific biometric information (including at least one biometric template) to the server system 200, at step 408.
[00104] Upon receiving the new card-specific biometric information, the server system 200 registers the new card-specific biometric information with the FIDO server 122, at step 410. It is noted that the process of registering biometric information with the FIDO server 122 has already been described earlier therefore, an explanation of the same is not repeated.
[00105] Then, at step 412, the server system 200 assigns new card-specific biometric information to the payment card and stores the new card-specific biometric information as stored card-specific biometric information.
[00106] At step 414, the server system 200 generates a card-specific token on the issuer application 124 based, at least in part, on the new card-specific biometric information and the payment card. In an implementation, the server system 200 may facilitate the issuer application 124 with the functionality to change one or more settings associated with the card-specific token.
[00107] At step 416, the server system 200 accesses the card-specific token from the issuer application 124 and transmits the card-specific token for the payment card to the issuer server 118.
[00108] FIGS. 5A and 5B, collectively, represent a sequence flow diagram 500 for authenticating a payment transaction, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 500, references may be made to elements described in FIGS. 1-4. It is understood that the various steps of the sequence flow have already been explained with reference to FIGS. 1 to 4, therefore an explanation for the same is not repeated herein for the sake of brevity. Further, it should be noted that the various steps described to be performed by the issuer application 124 may be performed by the server system 200 associated with the issuer application 124 since in various embodiments, the server system 200 may facilitate the issuer application 124 to perform the various steps described herein. The sequence flow begins at step 504.
[00109] At step 504, the cardholder 104 may initiate a purchase on a merchant application 502 associated with a merchant 108. Thereon, to complete the payment transaction for the purchase, the cardholder 104 may opt for a frictionless payment option.
[00110] At step 506, upon selecting the frictionless payment option, the merchant application 502 may display a GUI on the display of the electronic device 106 showing a list of one or more issuer applications installed on the electronic device 106 that provide the frictionless payment facility to the cardholder 104. Herein, the GUI is configured to prompt the cardholder 104 to select an issuer application 124 from the one or more issuer applications to conduct the frictionless payment transaction.
[00111] At step 508, the cardholder 104 selects a desired issuer application 124 from the one or more issuer applications.
[00112] At step 510, the merchant application 502 calls the issuer application 124 to initiate the frictionless payment transaction for the ongoing payment transaction. In other words, the merchant application 502 redirects to the selected issuer application 124 for authenticating the ongoing payment transaction.
[00113] At step 512, the issuer application 124 displays a GUI to the cardholder 104 on the display of the electronic device 106 to select a payment card for performing the payment transaction from one or more payment cards eligible for frictionless payment transactions. It is noted that for one or more payments to become eligible for the frictionless payment transaction, they have to be first registered with the issuer application 124. In a particular implementation for registering payment cards has already been described in FIG. 4. To that end, explanation for the same is not repeated. In an instance, before performing step 510, the issuer application 124 may perform an authentication of the cardholder 104 using the FIDO server 122.
[00114] At step 514, the cardholder 104 selects a payment card on the issuer application 124.
[00115] At step 516, upon receiving a selection of a payment card from the cardholder 104, the issuer application 124 transmits the information related to the selection of the payment card with the server system 200.
[00116] At step 518, the server system 200 accesses stored card-linked biometric information 224 of the cardholder 104 from a database such as database 204 associated with the server system 200. It is noted that the stored card-linked biometric information 224 indicates at least one specific biometric template of the cardholder 104 linked with the payment card.
[00117] At step 520, the server system 200 generates and transmits a biometric request for card-specific biometric information associated with the payment card to the issuer application 124.
[00118] At step 522, upon receiving the biometric request, the issuer application 124 requests the cardholder 104 for at least one biometric template linked to the specific payment card for which the biometric request is received.
[00119] At step 524, the cardholder 104 provides at least one biometric template to the issuer application 124 via the sensors or sensor arrays of the electronic device 106 of the cardholder 104.
[00120] At step 526, the issuer application 124 transmits the card-specific biometric information including the at least one biometric template to the server system 200.
[00121] At step 528, the server system 200 performs an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information 224. In one scenario, the server system 200 may request the FIDO server 122 to perform the authentication process on behalf of the server system 200.
[00122] Upon unsuccessful authentication, the server system 200 declines the payment transaction, at step 530A. On the other hand, upon successful authentication, the server system 200, accesses a card-specific token from the issuer application 124 at step 530B.
[00123] At step 532, the server system 200 transmits a payment authentication request message including the card-specific token to a corresponding issuer server 118 associated with the issuer application 124.
[00124] At step 534, the issuer server 118 matches the card-specific token with a card-specific token received during the payment card registration (depicted in FIG. 4) from the server system 200.
[00125] Upon determining that the match is unsuccessful, the issuer server 118 may decline the payment transaction at step 536A. Otherwise, if the match is successful, the issuer server transmits a payment authorization message indicating a successful transaction to the server system 200 at step 536B.
[00126] At steps 538A and 538B, the server system 200 transmits a payment successful notification with the issuer application 124 and the merchant application 502 respectively. Upon receiving the payment successful notification, the merchant 108 may process the purchase as complete.
[00127] FIGS. 6A, 6B and 6C, collectively, represent a sequence flow diagram for authenticating a payment transaction using the existing 3DS payment architecture, in accordance with another embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the sequence flow diagram 600, references may be made to elements described in FIGS. 1-5. It is understood that the various steps of the sequence flow have already been explained with reference to FIGS. 1 and 5, therefore an explanation for the same is not repeated herein for the sake of brevity. Further, it should be noted that the various steps described to be performed by the issuer application 124 may be performed by the server system 200 associated with the issuer application 124 since in various embodiments, the server system 200 may facilitate the issuer application 124 to perform the various steps described herein. The sequence flow begins at step 604.
[00128] It is noted that steps 604-630B of FIGS. 6A-6C are identical to steps 504-530B of FIGS. 5A-5B. Therefore, the explanation for the same is not repeated again for the sake of brevity.
[00129] At step 632, the server system 200 transmits the card-specific token to the merchant application 602. In an instance, the server system 200 may facilitate the issuer application 124 to transmit the card-specific token to the merchant application 602.
[00130] At step 634, the merchant application 602 transmits the received card-specific token to an Access Control Server (ACS) 644.
[00131] At step 636, the ACS 644 fetches the card-specific token received during the payment card registration by the issuer server 118 from the issuer server 118.
[00132] At step 638, the ACS 644 matches the card-specific token with a card-specific token received during the payment card registration (depicted in FIG. 4) from the server system 200.
[00133] Upon determining that the match is unsuccessful, the ACS 644 may decline the payment transaction at step 640A. Otherwise, if the match is successful, the ACS transmits a payment authorization message indicating a successful transaction to the server system 200 and the issuer server 118 at steps 640B and 640C.
[00134] At step 642A and 642B, the server system 200 transmits a payment successful notification with the issuer application 124 and the merchant application 602. Upon receiving the payment successful notification, the merchant 108 may process the purchase as complete.
[00135] FIGS. 7A-7D, collectively, represent various exemplary Graphical User Interfaces (GUIs) 700, 710, 720, 730 that are implemented on an electronic device such as electronic device 106 for generating a card-specific token, in accordance with various embodiments of the present disclosure. The GUI 700 includes an interface that is shown to a cardholder, such as the cardholder 104, on their electronic device 106, upon opening an issuer application 124 associated with an issuing bank (such as ABC BANK). As depicted, the GUI 700 may show various options to the cardholder 104 such as ‘REGISTER DEVICE BIOMETRICS’, ‘REGISTERED DEVICES’, ‘TRANSFER FUNDS’, ‘LINKED CARDS’, ‘ENABLE FRICTIONLESS AUTHENTICATION’, and so on. To enable a frictionless authentication process, the cardholder 104 may select the ‘ENABLE FRICTIONLESS AUTHENTICATION’ option which redirects the cardholder 104 to GUI 710. As depicted in GUI 710, the cardholder 104 may select a payment card from the displayed one or more payment cards. In this instance, the cardholder 104 may select a payment card from the ‘CREDIT CARD 1’, ‘CREDIT CARD 2’, and ‘DEBIT CARD 1’. Upon selecting the desired payment card, the cardholder 104 is redirected to GUI 720 which provides the cardholder 104 various options to configure the frictionless authentication process related to the selected payment card. For instance, the configuration options may include ‘DISABLE FRICTIONLESS TRANSACTIONS’, ‘GENERATE CARD-SPECIFIC TOKEN’, ‘CARD-SPECIFIC TOKEN SETTINGS’. As may be understood the cardholder 104 may select these options to configure the frictionless authentication process for the selected payment card. In an implementation, if the cardholder 104 selects the option of generating the card-specific token, then either a fresh or a new card-specific token is generated as shown in GUI 730. It is noted that upon generation of the card-specific token, the same is stored by the issuer application 124 on the electronic device 106. For instance, the card-specific token may be stored in the secure element of the electronic device 106 or a memory associated with the electronic device 106.
[00136] FIG. 8 illustrates a process flow diagram depicting a method 800 for facilitating an authentication of a cardholder 104, in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 800 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 800, and combinations of operations in the method 800 may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 800. The process flow starts at operation 802.
[00137] At 802, the method 800 includes receiving, by a server system 200, a user input for a payment transaction initiated by a cardholder104 with a merchant 108 from an issuer application 124 installed on the electronic device 106 associated with the cardholder 104. Herein, the user input indicates a payment card to be used for performing the payment transaction.
[00138] At 804, the method 800 includes accessing, by the server system 200, stored card-linked biometric information 224 of the cardholder 104 from a database 204 associated with the server system 200, the stored card-linked biometric information 224 indicating at least one specific biometric template of the cardholder 104 linked with the payment card.
[00139] At 806, the method 800 includes generating and transmitting, by the server system 200, a biometric request for card-specific biometric information associated with the payment card to the issuer application 124.
[00140] At 808, the method 800 includes upon receiving the card-specific biometric information, performing, by the server system 200, an authentication of the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information 224.
[00141] At 810, the method 800 includes upon successful authentication, facilitating, by the server system 200, transmission of a payment authentication request message to a corresponding issuer server 118 associated with the issuer application 124. In an implementation, the payment authentication request message includes a card-specific token, wherein the card-specific token is accessed from the issuer application 124 by the server system.
[00142] At 812, the method 800 includes upon successful authentication by the corresponding issuer server, receiving and transmitting, by the server system 200, a payment authorization message indicating a successful transaction to an acquirer server 120 associated with the merchant 108.
[00143] FIG. 9 shows a simplified block diagram of an electronic device 900 capable of implementing the various embodiments of the present disclosure. The electronic device 900 may be an example of the electronic device 106 shown in FIG.1. It should be understood that the electronic device 900 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with the electronic device 900 may be optional and thus in an example embodiment may include more, less, or different components than those described in connection with the example embodiment of the FIG. 9. As such, among other examples, the electronic device 900 could be any of an electronic device or may be embodied in any of the electronic devices, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00144] The illustrated electronic device 900 includes a controller or a processor 902 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 904 controls the allocation and usage of the components of the electronic device 900 and provides support for one or more programs such as a location tracking application that implements one or more of the innovative features described herein. The applications 906 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications such as USSD messaging or SMS messaging or SIM Tool Kit (STK) application) or any other computing application.
[00145] The illustrated electronic device 900 includes one or more memory components, for example, a non-removable memory 908 and/or a removable memory 910. The non-removable memory 908 and/or the removable memory 910 may be collectively known as storage device/module in an embodiment. The non-removable memory 908 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 910 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 904. The electronic device 900 may further include a user identity module (UIM) 912. The UIM 912 may be a memory device having a processor 902 built in. The UIM 912 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 912 typically stores information elements related to a mobile subscriber. The UIM 912 in the form of the SIM card is well known in Global System for Mobile (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA9000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00146] The electronic device 900 can support one or more input devices 920 and one or more output devices 930. Examples of the input devices 920 may include, but are not limited to, a touch screen / a display screen 922 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 924 (e.g., capable of capturing voice input), a camera module 926 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 928. Examples of the output devices 930 may include, but are not limited to, a speaker 932 and a display 934. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 922 and the display 934 can be combined into a single input/output device.
[00147] A wireless modem 940 can be coupled to one or more antennas (not shown in the FIG. 9) and can support two-way communications between the processor 902 and external devices, as is well understood in the art. The wireless modem 940 is shown generically and can include, for example, a cellular modem 942 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 944 for communicating at short range with an external Bluetooth-equipped device, or a local wireless data network or router, and/or a Bluetooth-compatible modem 946. The wireless modem 940 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the electronic device 900 and a public switched telephone network (PSTN).
[00148] The electronic device 900 can further include one or more input/output ports 950, a power supply 952, one or more sensors 954 for example, a fingerprint sensor, a heartbeat sensor, a face scanning sensor, a microphone, an accelerometer, a gyroscope, a compass, a global positioning system sensor (for providing location details) or an infrared proximity sensor for detecting the orientation or motion of the electronic device 900, a transceiver 956 (for wirelessly transmitting analog or digital signals) and/or a physical connector 960, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00149] The disclosed method with reference to FIGS. 2-8, or one or more operations of the server system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., Dynamic Random Access Memory (DRAM) or Static Random Access Memory (SRAM)), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such a suitable communication means include, for example, the Internet, the World Wide Web (WWW), an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including Radio Frequency (RF), microwave, and infrared communications), electronic communications, or other such communication means.
[00150] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, Complementary Metal Oxide Semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, Application Specific Integrated Circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00151] Particularly, the server system 200 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor 902 or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor 902 or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media. Non-transitory computer-readable media includes any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), Compact Disc Read-Only Memory (CD-ROM), Compact Disc Recordable (CD-R), Compact Disc Rewritable (CD-R/W ), Digital Versatile Disc (DVD ), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, Random Access Memory (RAM ), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00152] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00153] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A computer-implemented method, comprising:
receiving, by a server system, a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on an electronic device associated with the cardholder, the user input indicating a payment card to be used for performing the payment transaction;
accessing, by the server system, stored card-linked biometric information of the cardholder from a database associated with the server system, the stored card-linked biometric information indicating at least one specific biometric template of the cardholder linked with the payment card;
generating and transmitting, by the server system, a biometric request for card-specific biometric information associated with the payment card to the issuer application;
upon receiving the card-specific biometric information, performing, by the server system, an authentication of cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information;
upon successful authentication, facilitating, by the server system, transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application, the payment authentication request message comprising a card-specific token, wherein the card-specific token is accessed from the issuer application by the server system; and
upon successful authentication by the corresponding issuer server, receiving and transmitting, by the server system, a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.

2. The computer-implemented method as claimed in claim 1, wherein performing the authentication of the cardholder comprises:
determining, by the server system, at least one provided biometric template based, at least in part, on the card-specific biometric information;
determining, by the server system, the cardholder identity based, at least in part, on comparing the at least one specific biometric template with the at least one provided biometric template; and
performing, by the server system, one of:
determining that the authentication of the cardholder identity is successful based, at least in part, on a successful comparison, and
determining that the authentication of the cardholder identity is unsuccessful based, at least in part, on an unsuccessful comparison.

3. The computer-implemented method as claimed in claim 2, wherein determining the cardholder identity comprises:
requesting, by the server system, a Fast Identity Online (FIDO) server to authenticate the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information, wherein the FIDO server is configured to compare the card-specific biometric information with the stored card-linked biometric information to authenticate the cardholder identity.

4. The computer-implemented method as claimed in claim 1, wherein receiving the user input for the payment transaction comprises:
receiving, by the server system, a selection of the issuer application from one or more issuer applications on a merchant application associated with the merchant by the cardholder from the merchant application installed on the electronic device, wherein the one or more issuer applications are installed on the electronic device and each issuer application is associated with the corresponding issuer server;
facilitating, by the server system, a display of a first GUI on the issuer application, the first GUI being configured to prompt the cardholder to select the payment card from one or more payment cards for performing the payment transaction, wherein the one or more payment cards are eligible for a frictionless payment transaction; and
receiving, by the server system, a selection of the payment card from the issuer application.

5. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a frictionless payment enablement request for the payment card from the issuer application from one or more issuer applications installed on the electronic device;
receiving, by the server system, a new card-specific biometric information by the cardholder corresponding to the payment card on the issuer application, the new card-specific information being received in response to a selection of an option corresponding to the new card-specific biometric information from one or more biometric information options by the cardholder; and
assigning, by the server system, the new card-specific biometric information to the payment card.

6. The computer-implemented method as claimed in claim 5, further comprising:
upon assigning the new card-specific biometric information to the payment card, generating, by the server system, a card-specific token, wherein, the card-specific token is generated based, at least in part, on the new card-specific biometric information and the payment card;
storing, by the server system, the new card-specific biometric information assigned to the payment card as stored card-linked biometric information in the database;
facilitating, by the server system, the issuer application to store the card-specific token in the electronic device; and
transmitting, by the server system, the card-specific token to the corresponding issuer server of the issuer application.

7. The computer-implemented method as claimed in claim 1, wherein the at least one specific biometric template associated with each payment card of the one or more payment cards is unique.

8. The computer-implemented method as claimed in claim 1, further comprising:
upon unsuccessful authentication of the cardholder identity, generating and transmitting, by the server system, a payment failure message to the issuer application.

9. The computer-implemented method as claimed in claim 1, further comprising:
upon unsuccessful authentication corresponding issuer server, receiving and transmitting, by the server system, the payment authorization message indicating an unsuccessful transaction to the acquirer server.

10. The computer-implemented method as claimed in claim 1, further comprising:
facilitating, by the server system, a display of a second GUI on the issuer application, the second GUI being configured to prompt the cardholder to configure one or more settings associated with the payment card, wherein the one or more settings comprises at least a token expiration time, wherein the token expiration time indicates the time period for which the card-specific token is valid.

11. The computer-implemented method as claimed in claim 10, wherein the one or more settings associated with the payment card further comprises a transaction amount limit and a transaction mode, wherein the transaction amount limit indicates the maximum amount for a payment transaction and the transaction mode is the mode for the payment transaction.

12. The computer-implemented method as claimed in claim 1, wherein facilitating the transmission of the payment authentication request message further comprises:
transmitting, by the server system, the card-specific token to a merchant application associated with the merchant installed on the electronic device, wherein the merchant application is configured to generate and transmit the payment authentication request message to the corresponding issuer server.

13. The computer-implemented method as claimed in claim 1, wherein the server system is one of a payment server and the issuer server.

14. A server system, comprising:
a memory configured to store instructions;
a communication interface; and
a processor in communication with the memory and the communication interface, the processor configured to execute the instructions stored in the memory and thereby cause the server system to perform, at least in part, to:
receive a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on an electronic device associated with the cardholder, the user input indicating a payment card to be used for performing the payment transaction;
access stored card-linked biometric information of the cardholder from a database associated with the server system, the stored card-linked biometric information indicating at least one specific biometric template of the cardholder linked with the payment card;
generate and transmit a biometric request for card-specific biometric information associated with the payment card to the issuer application;
upon receiving the card-specific biometric information, perform an authentication of cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information;
upon successful authentication, facilitate transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application, the payment authentication request message comprising a card-specific token, wherein the card-specific token is accessed from the issuer application by the server system; and
upon successful authentication by the corresponding issuer server, receive and transmit a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.

15. The server system as claimed in claim 14, wherein to perform the authentication of the cardholder, the server system is further caused, at least in part, to:
determine at least one provided biometric template based, at least in part, on the card-specific biometric information;
determine the cardholder identity based, at least in part, on comparing the at least one specific biometric template with the at least one provided biometric template; and
perform one of:
determining that the authentication of the cardholder identity is successful based, at least in part, on a successful comparison, and
determining that the authentication of the cardholder identity is unsuccessful based, at least in part, on an unsuccessful comparison.

16. The server system as claimed in claim 15, wherein to determine the cardholder identi-ty, the server system is further caused, at least in part, to:
request a Fast Identity Online (FIDO) server to authenticate the cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information, wherein the FIDO server is configured to compare the card-specific biometric information with the stored card-linked biometric information to authenticate the cardholder identity.

17. The server system as claimed in claim 14, wherein to receive the user input for the payment transaction, the server system is further caused, at least in part, to:
receive a selection of the issuer application from one or more issuer applications on a merchant application associated with the merchant by the cardholder from the merchant application installed on the electronic device, wherein the one or more issuer applications are installed on the electronic device and each issuer application is associated with the corresponding issuer server;
facilitate a display of a first GUI on the issuer application, the first GUI being configured to prompt the cardholder to select the payment card from one or more payment cards for performing the payment transaction, wherein the one or more payment cards are eligible for a frictionless payment transaction; and
receive a selection of the payment card from the issuer application.

18. The server system as claimed in claim 14, wherein the server system is further caused, at least in part, to:
receive a frictionless payment enablement request for the payment card from the issuer application from one or more issuer applications installed on the electronic device;
receive a new card-specific biometric information by the cardholder corresponding to the payment card on the issuer application, the new card-specific information being received in response to a selection of an option corresponding to the new card-specific biometric information from one or more biometric information options by the cardholder; and
assign the new card-specific biometric information to the payment card.

19. The server system as claimed in claim 18, wherein the server system is further caused, at least in part, to:
upon assigning the new card-specific biometric information to the payment card, generate a card-specific token, wherein, the card-specific token is generated based, at least in part, on the new card-specific biometric information and the payment card;
store the new card-specific biometric information assigned to the payment card as stored card-linked biometric information in the database;
facilitate the issuer application to store the card-specific token in the electronic device; and
transmit the card-specific token to the corresponding issuer server of the issuer application.

20. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method comprising:
receiving a user input for a payment transaction initiated by a cardholder with a merchant from an issuer application installed on an electronic device associated with the cardholder, the user input indicating a payment card to be used for performing the payment transaction;
accessing stored card-linked biometric information of the cardholder from a database associated with the server system, the stored card-linked biometric information indicating at least one specific biometric template of the cardholder linked with the payment card;
generating and transmitting a biometric request for card-specific biometric information associated with the payment card to the issuer application;
upon receiving the card-specific biometric information, performing an authentication of cardholder identity based, at least in part, on the card-specific biometric information and the stored card-linked biometric information;
upon successful authentication, facilitating transmission of a payment authentication request message to a corresponding issuer server associated with the issuer application, the payment authentication request message comprising a card-specific token, wherein the card-specific token is accessed from the issuer application by the server system; and
upon successful authentication by the corresponding issuer server, receiving and transmitting a payment authorization message indicating a successful transaction to an acquirer server associated with the merchant.