Description:TECHNICAL FIELD
[001] The present disclosure relates to methods and systems for authenticating a payment transaction and, more particularly to, electronic methods and systems for authenticating a payment transaction based on multi-factor authentication.
BACKGROUND
[002] Nowadays, with the increase in digital transactions, payment cards such as credit cards, debit cards, and the like have become an essential part of the payment ecosystem. Payment card based electronic payment transactions are popular among both cardholders and merchants due to various aspects associated with such transactions. These various aspects include ease of use, security, fraud protection, automatic currency conversion, and the like. In other words, payment card-based payment transactions offer multiple advantages over conventional cash payments, such as cardholders need not carry any physical denominations of the currency for making the transactions. Yet another advantage of payment card-based payment transactions is that the cardholder is not bound to calculate the transaction amount based on currency conversions if the transaction is executed in another country/ foreign website. As may be understood, as the number of daily payment card based transactions has increased throughout the world, it has become crucial to curb fraudulent behavior such as identity theft of the cardholder to protect the cardholder from fraud. To that end, various techniques have been developed to authenticate the identity of the cardholder before a payment transaction is approved. One such technique is known as multi-factor authentication. In multi-factor authentication, the identity of the cardholder has to be authenticated based on multiple methods. One popular form of multi-factor authentication is known as Two-factor Authentication (2FA). It is noted that 2FA verifies the identity of the cardholder using at least authentication methods. For instance, a cardholder may be asked to provide his login credentials alongside a security question to authenticate their identity. Further, with the advent of smartphones, a One Time Password (OTP) based approach has become increasingly popular for performing the 2FA. More specifically, when the cardholder initiates a payment transaction using a payment card associated with a payment account of the cardholder, they are required to authenticate the transaction using an OTP security code. Specifically, an OTP code is received on a smartphone once the transaction is initiated and the cardholder is required to enter the received OTP code into a payment gateway to authenticate their identity. Once, the cardholder’s identity is authenticated, the payment transaction may be completed using the account of the selected payment card. Generally, the OTP code is valid for a predefined time period and if the same is entered into the payment gateway after the predefined time period has elapsed, the authentication process may be directly terminated. As may be understood, the OTP code can be generated dynamically for each payment transaction by an issuing bank associated with the cardholder. Further, the OTP code may be delivered to the cardholder using communication protocols such as Short Message Service (SMS). An example of an OTP code based 2FA method is three domain secure or 3DS that is employed by various issuers for authenticating cardholder’s identity during Card Not Present (CNP) transactions using OTP codes.
[003] Despite the popularity of OTP code based identity authentication, there are a few shortcomings in the existing OTP-based payment transactions. Conventionally, upon receiving the OTP code, the cardholder has to manually fetch the OTP code and enter the same in the payment gateway which is a cumbersome process. In some scenarios, although the OTP code may be picked automatically upon their receipt, as the delivery of the OTP security code is done through SMS, which is generally managed by a network provider, there may be a lag or wait time on the network provider’s side while delivering the OTP code to the cardholder. In such a scenario, the cardholder might have to wait for the OTP code to be delivered, during which the predefined time period might elapse which in turn might lead to an authentication failure. Additionally, after the predefined time period or the transaction time window ends, the transaction is automatically declined and a new transaction needs to be initiated by the cardholder or a new OTP code has to be requested. In such a scenario, the cardholder may not wish to continue with their once-declined transaction and might quit the purchasing process or may choose another payment card associated with the cardholder’s account to initiate the transaction. This might bring associated loss for the issuing bank and the cardholder as the cardholder might not receive the cashback/rewards associated with the initial payment card.
[004] For example, if there exists a latency in the delivery of the OTP code associated with a transaction using payment card A, the cardholder may choose another payment card B for initiating the transaction. In such a scenario, the cardholder will however complete the transaction associated with his purchase using the payment card B but might lose any benefits associated with payment card A such as receiving the cashback if the transaction was done using the payment card A.
[005] Hence, there exists a technological need for providing methods and systems for authenticating a payment card-based payment transaction by authenticating the identity of the cardholder using 2FA without the OTP code.
SUMMARY
[006] Various embodiments of the present disclosure provide methods and systems for authenticating a payment card-based payment transaction using 2FA without an OTP code.
[007] In an embodiment, a computer-implemented method is disclosed. The method includes receiving, by a server system, a payment authorization request message related to a cardholder initiated by a merchant with a merchant from an electronic device associated with the cardholder. The payment authorization request message includes a first unique key. In addition, the method includes receiving, by the server system, a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder. The method further includes facilitating, by the server system, a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder. Furthermore, the method includes receiving, by the server system, a cardholder response message corresponding to the payment transaction from one or more active payment transactions displayed on the application. The cardholder response message includes at least a second unique key and an approval flag. Moreover, upon determining that the cardholder response message includes the approval flag, validating, by the server system, an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Furthermore, upon successful validation, generating and transmitting, by the server system, a payment authentication request message to the issuer server. The payment authentication request message includes the OTP. Moreover, upon receiving a payment authentication response message which includes an authentication successful flag from the issuer server, generating and transmitting, by the server system, a payment approval message to an acquirer server associated with the merchant.
[008] 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 payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder. The payment authorization request message includes a first unique key. The server system is further caused to receive a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder. The server system is further caused to facilitate display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated. Further, the server system is caused to receive a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application. Herein, the cardholder response message includes at least a second unique key and an approval flag. Upon determining that the cardholder response message includes the approval flag the server system is further caused to validate the identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Moreover, upon successful validation, the server system is further caused to generate and transmit a payment authentication request message to the issuer server. Herein, the payment authentication request message includes the OTP. Furthermore, upon receiving a payment authentication response message including an authentication successful flag from the issuer server, generate and transmit a payment approval message to an acquirer server associated with the merchant.
[009] 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 payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder, the payment authorization request message includes a first unique key. The method further includes receiving a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder. Further, the method includes facilitating a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder. The method further includes receiving a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application. Herein, the cardholder response message includes at least a second unique key and an approval flag. Upon determining that the cardholder response message includes the approval flag the method further includes, validating an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Upon successful validation, the method includes generating and transmitting a payment authentication request message to the issuer server. The payment authentication request message includes the OTP. In response to receiving a payment authentication response message including an authentication successful flag from the issuer server, generating and transmitting a payment approval message to an acquirer server associated with the merchant.
[0010] In yet another embodiment, a computer-implemented method is disclosed. The method includes receiving, by a directory server, a payment authorization request message related to a cardholder initiated by a merchant with a merchant from an electronic device associated with the cardholder. The payment authorization request message includes a first unique key. In addition, the method includes receiving, by the directory server, a One Time Password (OTP) for the payment transaction from an access control server associated with the cardholder. The method further includes facilitating, by the directory server, a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder. Furthermore, the method includes receiving, by the directory server, a cardholder response message corresponding to the payment transaction from one or more active payment transactions displayed on the application. The cardholder response message includes at least a second unique key and an approval flag. Moreover, upon determining that the cardholder response message includes the approval flag, validating, by the directory server, an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Furthermore, upon successful validation, the method includes generating and transmitting, by the directory server, a payment authentication request message to the access control server. The payment authentication request message includes the OTP. Moreover, upon receiving a payment authentication response message which includes an authentication successful flag from the access control server, generating and transmitting, by the directory server, a payment approval message to a merchant plug-in associated with the merchant.
[0011] 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
[0012] 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:
[0013] FIG. 1 illustrates an example representation of an environment related to at least some embodiments of the present disclosure;
[0014] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0015] FIG. 3A and 3B represent a sequence flow diagram for authenticating a payment transaction, in accordance with an embodiment of the present disclosure;
[0016] FIG. 4 represents an example Graphical User Interface (GUI) implemented on an application installed on an electronic device for displaying the active transactions, in accordance with an embodiment of the present disclosure;
[0017] FIG. 5 represents a sequence flow diagram for registering a payment card on the application, in accordance with an embodiment of the present disclosure;
[0018] FIG. 6 illustrates a process flow diagram depicting a method for authenticating the payment transaction, in accordance with an embodiment of the present disclosure;
[0019] FIG. 7 illustrates a process flow diagram depicting a method for authenticating the payment transaction in a 3DS system;
[0020] FIG. 8 is a simplified block diagram of an electronic device, in accordance with an embodiment of the present disclosure.
[0021] FIG. 9 illustrates a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0022] FIG. 10 illustrates a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure; and
[0023] FIG. 11 illustrates a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
[0024] 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
[0025] 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.
[0026] 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 is 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.
[0027] 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.
[0028] 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 system called “issuer server” throughout the description.
[0029] Further, the term "acquirer", is an organization that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in question. Typically, the acquirer has an agreement with merchants, wherein the acquirer receives authorization requests for purchase transactions from the merchants and routes the authorization requests to the issuers of the payment cards being used for the purchase transactions. The terms "acquirer", "acquiring bank", "acquiring bank" or "acquirer bank" will be used interchangeably herein. Further, one or more server systems associated with the acquirer are referred to as "acquirer server" to carry out their functions.
[0030] 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.
[0031] 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®.
[0032] 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 card 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] The term "merchant application", used throughout the description, may be associated with a particular merchant or may be associated with a number of different merchants and may be capable of identifying a particular merchant (or multiple merchants) that are parties to a transaction. 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 merchant application. Further, the merchant application may also include a general-purpose browser or other software-designed application to interact with multiple merchant server computers as long as the browser is configured to identify the merchant server computer and process a remote transaction. The merchant application may be installed on the general-purpose memory of a mobile device.
[0037] The term "payment service provider", may include an entity that contracts with an acquirer for the purpose of providing acceptance to a sponsored merchant, the sponsored merchant then contracts with a payment service provider to obtain payment services.
OVERVIEW
[0038] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for authenticating a payment transaction.
[0039] In an embodiment, a server system is configured to receive a payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder. The payment authorization request message may include one or more transaction attributes related to the payment transaction. In various examples, one or more transaction attributes may include a transaction amount, a transaction date, a transaction time, a cardholder identifier (ID), an electronic device ID, merchant information, and authentication information. In yet some other examples, the one or more transaction attributes may include information related to the cardholder indicating card-related data, an account number of the cardholder, a Personal Account Number (PAN) of the cardholder, an IMEI (International Mobile Equipment Identity) number associated with the electronic device of the cardholder, an email-id of the cardholder, amount of the payment transaction, IP address or WiFi MAC address of the electronic device, geo-location of the electronic device, etc., among other transaction related attributes. Herein, the server system may be a payment server or a directory server
[0040] In another embodiment, the server system is configured to generate a first unique key associated with the cardholder based, at least in part, on the one or more transaction attributes. In another embodiment, the server system is configured to receive a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder. Herein, the issuer server may be an access control server.
[0041] In another embodiment, the server system is configured to facilitate a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder. In particular, for facilitating the display, the server system is configured to generate and transmit an active transaction request to the issuer server, then receive information related to the one or more active payment transactions from the issuer server. Further, the server system transmits the information related to the one or more active payment transactions to the application installed on the electronic device. It is understood that upon receiving the information related to the one or more active payment transactions, the application is configured to generate a graphical user interface (GUI) indicating the one or more active transactions.
[0042] In another embodiment, the server system is configured to receive a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application. In one example, the cardholder response message may include at least a second unique key and one of an approval flag and decline flag.
[0043] In another embodiment, upon determining that the cardholder response message includes the approval flag, the server system is configured to validate the identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Alternatively, upon determining that the cardholder response message includes the decline flag, the server system is configured to generate and transmit a payment declined message to at least one of the issuer server or the acquirer server.
[0044] In another embodiment, upon successful validation of the identity of the cardholder, the server system is configured to generate and transmit a payment authentication request message to the issuer server. In one example, the payment authentication request message may include the OTP. Alternatively, upon unsuccessful validation of the identity of the cardholder, the server system is configured to generate and transmit a payment authentication failure message to the issuer server.
[0045] In another embodiment, upon receiving a payment authentication response message including an authentication successful flag from the issuer server, the server system is configured to generate and transmit a payment approval message to an acquirer server associated with the merchant. Alternatively, upon receiving the payment authentication response message including an authentication unsuccessful flag from the issuer server, the server system is configured to generate and transmit a payment decline message to the acquirer server associated with the merchant. Herein, the acquirer server may be replaced by a merchant plug-in associated with the merchant.
[0046] In another embodiment, the server system is configured to receive a cardholder login request message from the application. In various non-limiting examples, the cardholder login request message may include a cardholder identifier (ID), an electronic device ID, a cardholder password, and the like. Then, the server system is configured to determine if the cardholder ID has been registered with another electronic device based, at least in part, on the cardholder ID and the electronic device ID. Further, upon determining that the cardholder ID has not been registered with another electronic device, the server system is configured to perform an authentication of the cardholder identity based, at least in part, on the cardholder ID and the cardholder password. Alternatively, upon determining that the cardholder ID has been registered with another electronic device, the server system is configured to generate and transmit a login unsuccessful message to the application. In this case, the server system is configured to facilitate a display of an option for deregistering another electronic device on the application, and upon determining that the cardholder has selected the option for deregistering another electronic device, authenticate and register the electronic device with the cardholder ID. Then, upon successful authentication, the server system is configured to generate and transmit a login successful message to the application.
[0047] Various embodiments of the present disclosure provide multiple advantages and technical effects while addressing technical problems such as how to authenticate payment card based payment transactions without the need to manually enter the OTP code by the cardholder. Various embodiments address this technical problem by the present disclosure by allowing the cardholder to directly approve or decline any of the one or more active payment transactions on an application installed on the electronic device of the cardholder. To that end, the need to enter the OTP is eliminated thus, making it easier for the cardholder to approve or decline any payment transaction within the predefined time period. It is noted that the functionality provided by the present disclosure can be implemented on the existing payment network, without making significant changes to the existing payment network architecture as well
[0048] Various embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 11.
[0049] 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, authenticating a payment card-based payment transaction using 2FA without the OTP code. 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 issuer server 118, an acquirer server 120, a payment network 110 including a payment server 112, and a database 114 (such as a transaction database), 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.
[0050] 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, and the payment server 112 may communicate.
[0051] 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 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 to initiate and complete a payment transaction using a bank account at the issuing bank.
[0052] In one scenario, the cardholder 104 may use their corresponding payment accounts to conduct payment transactions with the merchants 108. In an example, the cardholder 104 may enter payment account 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. Generally, “payment transaction” refers to an agreement that is carried out between a buyer and a seller to exchange assets as 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.
[0053] 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, or any third-party payment application. The user device may refer to any electronic device such as, but not limited to, personal computers (PCs), tablet devices, Personal Digital Assistants (PDAs), voice-activated assistants, Virtual Reality (VR) devices, smartphones, and laptops.
[0054] 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).
[0055] 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 such as cardholder 104 visit for performing a financial transaction in exchange for any goods and/or services or any financial transactions.
[0056] 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.
[0057] In an embodiment, the database 114 is a transaction database and is communicatively coupled to the server system 102. In one embodiment, the database 114 may include multifarious data, for example, social media data, Know Your Customer (KYC) data, payment data, trade data, employee data, Anti Money Laundering (AML) data, market abuse data, Foreign Account Tax Compliance Act (FATCA) data, and fraudulent payment transaction data. In particular, the database 114 provides a storage location for data and/or metadata associated with the payment cards of the cardholder.
[0058] In an example, the database 114 stores merchant profile data associated with the merchant 108. In one embodiment, the merchant profile data may include data such as the name of the merchant 108, transaction information of the cardholder 104 at a particular merchant (e.g., the merchant 108), information of fraudulent or non-fraudulent transactions performed at the merchant 108, various terminals (e.g., point-of-sale (POS) devices, automated teller machines (ATMs), etc.) associated with each merchant 108, and the like.
[0059] In yet another example, the database 114 stores real-time transaction data of the cardholder 104. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, transaction date, transaction time, cardholder identifier (ID), electronic device ID, merchant information, authentication information, transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past ‘x’ number of days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction.
[0060] 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.
[0061] In one embodiment, the server system 102 is configured to perform one or more of the operations described herein. The server system 102 is configured to store information regarding all the payment cards associated with the cardholder (e.g., the cardholder 104) in the database such as the database 114.
[0062] In an embodiment, the server system 102 is configured to receive a payment authorization request message related to a payment transaction initiated by the cardholder 104 with the merchant 108 from the electronic device 106 associated with the cardholder 104. In a non-limiting example, the payment transaction message may include one or more transaction attributes related to the payment transaction. Then, the server system 102 is configured to generate a first unique key associated with the cardholder based, at least in part, on one or more transaction attributes. As may be understood, when the payment transaction is initiated, an OTP will be triggered by the issuer server 118 associated with the cardholder 104. This OTP may be shared with the server system 102 as well. In other words, the server system 102 is configured to receive the OTP for the payment transaction from the issuer server 118 associated with the cardholder 104. At the same time or near the same time, the server system 102 may be configured to facilitate a display of one or more active payment transactions corresponding to the cardholder 104 on an application such as a payment application 122 (hereinafter referred to interchangeably as ‘application 122’) installed on the electronic device 106 associated with the cardholder 104. In one embodiment, the server system 102 is configured to run an instance of the payment application 122. In one embodiment, the cardholder 104 may utilize the payment application 122 to monitor the one or more active payment transactions associated with the cardholder’s payment cards and payment accounts. In another embodiment, the payment application 122 is an application/tool resting at the server system 102. In another embodiment, the payment application 122 is configured to facilitate the cardholder 104 to approve or decline any of the one or more active payment transactions.
[0063] In an embodiment, the payment application 122 may include one or more graphical user interfaces for facilitating the cardholder 104 to perform approve or decline an active or ongoing payment transaction with the merchant 108. 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 payment application 122 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 payment application 122. In one implementation, the payment application 122 utilizes communication APIs to communicate back and forth with the electronic device 106. In an example, the payment application 122 utilizes various distribution methods for sharing one or more messages, requests, or responses with the cardholder 104. 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 payment application 122 utilizes communication APIs to share the results of their various operations (described later on) with the server system 102 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.).
[0064] In some scenarios, the payment application 122 may include a mobile application or “app”. In various non-limiting examples, the payment application 122 may be installed and accessed on the electronic device 106. 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 payment application 122 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 that supports communication with the server system 102, the issuer server 118, the payment server 112 and the like. For instance, a third-party application may use or utilize the API associated with the payment application 122 of the server system 102 or an API associated with the instance of the payment application 122 to implement the functionality of the payment application 122 within the third-party application. In an implementation, the payment application 122 is managed, hosted, or executed by the server system 102 or the issuer server 118. In another implementation, the payment application 122 is managed, hosted, or executed by a communication device (not shown in figures) associated with the server system 102 or the issuer server 118.
[0065] In another embodiment, the server system 102 is configured to receive a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the payment application 122. In a non-limiting example, the cardholder response message may include at least a second key and one of an approval flag or decline flag. Upon determining that the cardholder response message includes the approval flag, the server system 102 is configured to validate the identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key. Otherwise, if there is a decline flag, the transaction may be declined.
[0066] Upon successful validation, the server system 102 is configured to generate and transmit a payment authentication request message to the issuer server 118. In an instance, the payment authentication request message may include the OTP. On the other hand, upon unsuccessful validation, the payment transaction may be declined.
[0067] In response to the payment authentication request message, a payment authentication response message is received from the issuer server 118. Upon determining that the payment authentication response message includes an authentication successful flag, the server system 102 is configured to generate and transmit a payment approval message to the acquirer server 120.
[0068] 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.).
[0069] 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.
[0070] 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. It is noted that the server system 200 is an example of the server system 102 of FIG. 1. In one embodiment, the server system 200 is a part of the payment network 110 or integrated within the payment server 112. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
[0071] 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.
[0072] In some embodiments, the database 204 is integrated into 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, i.e., a cardholder Identifier (ID) and the cardholder password associated with the cardholders such as the cardholder 104 in FIG. 1. The database 204 is an example of the database 114 of FIG. 1.
[0073] The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for authenticating a payment card-based payment transaction using 2FA without an OTP code. 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.
[0074] 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.
[0075] 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).
[0076] 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.
[0077] In one implementation, the processor 206 includes a user login module 218, an authorization module 220, a Graphical User Interface (GUI) generation module 222, an authentication module 224, and the like. It should be noted that the components, described herein, such as the user login module 218, the authorization module 220, the GUI generation module 222, and the authentication module 224 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.
[0078] The user login module 218 includes suitable logic and/or interfaces for facilitating a login process for the cardholder 104 on the application such as payment application 122 installed on the electronic device 106 of the cardholder 104. In particular, the login process may be initiated upon receiving a cardholder login request message from the application. In various non-limiting examples, the cardholder login request message may include a cardholder identifier (ID), electronic device ID, cardholder password, etc., among other suitable information for authenticating the identity of the cardholder 104. In other words, the cardholder login request message may include the account login credentials shared by the cardholder 104. Upon receiving these account login credentials, the user login module 218 may determine if the cardholder ID has been registered with another electronic device based at least in part on the cardholder ID and the electronic device ID. In other words, the user login module 218 checks if another electronic device has been registered using the same cardholder ID or not. This process may be done by comparing the cardholder ID with the electronic device ID of the registered electronic device in a registration dataset stored in the database 204. As may be understood, the registration dataset may be generated for a plurality of cardholders 104 that have registered on that payment application 122 by creating an account on the same. In a non-limiting scenario, the registration dataset may include information related to cardholder ID and the electronic device IDs corresponding to their registered electronic device.
[0079] Upon determining that the cardholder ID has been registered with another electronic device, the user login module 218 may generate and transmit a login unsuccessful message to the application. Additionally, the user login module 218 may facilitate a display of an option for deregistering another electronic device on the application. In other words, the selection of this option may lead to the cardholder 104 being logged off on another electronic device. If the cardholder 104 selects the option, then the user login module 218 may deregister that another electronic device from the cardholder ID and re-register the electronic device with the cardholder ID upon successful authentication.
[0080] On the other hand, upon determining that the cardholder ID has not been registered with another electronic device, the user login module 218 performs an authentication of the cardholder identity based, at least in part, on the cardholder ID and the cardholder password. Authentication of the cardholder identity may be performed by comparing the cardholder ID and the cardholder password with the stored account credentials corresponding to the cardholder ID in the database 204. If the authentication is successful, then the user login module 218 generates and transmits a login successful message to the application. Otherwise, the user login module 218 generates and transmits a login unsuccessful message to the application.
[0081] In a particular implementation within the 3DS system, an Access Control Server (ACS) may perform the authentication of the cardholder identity based, at least in part, on the cardholder ID and the cardholder password. In this implementation, the server system 200 may act as a Directory Server (DS) and might share the received credentials within the cardholder login request message to the ACS server for authentication. It is noted that in some implementations, ACS may be a server associated with the issuing bank or the issuer server 118. On the other hand, in an alternative implementation, the issuer server 118 may be an ACS server.
[0082] The authorization module 220 includes suitable logic and/or interfaces for a payment authorization request message related to a payment transaction initiated by the cardholder 104 with the merchant 108 from the electronic device 106 associated with the cardholder 104. As may be understood, the payment authorization message is received whenever the cardholder 104 performs a purchase transaction with any merchant. In a non-limiting example, the payment authorization request message may include at least one or more transaction attributes related to the payment transaction. In various non-limiting examples, the one or more transaction attributes related to the payment transaction may include at least one of a transaction amount, a transaction date, a transaction time, a cardholder identifier (ID), an electronic device ID, merchant information such as (merchant ID, merchant name, Merchant Classification Code (MCC), merchant industry, and the like), and authentication information (such as transaction-related credentials, Personal Identification Number (PIN), encrypted data required for authenticating the source of the transaction and the like). In another non-limiting example, the payment authorization message may further include at least one of information related to the cardholder indicating card-related data, the Personal Account Number (PAN) of the cardholder 104, an International Mobile Equipment Identity (IMEI) number associated with the electronic device, an email-id of the cardholder 104, IP address or WiFi MAC address of the electronic device, geo-location of the electronic device and the like.
[0083] In another embodiment, the authorization module 220 is configured to generate a first unique key (also referred to hereinafter interchangeably as ‘first unique code’) associated with the cardholder 104 based, at least in part, on one or more transaction attributes. In various non-limiting scenarios, a set of pre-defined rules may be used to generate the first unique key based on one or more transaction attributes. In other words, the set of pre-defined rules may indicate different methods for generating the first unique key by selecting some or all of one or more transaction attributes for the payment transaction. As may be understood, the set of pre-defined rules may be generated based on one or more internal policies of either the issuer or the payment processor. In an example, the set of pre-defined rules may be stored in the database 204
[0084] In an embodiment, the authorization module 220 is configured to forward or transfer the payment authorization request message to the issuer server such as the issuer server 118. In response, the issuer server 118 generates and transmits a One Time Password (OTP) corresponding to the transaction to the authentication module 224 of the server system 200. In some scenarios, the ACS is responsible for generating and transmitting the OTP for the payment transaction to the authentication module 224 of the server system 200. As may be understood, in accordance with the conventional process, the OTP may also be shared with the electronic device of the cardholder as well. To that end, in other words, the authorization module 220 is configured to receive the OTP for the payment transaction from the issuer server 118 associated with the cardholder 104 or the ACS associated with the issuer server 118.
[0085] At the same time or in near the same time, the authorization module 220 is also configured to request the GUI generation module 222 to generate a first GUI on the display screen associated with the electronic device 106 of the cardholder 104.
[0086] In an embodiment, the GUI generation module 222 includes suitable logic and/or interfaces for generating the first GUI in response to the request from the authorization module 220. In a non-limiting example, the first GUI may show one or more active payment transactions corresponding to the cardholder 104. Further, the GUI generation module 222 is configured to facilitate the display of the first GUI on the application installed on the electronic device 106 associated with the cardholder 104. As may be understood, to facilitate the display of the first GUI indicating the one or more active payment transactions corresponding to the cardholder 104 includes performing a plurality of operations through the authorization module 220. In a non-limiting example, the plurality of operations may include at first, generating and transmitting an active transaction request to the issuer server 118. Herein, the active transaction request is shared with the issuer server 118 for requesting information related to the one or more active payment transactions from the issuer server 118. In response to transmitting the active transaction request, the authorization module 220 is configured to receive the information related to the one or more active payment transactions from the issuer server 118. Then, this information related to the one or more active payment transactions may be used by the GUI generation module 222 to generate the first GUI. In other implementations, the payment application 122 installed on the electronic device 106 may be capable of generating the first GUI on its own. In such scenarios, the GUI generation module 222 can be configured to transmit the information related to the one or more active payment transactions to the application 122. Upon receiving the information related to the one or more active payment transactions, the payment application 122 is configured to generate the first GUI indicating the one or more active transactions to the cardholder 104.
[0087] Once the first GUI is rendered on the display of the electronic device 106, the cardholder 104 may perform a selection of the payment transaction that the cardholder 104 wishes to approve or decline. For instance, the first GUI may provide an ‘approve’ option and a ‘decline’ option for each payment transaction of the one or more active payment transactions that the cardholder 104 may select or click to either approve or decline the transaction. If the cardholder 104 selects the ‘approve’ option corresponding to the payment transaction from the one or more active payment transactions displayed on the application, then a cardholder response message including at least a second unique key and an approval flag is transmitted to the authentication module 224 of the server system 200. On the other hand, if the cardholder 104 selects the ‘decline’ option corresponding to the payment transaction from the one or more active payment transactions displayed on the application, then a cardholder 104 response message including at least a second unique key and a decline flag is transmitted to the authentication module 224 of the server system 200. It is noted that the second unique key is referred to hereinafter interchangeably as the second unique code. It is noted that the second unique key is generated by the payment application 122 using the same process followed by the server system 200 to generate the first unique key. To that end, the generation process of the second unique key is not explained again for the sake of brevity.
[0088] In an embodiment, the authentication module 224 includes suitable logic and/or interfaces for receiving the cardholder 104 response message from the payment application 122 installed on the electronic device 106.
[0089] Upon determining that the cardholder 104 response message includes the approval flag, the authentication module 224 is configured to validate the identity of the cardholder 104 based, at least in part, on comparing the first unique key and the second unique key. It is noted that if the source of the second unique key is genuine, then the second unique key should be the same as the first unique key generated by the authorization module 220. To that end, if the first unique key and the second unique key match then, the identity of the cardholder 104 can be validated. In other words, the validation will be successful upon determining that the first unique key and the second unique key match each other. On the other hand, if the first unique key and the second unique key don’t match then, the identity of the cardholder 104 cannot be validated. In other words, the validation will be unsuccessful upon determining that the first unique key and the second unique key don’t match each other. To that end, the validation of the identity of the cardholder 104 based, at least in part, on comparing the first unique key and the second unique key provides an alternative method of performing the 2FA of the cardholder 104.
[0090] In one scenario, upon successful validation of the identity of the cardholder, the authentication module 224 is configured to generate and transmit a payment authentication request message including the OTP to the issuer server 118. In another example, upon successful validation of the identity of the cardholder 104, the authentication module 224 is configured to generate and transmit the payment authentication request message including the OTP to the ACS. As may be understood, upon receiving the payment authentication request message, the issuer server 118 or the ACS may confirm or authenticate if the OTP included in the payment authentication request message is the same as the OTP transmitted to the electronic device 106 of the cardholder 104 or the server system 102. If the OTP is the same, a payment authentication response message including an authentication successful flag is sent to the authentication module 224 by the issuer server 118 or the ACS. Otherwise, if the OTP is not the same, a payment authentication response message including an authentication unsuccessful flag is sent to the authentication module 224 by the issuer server 118 or the ACS. In other words, even if the validation of the identity of the cardholder 104 is performed by comparing the first unique key and the second unique key, the end authentication of cardholder 104 by the issuer server 118 or ACS is still performed using the OTP. To that end, the embodiments of the present disclosure can be applied easily to the existing payment network 110 without adding complexity to the present architecture of the payment network 110. In an embodiment, upon receiving the payment authentication response message including the authentication successful flag by the issuer server 118 or the ACS, the authentication module 224 is configured to generate and transmit a payment approval message to the acquirer server 120 (or a Merchant Plug-in (MPI)) associated with the merchant 108. In an alternative embodiment, upon receiving the payment authentication response message including the authentication unsuccessful flag by the issuer server 118 or the ACS, the authentication module 224 is configured to generate and transmit a payment decline message to the acquirer server 120 (or a Merchant Plug-in (MPI)) associated with the merchant 108.
[0091] In an alternative scenario, upon unsuccessful validation of the identity of the cardholder 104, the authentication module 224 is configured to generate and transmit a payment authentication failure message to the issuer server 118. In another example, upon unsuccessful validation of the identity of the cardholder 104, the authentication module 224 is configured to generate and transmit the payment authentication failure message to the ACS.
[0092] Upon determining that the cardholder 104 response message includes the decline flag, the authentication module 224 is configured to generate and transmit a payment declined message to at least one of the issuer server 118 or the acquirer server 120. In some scenarios, the payment declined message may be transmitted to that ACS as well.
[0093] FIG. 3A represents a sequence flow diagram 300A for authenticating a payment transaction, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300A 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 300A, references may be made to elements described in FIGS. 1-2. 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 302.
[0094] At step 302 the cardholder 104 performs a purchase transaction with a merchant such as merchant 108.
[0095] At step 304, the electronic device 106 captures the transaction data and transmits it to the merchant 108.
[0096] At step 306, the merchant 108 generates the payment authorization request message along with the transaction data including the one or more transaction attributes for authorization of the payment/purchase transaction, and sends it to the server system 102.
[0097] At step 308, the server system 102 generates a first unique key based on the one or more transaction attributes and transmits the payment authorization request message along with the transaction data to the issuer server 118.
[0098] At step 310, the issuer server 118 generates the One Time Password (OTP) code corresponding to the transaction and sends the same to the server system 102.
[0099] At 312, the server system 102 facilitates the display of the first GUI to be displayed on a display associated with the electronic device 106 of cardholder 104. In a non-limiting example, the GUI may include a first option for approval of the corresponding payment transaction and a second option for denial of the corresponding payment transaction. In a particular implementation, if the corresponding payment transaction is an online payment, then the first GUI may be facilitated to be included in the existing payment gateway being displayed to cardholder 104 by the payment server 112. In another implementation, if the corresponding payment transaction is a CP transaction at a POS device of the merchant 108, then the first GUI may be facilitated to be included in the existing payment gateway being displayed on the POS device of the merchant 108.
[00100] As may be understood, if at step 314A, the cardholder 104 selects the first option on the first GUI on their electronic device 106 then, at step 314B the server system 102 will validate the cardholder 104 identity corresponding to the payment transaction.
[00101] Alternatively, if at step 316A, the cardholder 104 selects the second option on the first GUI on their electronic device 106 then, at step 316B the server system 102 will generate and transmit the payment declined message to the issuer server 118.
[00102] At 318, the server system 102 sends a payment authentication request message including the OTP received at the step 310. The payment authentication request message is sent to the issuer server 118 upon successful validation of the cardholder identity at step 314B. The issuer server 118 then authenticates the payment by comparing the OTP generated initially and the one received in the payment authentication request message.
[00103] At 320, the issuer server 118 sends a payment authentication response message. The payment authentication response message either includes a payment successful flag or a payment unsuccessful flag.
[00104] As may be understood, if at step 322A, if an authentication successful flag is received with the payment authentication response message then, at step 322B the server system 102 generates and sends the payment approval message to the acquirer server 120 associated with the merchant 108.
[00105] Alternatively, if at step 324A, an authentication unsuccessful flag is received with the payment authentication response message then, at step 324B the server system 102 generates and sends the payment decline message to the acquirer server 120 associated with the merchant 108.
[00106] As discussed above, transaction data is accessed from the database 114. In an embodiment, the transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past ‘x’ number of days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction. It is to be noted that, the server system 102 in the above flow can be a directory server (DS) and the issuer server 118 can be an Access Control Server (ACS). The flow for authenticating a payment transaction with respect to Access Control Server (ACS) and directory server (DS) is explained in FIG. 3B.
[00107] FIG. 3B is a sequence flow diagram 300B for authenticating a payment transaction in the 3DS authentication process, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300B 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, references may be made to elements described in FIGS. 1-2. 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 326.
[00108] At step 326 the cardholder 104 performs a purchase transaction with a merchant such as merchant 108.
[00109] At step 328, the electronic device 106 captures the transaction data and transmits it to the merchant 108.
[00110] At step 330, the merchant 108 generates the payment authorization request message along with the transaction data including one or more transaction attributes for authorization of the payment/purchase transaction, and sends it to a Directory server (DS) 350 which transfers it to an Access Control Server (ACS) 352. Further, the DS 350 also generates a first unique key based on the one or more transaction attributes.
[00111] At step 332, the Access Control Server 352 generates the One Time Password (OTP) code corresponding to the transaction and sends the same to the Directory Server (DS) 350.
[00112] At 334, Directory Server 350 facilitates the display of the first GUI to be displayed on a display associated with the electronic device 106 of cardholder 104. In a non-limiting example, the GUI may include a first option for approval of the corresponding payment transaction and a second option for denial of the corresponding payment transaction. In a particular implementation, if the corresponding payment transaction is an online payment, then the first GUI may be facilitated to be included in the existing payment gateway being displayed to cardholder 104 by the payment server 112. In another implementation, if the corresponding payment transaction is a CP transaction at a POS device of the merchant 108, then the first GUI may be facilitated to be included in the existing payment gateway being displayed on the POS device of the merchant 108.
[00113] As may be understood, if at step 336A, the cardholder 104 selects the first option on the first GUI on their electronic device 106 then, at step 336B the Directory Server (DS) 350 will validate the cardholder 104 identity corresponding to the payment transaction.
[00114] Alternatively, if at step 338A, the cardholder 104 selects the second option on the first GUI on their electronic device 106 then, at step 338B the Directory Server 350 will generate and transmit the payment declined message to the ACS server 352.
[00115] At 340, the Directory Server 350 sends a payment authentication request message including the OTP received at the step 332. The payment authentication request message is sent to the ACS server 352 upon successful validation of the cardholder 104 identity at step 336B. The ACS server 352 then authenticates the payment by comparing the OTP generated initially and the one received in the payment authentication request message.
[00116] At 342, the ACS server 352 sends a payment authentication response message. The payment authentication response message either includes a payment successful flag or a payment unsuccessful flag.
[00117] As may be understood, if at step 344A, an authentication successful flag is received with the payment authentication response message then, at step 344B Directory Server (DS) 350 generates and sends the payment approval message to the acquirer server 120 associated with the merchant 108.
[00118] Alternatively, if at step 346A, if an authentication unsuccessful flag is received with the payment authentication response message then, at step 346B Directory Server (DS) 350 generates and sends the payment decline message to the acquirer server 120 associated with the merchant 108.
[00119] FIG. 4 represents an exemplary Graphical User Interfaces (GUIs) 400 implemented on an application installed on an electronic device such as electronic device 106 or electronic device 404 for displaying the active transactions, in accordance with an embodiment of the present disclosure. The GUI 400 (such as the first GUI) includes an interface that is shown to a cardholder, such as the cardholder 402, by the payment application 122 on their electronic device 106 by the server system 200. The cardholder 402 is an example of the cardholder 104 of FIG. 1. In a non-limiting implementation, the GUI 400 may correspond to an application interface associated with a list of one or more active transactions. It is noted that the cardholder 402 may see the list of one or more active transactions on the application with GUI 400. As illustrated, an application 408 (may be exemplary representation of the payment application 122) includes a list of one or more active transactions (see, 410) such as the first active transaction and the second active transaction in the list (see, 406). As illustrated, the first active transaction may be a transaction performed by the cardholder 104 at ‘Merchant A, 5:05 PM’ and the second active transaction 406 may be a transaction performed by the cardholder 104 at ‘Merchant B, 6:00 PM’. In the illustrated GUI 400, the cardholder402 is presented with the option to approve the first active transaction (see, 412A) and an option to decline the first active transaction (see, 412B). It is noted that although the exemplary GUI 400 illustrates the approve option and the decline option in a particular manner, the same may also be implemented in another manner. Upon selecting the approve option, the payment transaction may be authorized by the issuer server 118 or the ACS 352 via the server system 200.
[00120] FIG. 5 represents a sequence flow diagram for registering a payment card on the payment application 122, 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, references may be made to elements described in FIGS. 1-2. 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 502.
[00121] At step 502 the cardholder 104 with electronic device 508 initiates the process for adding a payment card on an application such as payment application 122 installed on the electronic device 508 by transmitting a card addition request to the issuer server 510.
[00122] At step 504, the issuer server 510 validates the payment card addition request. In an embodiment, the issuer server 510 validates the payment card addition request by checking whether the payment card is already registered with other electronic devices 508.
[00123] At step 506, the issuer server 510 sends the payment card addition response back to the electronic device 508. If the payment card is not already registered with another electronic device, the validation is successful. If the payment card is already registered with another electronic device, the validation is unsuccessful. In another scenario, if the payment card is already registered with another electronic device, the payment card addition response may include a message for approval or denial to de-register the payment card with another electronic device 508. The cardholder 104 using his electronic device 508 can approve or deny the de-register request.
[00124] FIG. 6 illustrates a process flow diagram depicting a method 600 for authenticating the payment transaction, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 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. Operations of the method 600, and combinations of operations in the method 600 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 600. The process flow starts at operation 602.
[00125] At 602, the method 600 includes receiving, by a server system such as server system 200, a payment authorization request message related to a payment transaction initiated by a cardholder such as cardholder 104 with a merchant such as merchant 108 from an electronic device such as electronic device 106 associated with the cardholder 104. Herein, the payment authorization request message may include at least one or more transaction attributes related to the payment transaction.
[00126] At 604, the method 600 includes generating, by the server system 200, a first unique key associated with the cardholder 104 based, at least in part, on the one or more transaction attributes.
[00127] At 606, the method 600 includes receiving, by the server system 200, a One Time Password (OTP) for the payment transaction from an issuer server 118 associated with the cardholder 104.
[00128] At 608, the method 600 includes facilitating, by the server system 200, a display of one or more active payment transactions corresponding to the cardholder 104 on an application such as payment application 122 installed on the electronic device 106 associated with the cardholder 104.
[00129] At 610, the method 600 includes receiving, by the server system 200, a cardholder 104 response message corresponding to the payment transaction from the one or more active payment transactions displayed on the payment application 122. Herein, the cardholder 104 response message may include at least a second unique key and one of an approval flag and decline flag.
[00130] At 612, the method 600 includes upon determining that the cardholder 104 response message includes the approval flag, validating, by the server system 200, an identity of the cardholder 104 based, at least in part, on comparing the first unique key and the second unique key.
[00131] At 614, the method 600 includes upon successful validation of the identity of the cardholder 104, generating and transmitting, by the server system 200, a payment authentication request message to the issuer server 118. In an example, the payment authentication request message may include the OTP.
[00132] At 616, the method 600 includes upon receiving a payment authentication response message including an authentication successful flag from the issuer server 118, generating and transmitting, by the server system 200, a payment approval message to an acquirer server 120 associated with the merchant 108.
[00133] FIG. 7 illustrates a process flow diagram depicting a method 700 for authenticating the payment transaction in a 3DS system, in accordance with an embodiment of the present disclosure. The method 700 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 700 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 700, and combinations of operations in the method 700 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 700. The process flow starts at operation 702.
[00134] At 702, the method 700 includes receiving, by a Directory Server (DS) 350, a payment authorization request message related to a payment transaction initiated by a cardholder such as cardholder 104 with a merchant such as merchant 108 from an electronic device such as electronic device 106 associated with the cardholder 104. Herein, the payment authorization request message may include at least one or more transaction attributes related to the payment transaction.
[00135] At 704, the method 700 includes generating, by the directory server 350, a first unique key associated with the cardholder 104 based, at least in part, on the one or more transaction attributes.
[00136] At 706, the method 700 includes receiving, by the directory server 350, a One Time Password (OTP) for the payment transaction from an Access Control Server (ACS) 352 associated with the cardholder 104.
[00137] At 708, the method 700 includes facilitating, by the directory server 350, a display of one or more active payment transactions corresponding to the cardholder 104 on an application such as payment application 122 installed on the electronic device 106 associated with the cardholder 104.
[00138] At 710, the method 700 includes receiving, by the directory server 350, a cardholder 104 response message corresponding to the payment transaction from the one or more active payment transactions displayed on the payment application 122. Herein, the cardholder 104 response message may include at least a second unique key and one of an approval flag and a decline flag.
[00139] At 712, the method 700 includes upon determining that the cardholder 104 response message includes the approval flag, validating, by the directory server, an identity of the cardholder 104 based, at least in part, on comparing the first unique key and the second unique key.
[00140] At 714, the method 700 includes upon successful validation of the identity of the cardholder 104, generating and transmitting, by the directory server 350, a payment authentication request message to the ACS 352. In an example, the payment authentication request message may include the OTP.
[00141] At 716, the method 700 includes upon receiving a payment authentication response message including an authentication successful flag from the ACS 352, generating and transmitting, by the directory server 350, a payment approval message to an MPI associated with the merchant 108.
[00142] FIG. 8 shows a simplified block diagram of an electronic device 800 capable of implementing the various embodiments of the present disclosure. The electronic device 800 may be an example of either the electronic device 106 shown in FIG.1. It should be understood that the electronic device 800 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 800 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. 8. As such, among other examples, the electronic device 800 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.
[00143] The illustrated electronic device 800 includes a controller or a processor 802 (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 804 controls the allocation and usage of the components of the electronic device 800 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 API security applications 806 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.
[00144] The illustrated electronic device 800 includes one or more memory components, for example, a non-removable memory 808 and/or a removable memory 810. The non-removable memory 808 and/or the removable memory 810 may be collectively known as storage device/module in an embodiment. The non-removable memory 808 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 810 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 804. The electronic device 800 may further include a user identity module (UIM) 812. The UIM 812 may be a memory device having a processor built in. The UIM 812 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 812 typically stores information elements related to a mobile subscriber. The UIM 812 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).
[00145] The electronic device 800 can support one or more input devices 820 and one or more output devices 830. Examples of the input devices 820 may include, but are not limited to, a touch screen / a display screen 822 (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 824 (e.g., capable of capturing voice input), a camera module 826 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 828. Examples of the output devices 830 may include, but are not limited to, a speaker 832 and a display 834. 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 822 and the display 834 can be combined into a single input/output device.
[00146] A wireless modem 840 can be coupled to one or more antennas (not shown in the FIG. 8) and can support two-way communications between the processor 802 and external devices, as is well understood in the art. The wireless modem 840 is shown generically and can include, for example, a cellular modem 842 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 844 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 846. The wireless modem 840 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 800 and a public switched telephone network (PSTN).
[00147] The electronic device 800 can further include one or more input/output ports 850, a power supply 852, one or more sensors 854 for example, 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 800, a transceiver 856 (for wirelessly transmitting analog or digital signals) and/or a physical connector 860, 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.
[00148] FIG. 9 illustrates a simplified block diagram of the acquirer server 900, in accordance with an embodiment of the present disclosure. The acquirer server 900 is an example of the acquirer server 120 of FIG. 1. The acquirer server 900 is associated with an acquirer bank/acquirer, in which a merchant may have an account. The acquirer server 900 includes a processing module 902 operatively coupled to a storage module 904 and a communication module 906. The components of the acquirer server 900 provided herein may not be exhaustive and the acquirer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00149] The storage module 904 is configured to store machine-executable instructions to be accessed by the processing module 902. Additionally, the storage module 904 stores information related to, contact information of the merchant, bank account number, availability of funds in the account, payment card details, transaction details, and/or the like. Further, the storage module 904 is configured to store payment transactions.
[00150] In one embodiment, the acquirer server 900 is configured to store profile data (e.g., an account balance, a credit line, details of the merchant 108, account identification information) in a transaction database 908. The details of the merchant 108 may include, but are not limited to, merchant name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, Merchant Category Code (MCC), merchant industry, merchant type, etc.
[00151] The processing module 902 is configured to communicate with one or more remote devices such as a remote device 910 using the communication module 906 over a network such as the network 116 of FIG. 1. The examples of the remote device 910 include the server system 102, the payment server 112, the issuer server 118 or other computing systems of the acquirer server 900, and the like. The communication module 906 is capable of facilitating such operative communication with the remote device 910 and cloud servers using Application Program Interface (API) calls. The communication module 906 is configured to receive a payment transaction request performed by the cardholder 104 via the network 116. The processing module 902 receives payment card information, a payment transaction amount, and cardholder information from the remote device 910 (i.e., the payment server 112). The acquirer server 900 includes a user profile database 912 and the transaction database 908 for storing transaction data. The user profile database 912 may include information of the merchants. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, and other internal data to evaluate each transaction.
[00152] FIG. 10 illustrates a simplified block diagram of the issuer server 1000, in accordance with an embodiment of the present disclosure. The issuer server 1000 is an example of the issuer server 118 of FIG. 1. The issuer server 1000 is associated with an issuer bank/issuer, in which an account holder may have an account, which provides a payment card. The issuer server 1000 includes a processing module 1002 operatively coupled to a storage module 1004 and a communication module 1006. The components of the issuer server 1000 provided herein may not be exhaustive and the issuer server 1000 may include more or fewer components than those depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 1000 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00153] The storage module 1004 is configured to store machine-executable instructions to be accessed by the processing module 1002. Additionally, the storage module 1004 stores information related to, contact information of the cardholder, a bank account number, availability of funds in the account, payment card details, transaction details, payment account details, and/or the like. Further, the storage module 1004 is configured to store payment transactions.
[00154] In one embodiment, the issuer server 1000 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder, account identification information, payment card number, etc.) in a database. The details of the cardholder may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder, etc.
[00155] The processing module 1002 is configured to communicate with one or more remote devices such as a remote device 1008 using the communication module 1006 over a network such as the network 116 of FIG. 1. Examples of the remote device 1008 include the server system 200, the payment server 112, the acquirer server 120 or other computing systems of the issuer server 1000. The communication module 1006 is capable of facilitating such operative communication with the remote devices 1008 and cloud servers using API calls. The communication module 1006 is configured to receive a payment transaction request performed by an account holder via the network 116. The processing module 1002 receives payment card information, a payment transaction amount, cardholder information, and merchant information from the remote device 1008 (e.g., the payment server 112). The issuer server 1000 includes a transaction database 1010 for storing transaction data. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular account holder, transaction location information, external data sources, and other internal data to evaluate each transaction. The issuer server 1000 includes a user profile database 1012 storing user profiles associated with the plurality of account holders.
[00156] The user profile data may include an account balance, a credit line, details of the account holders, account identification information, payment card number, or the like. The details of the account holders may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder.
[00157] FIG. 11 illustrates a simplified block diagram of a payment server 1100, in accordance with an embodiment of the present disclosure. The payment server 1100 is an example of the payment server 112 of FIG. 1. The payment server 1100 and the server system 200 may use the payment network 110 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
[00158] The payment server 1100 includes a processing module 1102 configured to extract programming instructions from a memory 1104 to provide various features of the present disclosure. The components of the payment server 1100 provided herein may not be exhaustive and the payment server 1100 may include more or fewer components than that depicted in FIG. 11. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1100 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00159] Via a communication module 1106, the processing module 1102 receives a request from a remote device 1108, such as the issuer server 118, the acquirer server 120, or the server system 102. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 1100 includes a database 1110. The database 1110 also includes transaction processing data such as issuer Identifier (ID), country code, acquirer ID, and Merchant ID (MID), among others.
[00160] When the payment server 1100 receives a payment transaction request from the acquirer server 120 or a payment terminal (e.g., Internet Of Things (IoT) device), the payment server 1100 may route the payment transaction request to an issuer server (e.g., the issuer server 118). The database 1110 stores transaction identifiers for identifying transaction details such as transaction amount, IoT device details, acquirer account information, transaction records, merchant account information, and the like.
[00161] In one example embodiment, the acquirer server 120 is configured to send an authorization request message to the payment server 1100. The authorization request message includes, but is not limited to, the payment transaction request.
[00162] The processing module 1102 further sends the payment transaction request to the issuer server 118 for facilitating the payment transactions from the remote device 1108. The processing module 1102 is further configured to notify the remote device 1108 of the transaction status in form of an authorization response message via the communication module 1106. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 118. Alternatively, in one embodiment, the processing module 1102 is configured to send an authorization response message for declining the payment transaction request, via the communication module 1106, to the acquirer server 120. In one embodiment, the processing module 1102 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.
[00163] The disclosed method with reference to FIGS. 2-7, 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.
[00164] 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 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).
[00165] 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 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 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.
[00166] 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 scope of the invention.
[00167] 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 payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder, the payment authorization request message comprising one or more transaction attributes related to the payment transaction;
generating, by the server system, a first unique key associated with the cardholder based, at least in part, on the one or more transaction attributes;
receiving, by the server system, a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder;
facilitating, by the server system, a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder;
receiving, by the server system, a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application, the cardholder response message comprising at least a second unique key and one of an approval flag and decline flag;
upon determining that the cardholder response message comprises the approval flag, validating, by the server system, an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key;
upon successful validation of the identity of the cardholder, generating and transmitting, by the server system, a payment authentication request message to the issuer server, the payment authentication request message comprising the OTP; and
upon receiving a payment authentication response message comprising an authentication successful flag from the issuer server, generating and transmitting, by the server system, a payment approval message to an acquirer server associated with the merchant.

2. The computer-implemented method as claimed in claim 1, wherein the one or more transaction attributes related to the payment transaction comprises at least one of a transac-tion amount, a transaction date, a transaction time, a cardholder identifier (ID), an electronic device ID, merchant information, and authentication information.

3. The computer-implemented method as claimed in claim 1, wherein facilitating the display of one or more active payment transactions corresponding to the cardholder, further comprises:
generating and transmitting, by the server system, an active transaction request to the issuer server;
receiving, by the server system, information related to the one or more active payment transactions from the issuer server; and
transmitting, by the server system, the information related to the one or more active payment transactions to the application installed on the electronic device, wherein upon receiving the information related to the one or more active payment transactions, the application is configured to generate a graphical user interface (GUI) indicating the one or more active transactions.

4. The computer-implemented method as claimed in claim 1, further comprising:
upon determining that the cardholder response message comprises the decline flag, generating and transmitting, by the server system, a payment declined message to at least one of the issuer server and the acquirer server.

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

6. The computer-implemented method as claimed in claim 1, further comprising:
upon receiving the payment authentication response message comprising an authentication unsuccessful flag from the issuer server, generating and transmitting, by the server system, a payment decline message to the acquirer server associated with the merchant.

7. The computer-implemented method as claimed in claim 1, wherein the payment au-thorization request message further comprises at least one of information related to the card-holder indicating a card-related data, an account number of the cardholder, an International Mobile Equipment Identity (IMEI) number associated with the electronic device, an email-id of the cardholder, amount of the payment transaction, IP address or WiFi MAC address of the electronic device and geo-location of the electronic device.

8. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a cardholder login request message from the application, the cardholder login request message comprising a cardholder identifier (ID), electronic device ID, and a cardholder password;
determining, by the server system, if the cardholder ID has been registered with another electronic device based, at least in part on the cardholder ID and the electronic device ID;
upon determining that the cardholder ID has not been registered with the another electronic device, performing, by the server system, an authentication of the cardholder identity based, at least in part, on the cardholder ID and the cardholder password; and
upon successful authentication, generating and transmitting, by the server system, a login successful message to the application.

9. The computer-implemented method as claimed in claim 8, further comprising:
upon determining that the cardholder ID has been registered with the another electronic device, generating and transmitting, by the server system, a login unsuccessful message to the application;
facilitating, by the server system, a display of an option for deregistering the another electronic device on the application; and
upon determining that the cardholder has selected the option for deregistering the another electronic device, authenticating and registering, by the server system, the electronic device with the cardholder ID.

10. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server.

11. 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 payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder, the payment authorization request message comprising one or more transaction attributes related to the payment transaction;
generate a first unique key associated with the cardholder based, at least in part, on the one or more transaction attributes;
receive a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder;
facilitate a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder;
receive a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application, the cardholder response message comprising at least a second unique key and one of an approval flag and decline flag;
upon determining that the cardholder response message comprises the approval flag, validate an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key;
upon successful validation of the identity of the cardholder, generate and transmit a payment authentication request message to the issuer server, the payment authentication request message comprising the OTP; and
upon receiving a payment authentication response message comprising an authentication successful flag from the issuer server, generate and transmit a payment approval message to an acquirer server associated with the merchant.

12. The server system as claimed in claim 11, wherein the one or more transaction attrib-utes related to the payment transaction comprises at least one of a transaction amount, a transaction date, a transaction time, a cardholder identifier (ID), an electronic device ID, merchant information, and authentication information.

13. The server system as claimed in claim 11, wherein to facilitate the display of one or more active payment transactions corresponding to the cardholder, the server system is fur-ther caused to:
generate and transmit an active transaction request to the issuer server;
receive information related to the one or more active payment transactions from the issuer server; and
transmit the information related to the one or more active payment transactions to the application installed on the electronic device, wherein upon receiving the information related to the one or more active payment transactions, the application is configured to generate a graphical user interface (GUI) indicating the one or more active transactions.

14. The server system as claimed in claim 11, wherein the server system is further caused to:
upon determining that the cardholder response message comprises the decline flag, generate and transmit a payment declined message to at least one of the issuer server and the acquirer server.

15. The server system as claimed in claim 11, wherein the server system is further caused to:
upon unsuccessful validation of the identity of the cardholder, generate and transmit a payment authentication failure message to the issuer server.

16. The server system as claimed in claim 11, wherein the server system is further caused to:
upon receiving the payment authentication response message comprising an authentication unsuccessful flag from the issuer server, generate and transmit a payment decline message to the acquirer server associated with the merchant.

17. The server system as claimed in claim 11, wherein the server system is further caused to:
receive a cardholder login request message from the application, the cardholder login request message comprising a cardholder identifier (ID), an electronic device ID, and a cardholder password;
determine if the cardholder ID has been registered with another electronic device based, at least in part, on the cardholder ID and the electronic device ID;
upon determining that the cardholder ID has not been registered with the another electronic device, perform an authentication of the cardholder identity based, at least in part, on the cardholder ID and the cardholder password; and
upon successful authentication, generate and transmit a login successful message to the application.

18. The server system as claimed in claim 17, wherein the server system is further caused to:
upon determining that the cardholder ID has been registered with the another electronic device, generate and transmit a login unsuccessful message to the application;
facilitate a display of an option for deregistering the another electronic device on the application; and
upon determining that the cardholder has selected the option for deregistering the another electronic device, authenticate and register the electronic device with the cardholder ID.

19. A computer-implemented method, comprising:
receiving, by a directory server, a payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder, the payment authorization request message comprising one or more transaction attributes related to the payment transaction;
generating, by the directory server, a first unique key associated with the cardholder based, at least in part, on the one or more transaction attributes;
receiving, by the directory server, a One Time Password (OTP) for the payment transaction from an access control server associated with the cardholder;
facilitating, by the directory server, a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder;
receiving, by the directory server, a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application, the cardholder response message comprising at least a second unique key and one of an approval flag and decline flag;
upon determining that the cardholder response message comprises the approval flag, validating, by the directory server, an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key;
upon successful validation of the identity of the cardholder, generating and transmitting, by the directory server, a payment authentication request message to the access control server, the payment authentication request message comprising the OTP; and
upon receiving a payment authentication response message comprising an authentication successful flag from the access control server, generating and transmitting, by the directory server, a payment approval message to a merchant plug-in associated with the merchant.

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 payment authorization request message related to a payment transaction initiated by a cardholder with a merchant from an electronic device associated with the cardholder, the payment authorization request message comprising one or more transaction attributes related to the payment transaction;
generating a first unique key associated with the cardholder based, at least in part, on the one or more transaction attributes;
receiving a One Time Password (OTP) for the payment transaction from an issuer server associated with the cardholder;
facilitating a display of one or more active payment transactions corresponding to the cardholder on an application installed on the electronic device associated with the cardholder;
receiving a cardholder response message corresponding to the payment transaction from the one or more active payment transactions displayed on the application, the cardholder response message comprising at least a second unique key and one of an approval flag and decline flag;
upon determining that the cardholder response message comprises the approval flag, validating an identity of the cardholder based, at least in part, on comparing the first unique key and the second unique key;
upon successful validation of the identity of the cardholder, generating and transmitting a payment authentication request message to the issuer server, the payment authentication request message comprising the OTP; and
upon receiving a payment authentication response message comprising an authentication successful flag from the issuer server, generating and transmitting a payment approval message to an acquirer server associated with the merchant.