Systems and methods for network authentication using device-level authentication controls

Abstract

A system and method for network authentication using device-level authentication controls is provided. The method includes receiving a first payment transaction request from a user device. In response to receiving consent, the method includes enabling an authentication mode for the user to perform authentication using the selected authentication mode and generating a key pair to link with the enabled authentication mode for further authentication of the user device in one or more further transaction requests. The method further includes generating a registration completion message and, upon successful signing using the linked key pair, executing the first payment transaction request. In this manner, the present disclosure can be configured to utilize device authentication data as part of a network authentication risk check, which leads to providing a more secure method for completing transactions.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to Indian Provisional Patent Application No. 202241072014, filed on December 13, 2022, the entire disclosure of which is incorporated herein by reference. [Background technology]

[0002] The present disclosure relates generally to digital transactions, and more particularly to systems and methods for network authentication using device-level authentication controls.

[0003] Technical considerations Recent years have seen a significant increase in e-commerce transactions using user devices, such as card-on-file payments, Unified Payment Interface (UPI), and network banking. Such transactions involve a PIN that the user must enter, and the user must wait for a one-time password (OTP) to successfully complete the transaction. However, this implementation is time-consuming, as the receipt of the OTP can be delayed due to network issues, server problems, and other factors. To address this issue, regulatory distribution-based implementations have emerged, where payment networks are authorized to authenticate transactions on behalf of issuers or the payment network. These implementations introduced authentication solutions that rely on device integrity and identity as the primary factor for authenticating transactions, reducing friction during transactions. While these implementations reduced friction and lack of scalability, risk-averse users were hesitant to trust payment flows without second-factor authentication and were reluctant to perform such payments. This led to a decline in the number of users using these network authentication services.

[0004] Additionally, because transactions may be implemented by a payment network, in such implementations, if such a server associated with the payment network fails due to a server issue, the payment network may not be able to successfully complete the transaction. Furthermore, the payment network's security mechanisms or authentication systems, or the absence of an authentication system, may result in a failure to validate the cardholder initiating the transaction, thus leading to potential fraud. Therefore, there is a need for an improved method for network authentication that uses device-level authentication controls.

[0005] The information disclosed in the Background section of this disclosure is intended solely to enhance understanding of the general background of the disclosure and should not be taken as an acknowledgment or any form of suggestion that this information forms part of existing information already known to those skilled in the art. Summary of the Invention [Problem to be solved by the invention]

[0006] Through the present disclosure, one or more shortcomings of existing systems may be overcome and additional advantages may be provided. Additional features and advantages may be realized through the techniques of the present disclosure. Other non-limiting embodiments and aspects of the present disclosure are described in detail herein and are considered a part of this disclosure.

[0007] Accordingly, an improved system, method, and computer program product is provided for network authentication using device-level authentication control. [Means for solving the problem]

[0008] The present disclosure discloses a method for network authentication using device-level authentication control. The method includes receiving, by an authentication system, a first payment transaction request from a user device. The first payment transaction request includes consent to enroll a user of the user device in authentication based on an authentication mode selected by the user. In response to receiving the consent, the method further includes enabling, by the authentication system, the user to perform authentication using the selected authentication mode. Upon successful authentication, the method includes generating, by the authentication system, a key pair to link with the enabled authentication mode for further authentication of the user device in one or more further transaction requests. The method further includes generating, by the authentication system, a registration completion message using the registered authentication mode that enables the user device to be authenticated in one or more further transaction requests. Thereafter, the method includes executing, by the authentication system, the first payment transaction request upon successful signing using the linked key pair.

[0009] The present disclosure also discloses an authentication system for network authentication using device-level authentication control. The authentication system includes a processor and a memory communicatively coupled to the processor. The memory stores instructions that, when executed, cause the processor to receive a first payment transaction request from a user device. The first payment transaction request includes consent to register a user of the user device for authentication based on an authentication mode selected by the user. In response to receiving the consent, the processor is further configured to enable the user to perform authentication using the selected authentication mode. Furthermore, upon successful authentication, the processor is further configured to generate a registration completion message that enables the user device to authenticate one or more further transaction requests using the registered authentication mode. Thereafter, the processor is configured to execute the first payment transaction request upon successful signing using the linked key pair.

[0010] The present disclosure further discloses a method for network authentication using device-level authentication control. The method includes receiving, by an authentication system, a second payment transaction request from a user device and an authentication mode as input from the user. The method further includes verifying, by the authentication system, user authentication based on a comparison of the input authentication mode set by the user and a pre-registered authentication mode. If the user verification is successful, the method further includes signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication mode. Thereafter, the method includes executing the second payment transaction request if the authentication system successfully signs using the linked key pair.

[0011] The present disclosure further discloses an authentication system for network-level authentication using device-level authentication control. The authentication system includes a processor and a memory. The memory is communicatively coupled to the processor. The memory stores instructions that, when executed, cause the processor to receive a second payment transaction request from a user device and an authentication mode as input from the user. The processor is further configured to verify user authentication based on a comparison between the input authentication mode and a pre-registered authentication mode set by the user. If the user verification is successful, the processor is further configured to sign one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication mode. Thereafter, the processor is configured to execute the second payment transaction request if the signing using the linked key pair is successful.

[0012] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the exemplary aspects, embodiments, and configurations described above, further aspects, embodiments, and configurations will become apparent by reference to the drawings and the following detailed description.

[0013] Several further non-limiting embodiments or aspects are described in the following numbered clauses.

[0014] Clause 1: A method comprising: receiving, by an authentication system, a first payment transaction request from a user device, the first payment transaction request including consent to register a user of the user device for authentication based on an authentication mode selected by the user; enabling, by the authentication system, an authentication mode for the user to perform authentication using the selected authentication mode in response to receiving the consent; upon successful authentication, generating, by the authentication system, a key pair for linking with the enabled authentication mode for further authentication of the user device in one or more further transaction requests; generating, by the authentication system, a registration completion message using the registered authentication mode to enable the user device to be authenticated in the one or more further transaction requests; and upon successful signing using the linked key pair, executing the first payment transaction request by the authentication system.

[0015] Clause 2: The method of clause 1, wherein the enabled authentication mode is one of a first plurality of registered authentication modes registered by the user, and the first plurality of registered authentication modes is associated with device-level authentication control.

[0016] Clause 3: The method of clause 1 or 2, wherein the key pair includes a private key and a public key, the private key being used to sign one or more transactions originating from the user device and stored on the user device, and the public key being used to verify the signed transactions originating from the user device and stored in the authentication system.

[0017] Clause 4: The method of any of clauses 1 to 3, wherein receiving the first payment transaction request includes determining device integrity of the user device, and in response to successful determination of the device integrity of the user device, accessing the key pair, verifying the first payment transaction request, and proceeding with payment of the first payment transaction request.

[0018] Clause 5: A method according to any one of clauses 1 to 4, comprising storing in a database the authentication mode registered by the user, the authentication mode selected by the user, the success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

[0019] Clause 6: The method of any of clauses 1 to 5, comprising determining whether the user device is associated with device-level authentication control, and in response to determining that the user device is not associated with the device-level authentication control, registering one of a second plurality of authentication modes to authenticate the one or more further transaction requests.

[0020] Clause 7: A method, comprising: receiving, by an authentication system, a second payment transaction request from a user device and an authentication mode as input from a user; verifying, by the authentication system, user authentication based on a comparison of the input authentication mode set by the user and a pre-registered authentication mode; if the user is successfully verified, signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication mode; and if signing using the linked key pair is successful, executing the second payment transaction request by the authentication system.

[0021] Clause 8: The method of clause 7, wherein the key pair is accessed in response to a successful device integrity determination of the user device.

[0022] Clause 9: The method of clause 7 or 8, wherein executing the second payment transaction request includes determining the integrity of the user device and storing in a database user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

[0023] Clause 10: The method of any of clauses 7 to 9, further comprising determining one or more risks associated with the user device based on user device authentication data stored in the database to determine the integrity of the user device.

[0024] Clause 11: An authentication system comprising: a processor; and a memory communicatively coupled to the processor, the memory storing instructions that, when executed, cause the processor to: receive a first payment transaction request from a user device, the first payment transaction request including consent to register a user of the user device for authentication based on an authentication mode selected by the user; in response to receiving the consent, enable the authentication mode for the user to perform authentication using the selected authentication mode; upon successful authentication, generate a key pair to link with the enabled authentication mode for further authentication of the user device in one or more further transaction requests; generate a registration completion message using the registered authentication mode to enable the user device to be authenticated in the one or more further transaction requests; and upon successful signing using the linked key pair, execute the first payment transaction request.

[0025] Clause 12: An authentication system as described in Clause 11, wherein the enabled authentication mode is one of a first plurality of registered authentication modes registered by the user, and the first plurality of registered authentication modes is associated with device-level authentication control.

[0026] Clause 13: An authentication system as described in Clause 11 or 12, wherein the key pair includes a private key and a public key, the private key being used to sign one or more transactions originating from the user device and stored on the user device, and the public key being used to verify the signed transactions originating from the user device and stored on the authentication system.

[0027] Clause 14: An authentication system described in any of Clauses 11 to 13, wherein, to execute the first payment transaction request, the processor is configured to determine device integrity of the user device, and in response to successful determination of the device integrity of the user device, access the key pair, verify the first payment transaction request, and proceed with payment of the first payment transaction request.

[0028] Clause 15: An authentication system described in any of Clauses 11 to 14, wherein the processor is configured to store in a database the authentication mode registered by the user, the authentication mode selected by the user, the success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

[0029] Clause 16: An authentication system described in any of Clauses 11 to 15, wherein the processor is configured to determine whether the user device is associated with device-level authentication control, and in response to a determination that the user device is not associated with the device-level authentication control, register one of a second plurality of authentication modes to authenticate the one or more further transaction requests.

[0030] Clause 17: An authentication system comprising: a processor; and a memory communicatively coupled to the processor, the memory storing instructions that, when executed, cause the processor to: receive a second payment transaction request from a user device and an authentication mode as input from a user; verify user authentication based on a comparison of the input authentication mode set by the user with a pre-registered authentication mode; sign one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registered authentication mode upon successful verification of the user; and execute the second payment transaction request using the linked key pair upon successful signing.

[0031] Clause 18: The authentication system of clause 17, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

[0032] Clause 19: An authentication system as described in Clause 17 or 18, wherein, for executing the second payment transaction request, the processor is configured to determine the integrity of the user device and store in a database user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, the success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

[0033] Clause 20: An authentication system described in any of clauses 17 to 19, wherein, in order to determine the integrity of the user device, the processor is further configured to determine one or more risks associated with the user device based on user device authentication data stored in the database.

[0034] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the drawings, the leftmost digit(s) of a reference number indicates the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like structures and components. Certain non-limiting embodiments or aspects of systems and / or methods according to the present subject matter will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0035] [Figure 1] FIG. 1 is a schematic diagram illustrating an environment for network authentication using device-level authentication controls, in accordance with certain non-limiting embodiments or aspects of the present disclosure. [Figure 2] FIG. 2 is a detailed block diagram of an authentication system for network authentication using device-level authentication control, according to certain non-limiting embodiments or aspects related to the present disclosure. [Figure 3A] FIG. 3A is a flowchart illustrating a method for network authentication using device-level authentication control, according to certain non-limiting embodiments or aspects of the present disclosure. [Figure 3B] FIG. 3B is a flowchart illustrating a method for enabling network authentication using device-level authentication controls, according to certain non-limiting embodiments or aspects of the present disclosure. [Figure 4] FIG. 4 is a block diagram of an exemplary computer system for implementing embodiments according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0036] Those skilled in the art will appreciate that all block diagrams in the present disclosure represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be understood that all flowcharts, flow diagrams, state transition diagrams, pseudocode, and the like may be substantially represented in a computer-readable medium and represent various processes that may be performed by a computer or processor, whether or not such a computer or processor is explicitly shown.

[0037] Hereinafter, for purposes of description, the terms "end," "top," "bottom," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and derivatives thereof, refer to the present embodiments and aspects as oriented in the drawings. However, it will be understood that the present embodiments may contemplate various alternative variations and sequences of steps unless expressly specified to the contrary. It will also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Therefore, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed in the present disclosure are not to be considered limiting.

[0038] It is to be understood, however, that the present invention may contemplate various alternative modifications and step sequences unless expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the accompanying drawings, and described in the following specification, are merely exemplary and non-limiting embodiments or aspects. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed in the present disclosure are not to be considered limiting.

[0039] Some non-limiting embodiments or aspects are described in this disclosure in relation to a threshold value. As used in this disclosure, meeting a threshold value can refer to a value greater than the threshold value, a value greater than the threshold value, a value higher than the threshold value, a value equal to or greater than the threshold value, a value less than the threshold value, a value lower than the threshold value, a value equal to or less than the threshold value, or a value equal to the threshold value.

[0040] No aspect, component, element, structure, act, step, function, instruction, and / or the like used in this disclosure should be construed as critical or essential unless expressly stated as such. Also, as used in this disclosure, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more" and "at least one." Furthermore, as used in this disclosure, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, and / or the like) and may be used interchangeably with "one or more" or "at least one." Where only one item is intended, the term "one" or similar language is used. Also, as used in this disclosure, the terms "has," "have," "having," or similar terms are intended to be open-ended. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Additionally, references to an action based on a state may refer to an action that is responsive to a state. For example, the phrases "based on" and "depending on / in response to" may, in some non-limiting embodiments or aspects, refer to a condition for automatically triggering an action (e.g., a particular operation of an electronic device such as a computing device, processor, and / or the like).

[0041] As used in this disclosure, the term “communication” may refer to receipt, receiving, sending, forwarding, providing, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). When one unit (e.g., a device, a system, or a component of a device or system, combinations thereof, and / or the like) communicates with another unit, it means that the unit can directly or indirectly receive information from and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. Also, when two units communicate with each other, the information transmitted may be modified, processed, relayed, and / or routed between the first and second units. For example, a first unit may passively receive information and not actively transmit information to the second unit, yet still be in communication with the second unit. As another example, a first unit may be communicating with a second unit if at least one intermediate unit processes information received from a first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet containing data (e.g., a data packet and / or the like). It will be understood that many other configurations are possible.

[0042] As used in this disclosure, the term "computing device" may refer to one or more electronic devices configured to process data. A computing device, in some embodiments, may include components necessary to receive, process, and output data, such as a processor, a display device, a memory, an input device, a network interface, and / or the like. A computing device may be a mobile device. By way of example, a mobile device may include a mobile phone (e.g., a smartphone or a standard mobile phone), a portable computer, a wearable device (e.g., a watch, eyeglasses, lenses, clothing, and / or the like), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0043] As used in this disclosure, the term “server” may refer to one or more computing devices operated by or facilitating communication and processing between multiple parties in a network environment, such as the Internet, or may include one or more such computing devices. However, it will be understood that communication can be facilitated via one or more public or private network environments, and various other configurations are possible. Furthermore, multiple computing devices (e.g., servers, point-of-sale POS devices, mobile devices, etc.) may constitute a “system” communicating directly or indirectly within a network environment. References to a “server” or a “processor,” as used in this disclosure, can refer to a previously described server and / or processor, other servers and / or processors, and / or combinations of multiple servers and / or processors described as performing the previous step or function. For example, as used in the specification and claims, a first server and / or processor described as performing a first step or function may refer to the same or different server and / or processor described as performing a second step or function.

[0044] As used in this disclosure, the term "system" may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of the like, and / or the like). References to "device," "server," "processor," and / or the like, as used in this disclosure, can refer to a previously described server and / or processor, other servers and / or processors, and / or combinations of multiple servers and / or processors recited as performing a previous step or function. For example, as used in the specification and claims, a first server or first processor recited as performing a first step or first function may refer to the same or different server or processor as the server or processor described as performing a second step or function.

[0045] The word "exemplary" is used herein to mean "serving as an example, illustration, or illustration." Any embodiment or implementation of the present subject matter described in this disclosure as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or aspects.

[0046] While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are described in detail below. It is to be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative constructions falling within the spirit and scope of the disclosure.

[0047] The words "comprises," "includes," "comprising," "including," or any other variation thereof, are intended to cover a non-exclusive inclusion, and a setup, device, or method comprising listed components or steps does not include only those components or steps, but may include other components or steps not expressly listed or inherent to such setup, device, or method. In other words, one or more elements in a system or apparatus described before the phrase "comprising" does not, absent other constraints, exclude the presence of other or additional elements in the system or method.

[0048] In the following detailed description of embodiments or aspects of the present disclosure, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific embodiments in which the disclosure may be practiced. These non-limiting embodiments or aspects are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it should be understood that other non-limiting embodiments or aspects may be utilized and changes may be made without departing from the scope of the disclosure. Accordingly, the following description should not be taken in a limiting sense.

[0049] In recent years, there has been a significant increase in digital transactions, such as e-commerce transactions using user devices, card-on-file payments, Unified Payment Interface (UPI), and network banking. However, a problem with the aforementioned transaction processes is that they sometimes take a long time due to network issues, or issuer servers may be down, resulting in the OTP not being generated and leading to transaction failure. To address the aforementioned issues, in one regulatory distribution-based implementation, the payment network may be permitted to authenticate transactions on behalf of the issuer.

[0050] However, while these aforementioned conventional solutions reduce friction and lack scalability, risk-averse users who are hesitant to trust payment flows without two-factor authentication are less willing to make such payments, leading to a decrease in the number of users using such network authentication services. Furthermore, in such implementations, because transactions may be implemented by the payment network, if such a server associated with the payment network fails due to a server issue, the payment network may not be able to successfully complete the transaction. Furthermore, the absence of a security mechanism or authentication system may result in a failure to verify the cardholder initiating the transaction, thus potentially leading to fraudulent activity.

[0051] To solve the aforementioned problems, the present disclosure relates to a method for network authentication using device-level authentication control. The method includes receiving, by an authentication system, a first payment transaction request from a user device. In response to receiving consent, the method further includes enabling an authentication mode for the user to perform authentication using the selected authentication mode. The method further includes generating a key pair to link with the enabled authentication mode for further authentication of the user device in one or more further transaction requests, and generating a registration completion message using the registered authentication mode to enable the user device to be authenticated in one or more further transaction requests. The method then includes executing the first payment transaction request upon successfully signing using the linked key pair. Thus, the present disclosure may be configured to utilize device authentication data as part of a network authentication risk check and associated cryptographic techniques utilized as part of a device integrity determination, providing a more secure method for completing transactions. The secure transaction method disclosed herein ensures and checks whether a registered user is performing network authentication, thereby providing secure transactions for the user during such network authentication using device-level authentication control. As a further advantage, the present disclosure may provide an enhanced and secure method of authenticating multiple users utilizing network authentication using device-level authentication controls due to the utilization of network authentication risk checks in device-level authentication controls.

[0052] FIG. 1 depicts a schematic diagram illustrating an environment (100) for network authentication using device-level authentication controls, according to certain non-limiting embodiments or aspects of the present disclosure.

[0053] The environment (100) includes a user device (102), an authentication system (104), and a payment network (108) communicatively coupled to a communication network (106). The communication network (106) may be one of a wired communication network, a wireless communication network, or a combination of both wired and wireless communication networks. The communication network (106) may include user devices (102) connected to each other via one or more network devices, such as a switch, a hub, a gateway, a router, etc. The user device (102) associated with a user may be configured to transmit a payment transaction request to the payment network (108) for transaction authentication based on an authentication mode selected by the user. In some non-limiting embodiments or aspects, a payment transaction request may also be referred to as one or more transaction requests.

[0054] The authentication system (104) may be configured to perform network authentication using device-level authentication control for one or more transaction requests. In some non-limiting embodiments or aspects, the authentication system (104) receives a first payment transaction request from a user device (102). The first payment transaction request may include consent to register a user of the user device (102) to authenticate transactions based on an authentication mode selected by the user. The authentication mode may be one of a first plurality of registered authentication modes registered by the user. The first plurality of registered authentication modes registered by the user is associated with device-level authentication control. For example, if the authentication mode for unlocking the user device (102) associated with the user is a password, the first plurality of registered authentication modes may be password-based authentication, and the user may be authenticated by entering the same password. If the authentication system (104) determines that the user has not consented to registering any of the authentication modes for authenticating transactions and determines that the user device (102) is not associated with device-level authentication controls, the authentication system (104) may be configured to enroll the user of the user device (102) in one of a second plurality of authentication modes to authenticate one or more further transaction requests. For example, the authentication system (104) may provide the user with the option of setting a new authentication mode, such as a four-digit PIN, as device-level authentication for one or more further transactions.

[0055] Upon registering or enabling a first plurality of authentication modes for a user associated with the user device (102), the authentication system (104) may be configured to associate the first plurality of authentication modes with the user device (102). In some non-limiting embodiments or aspects, the authentication system may be configured to generate a key pair and link the generated key pair with the enabled authentication mode for further authentication of the user device (102) in one or more further transaction requests. The key pair may include, but is not limited to, a private key and a public key. The private key may be used to sign one or more transactions originating from the user device (102). The public key may be used to verify signed transactions originating from the user device (102) and is stored in the authentication system (104).

[0056] Upon linking the user's first plurality of authentication modes to the key pair, the authentication system (104) may be configured to generate a registration completion message that enables the user device (102) to authenticate one or more further transaction requests using the registered authentication modes, and may execute the first payment transaction request.

[0057] In some non-limiting embodiments or aspects, the authentication system (104) is configured to execute a first payment transaction request upon verifying the integrity of the user device (102). For example, the authentication system (104) may determine the device integrity of the user device (102), and upon determining that the user device (102) has device integrity, the authentication system (104) may verify the first payment transaction request by accessing a key pair. The key pair verification is performed using cryptographic techniques. In some non-limiting embodiments or aspects, the payment network (108) may verify the signature of the linked key pair. In some non-limiting embodiments or aspects, if the authentication system (104) determines that the integrity of the user device (102) has been compromised, the authentication system (104) may not execute the first payment transaction and may generate a transaction failure message prompting the user about the failed transaction.

[0058] In some non-limiting embodiments or aspects, the authentication system (104) may be configured to receive a second payment transaction request and an associated input authentication mode from a user device (102) associated with the user. Furthermore, to validate the user device (102) associated with the user, the authentication system (104) may be configured to validate the input authentication mode from the user device (102) as a pre-registration authentication mode. The pre-registration authentication mode may be configured to be set by the user when registering authentication for one or more additional transaction requests based on the authentication mode selected by the user. Upon successful validation of the user device (102) associated with the user, the authentication system (104) may be configured to sign one or more transaction elements of the second payment transaction request using a key pair linked to the pre-registration authentication mode. In some non-limiting embodiments or aspects, the generated key pair may be utilized to cryptographically sign one or more transactions, such as, but not limited to, a tokenized transaction or a transaction number in a flow, such as a 3DS 2.0 flow. Thereafter, if the signature using the linked key pair is successful, the authentication system (104) may execute a second payment transaction request. In some non-limiting embodiments or aspects, if the device integrity of the user device (102) associated with the user is successfully determined, the authentication system (104) may access the key pair. The authentication system (104) may be configured to determine the integrity of the user device (102) associated with the user based on one or more risks associated with the user device (102) and user device authentication data stored in a database. The user device authentication data may include, but is not limited to, a pre-registered authentication mode by the user, an authentication mode selected by the user (also referred to as an input authentication mode), a device authentication success / failure status, and a timestamp associated with the device authentication success / failure status. For example, the authentication mode pre-registered by the user may be a password for user device A and a face ID for user device B, etc.The device authentication success or failure indicates the total number of successful or failed attempts achieved using the authentication mode executed by the user on the user device (102) to authenticate one or more transaction requests. The timestamp associated with the device authentication success or failure may be, for example, at 12:45 AM, a device authentication failure occurred after four attempts, and at 1:45 PM, a device authentication success occurred after three attempts. This provides an inference that an incorrect authentication mode entered by the user, even after four attempts, leads to device authentication failure of the transaction request, while a correct authentication mode entered after two attempts leads to device authentication success of one or more transaction requests. A detailed description of network authentication using device-level authentication control is shown in FIG. 2.

[0059] FIG. 2 illustrates a detailed block diagram (200) of an authentication system (104) for network authentication using device-level authentication control, according to certain non-limiting embodiments or aspects related to the present disclosure.

[0060] In some non-limiting embodiments or aspects, the authentication system (104) may include a processor (201), a memory (203), and an I / O interface (204). The I / O interface (204) may be configured to receive and transmit input and / or output signals related to one or more operations of the authentication system (104). The memory (203) may be communicatively coupled to the processor (201) and one or more modules (205). The processor (201) may be configured to use the data (206) and the one or more modules (205) to perform one or more functions of the authentication system (104).

[0061] In one embodiment, the data (206) stored in the memory (203) may include, but is not limited to, transaction request data, authentication mode data (208), key pairs (210), user device authentication data (212), and other data (214). In some implementations, the data (206) may be stored in the memory (203) in the form of various data structures. Furthermore, the data (206) may be organized using a data model. The other data (214) may include various temporary data and files generated by different components of the authentication system (104).

[0062] In some non-limiting embodiments or aspects, the transaction request data may include one or more transaction requests. The one or more transaction requests may include, but are not limited to, a first payment transaction request, a second payment transaction request, etc. In some non-limiting embodiments or aspects, the one or more transaction requests include a request to perform network authentication using device-level authentication control using an authentication mode selected by the user. The first payment transaction request may include consent to register the user device (102) and authenticate based on the authentication mode selected by the user. For example, if the user selected password as the authentication mode during the first transaction, the user must enter the same password for one or more additional transactions to successfully complete the one or more additional transactions. The second payment transaction request includes a request to perform a second payment transaction based on network authentication using device-level authentication control. For example, if registration for performing network authentication using device-level authentication control was performed using password A, the second payment transaction will only be successful if the same password A is entered.

[0063] In some non-limiting embodiments or aspects, the authentication mode data (208) may include a plurality of authentication modes registered by a user to perform network authentication using device-level authentication control. For example, the authentication mode may include, but is not limited to, a static pin, a pattern, a password, biometric authentication, etc. The authentication mode may be one of a first plurality of authentication modes registered by the user, a second plurality of authentication modes registered by the user, etc. The first plurality of registered authentication modes is associated with device-level authentication control. For example, if a user sets password X to unlock a user device (102) associated with the user, password X must be entered during authentication. The second plurality of registered authentication modes are authentication modes selected by the user if the user has not registered or provided consent to authenticate transaction requests using an authentication mode.

[0064] In some non-limiting embodiments or aspects, the key pair (210) may be used to verify a second plurality of transactions associated with the second payment transaction request. The key pair (210) may include a private key and a public key that are linked to each other for use in verifying the second plurality of transactions. The private key originates from the user device (102) and is used to sign the second plurality of transactions stored on the user device (102). The public key originates from the user device (102) and is used to verify signed transactions stored in the authentication system (104). Upon successful determination of the device integrity of the user device (102), the authentication system (104) may access the key pair. Furthermore, in some non-limiting embodiments or aspects, upon successful signing using the linked key pair, the authentication system (104) may execute one or more transaction requests. In some non-limiting embodiments or aspects, the payment network (108) may be configured to verify the signature of the linked key pair. In some non-limiting embodiments or aspects, the authentication system (104) may be configured to verify the signature of the linked key pair. The verification signature of the linked key pair may be performed using state of the art cryptography.

[0065] User device authentication data (212) is a type of data utilized to determine the integrity of the user device (102). The user device authentication data (212) may include, but is not limited to, a pre-registered authentication mode by the user, an authentication mode selected by the user (also referred to as an input authentication mode), the success or failure of device authentication, and a timestamp associated with the success or failure of device authentication. An example of user device authentication data (212) is shown in FIG. 1. The user device authentication data (212) may be stored in a database associated with the authentication system (104).

[0066] In some non-limiting embodiments or aspects, the data (206) may be processed by one or more modules (205) of the authentication system (104). In implementations, the one or more modules (205) may include, but are not limited to, a receiving module (216), an authentication mode enablement module (218), a payment transaction registration module (220), a user authentication verification module (222), a transaction element signing module (224), and other modules (226). In one embodiment, the other modules (226) may be used to perform various miscellaneous functions of the authentication system (104). It will be understood that such one or more modules (205) may be represented as a single module or a combination of different modules.

[0067] In some non-limiting embodiments or aspects, the receiving module (216) may be configured to receive a first payment transaction request from the user device (102). Upon registering the user device (102) for network authentication based on an authentication mode selected by the user, the authentication mode enablement module (218) may be configured to enable the user device (102) associated with the user to perform authentication using the selected authentication mode. Upon successful authentication of the user device (102) associated with the user, the payment transaction registration module (220) may be configured to generate a registration completion message that enables the user device (102) to be authenticated for one or more further transaction requests using the registered authentication mode. In some non-limiting embodiments or aspects, the payment transaction registration module (220) may be configured to execute the first payment transaction request by determining device integrity of the user device (102) and, in response to a successful determination of the device integrity of the user device (102), accessing the key pair (210) and verifying the first payment transaction request.

[0068] Upon successful authentication of the first payment transaction request, in some non-limiting embodiments or aspects, the receiving module (216) may be configured to receive a second payment transaction request from the user device (102) and receive an input authentication mode as input from the user. The user authentication verification module (222) may be configured to verify the user authentication by comparing the input authentication mode with a pre-registered authentication mode set by the user.

[0069] Upon successful verification of the user device (102) associated with the user, the transaction element signing module (224) may be configured to sign one or more transaction elements associated with a second payment transaction request using the key pair (210) linked to the pre-registration authentication mode. Thereafter, upon successful signing using the linked key pair, the payment transaction registration module (220) may be configured to execute the second payment transaction request by determining the integrity of the user device (102) and storing the user device authentication data (212). To determine the integrity of the user device (102), the payment transaction registration module (220) may be configured to determine one or more risks associated with the user device (102) based on the user device authentication data (212). In some non-limiting embodiments or aspects, the one or more risks associated with the user device (102) may be such that the payment transaction registration module (220) checks whether the user device (102) has vulnerabilities or misconfigurations, for example, based on information received from third-party applications installed on the user device (102), such as antivirus or malware applications, device configuration applications, and the like, as part of determining the integrity of the user device (102).

[0070] In an alternative embodiment, the transaction process performed by the payment network (108) and the merchant application (not shown) is described in the following paragraphs. First, the merchant application receives a payment transaction request along with an authentication mode as input from the user device (102) associated with the user. The payment transaction request may include, but is not limited to, a unique identifier stored in the retailer's wallet and user device authentication data (212). The merchant then collects the device authentication result and the authentication mode and sends them to the payment network along with transaction details as part of an authentication request. If the input authentication mode is the same as that of the pre-registration authentication, the merchant application sends a payment transaction request along with the input authentication mode shared by the user to the payment network (108). The payment network (108) then checks the authentication mode registered by the user device (102) as part of the network authentication via device authentication control. The payment network (108) then sends the issuer device authentication identifier and the shared secret to the merchant application. In some non-limiting embodiments or aspects, the issuer device authentication identifier may be a key associated with a key pair (210) generated and stored within the user device (102). Furthermore, the merchant application sends a request to the user to authenticate the transaction using the same device-level authentication as the issuer device authentication identifier. Upon successful authentication, the merchant application obtains the key pair (210) using the issuer device authentication identifier and signs a shared secret using the key pair (210). In some non-limiting embodiments or aspects, the shared secret is a random string (also referred to as dynamic text) dynamically generated for the transaction. The shared secret is received by the merchant application. In some non-limiting embodiments or aspects, if the merchant application successfully signs the random string based on the shared secret provided by the payment network (108), the user is authenticated on the merchant application, and the key pair is presumed to have been accessed based on the merchant application's signature on the random string.Additionally, the merchant application sends the signed secret using the key pair to the payment network (108). Finally, the payment network (108) performs an authentication check using the data collected during network authentication using the device authentication response, which is a signed shared secret, in addition to network-specific risk rule checks.

[0071] FIG. 3A shows a flowchart illustrating a method (300A) for network authentication using device-level authentication control, according to certain non-limiting embodiments or aspects of the present disclosure.

[0072] As shown in Figure 3A, the method (300A) includes one or more blocks illustrating the method (300A) for network authentication for device-level authentication control. The method (300A) may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, functions, and the like that perform a function or implement an abstract data type.

[0073] The order in which the method (300A) is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined and the method (300A) can be performed in any order. Also, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described in this disclosure. Furthermore, the method (300A) can be implemented in any suitable hardware, firmware, or combination of hardware and software.

[0074] In block 301, the method (300A) includes receiving, by the authentication system (104), a first payment transaction request from the user device (102). The first payment transaction request includes consent to register and authenticate a user of the user device (102) based on an authentication mode selected by the user.

[0075] At block 303, in response to receiving the consent, the method (300A) includes enabling the authentication mode by the authentication system (104) for the user to perform authentication using the selected authentication mode.

[0076] In block 305, upon successful authentication, the method (300A) includes generating, by the authentication system (104), a key pair (210) to link with the enabled authentication mode for further authentication of the user device (102) in one or more further transaction requests.

[0077] At block 307, the method (300A) includes generating, by the authentication system (104), a registration completion message that enables the user device (102) to be authenticated with one or more further transaction requests using the registered authentication mode.

[0078] In block 309, upon successful signing using the linked key pair, the method (300A) includes executing, by the authentication system (104), a first payment transaction request upon successful signing using the linked key pair.

[0079] FIG. 3B shows a flowchart illustrating a method (300B) for enabling network authentication using device-level authentication controls, according to certain non-limiting embodiments or aspects of the present disclosure.

[0080] As shown in Figure 3B, the method (300B) includes one or more blocks illustrating the method (300B) for network authentication using device-level authentication control. The method (300B) may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, functions, and the like that perform a function or implement an abstract data type.

[0081] The order in which the method (300B) is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined and performed in any order to perform the method (300B). Also, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described in this disclosure. Furthermore, the method (300B) can be implemented in any suitable hardware, software, firmware, or combination of hardware and software.

[0082] At block 311, the method (300B) includes receiving, by the authentication system (104), a second payment transaction request from the user device (102) and an authentication mode as input from the user.

[0083] At block 313, the method (300B) includes verifying, by the authentication system (104), user authentication based on a comparison of the input authentication mode set by the user and the pre-registered authentication mode.

[0084] In block 315, if the user verification is successful, the method (300B) includes signing, by the authentication system (104), one or more transaction elements associated with the second payment transaction request using the key pair (210) linked to the pre-registration authentication mode.

[0085] At block 317, upon successfully signing using the linked key pair, the method (300B) includes executing a second payment transaction request by the authentication system (104).

[0086] FIG. 4 illustrates a block diagram of an exemplary computer system (400) for implementing embodiments or aspects of the present disclosure. Accordingly, the computer system (400) may be used to receive a first payment transaction request from a user device (102). The computer system (400) may include a central processing unit ("CPU" or "processor") (402). The processor (402) may include at least one data processor. The processor (402) may include specialized processing units such as an integrated system (bus) controller, a memory management control unit, a floating-point unit, a graphics processing unit, a digital signal processing unit, etc. The processor (402) may be used to implement the processor (201) illustrated in FIG. 2.

[0087] The processor 402 may be configured to communicate with one or more input / output (I / O) devices (not shown) via an I / O interface 401. The I / O interface 401 may employ communication protocols / methods such as, without limitation, audio, analog, digital, monoaural, RCA, stereo, IEEE (Institute of Electrical and Electronics Engineers)-1394, serial bus, universal serial bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (HDMI), radio frequency (RF) antenna, S-video, VGA, IEEE 802.n / b / g / n / x, Bluetooth, cellular communications (e.g., code division multiple access (CDMA), high-speed packet access (HSPA+), global system for mobile communications (GSM), long-term evolution (LTE), WiMax, or the like).

[0088] Using the I / O interface (401), the computer system (400) can communicate with one or more I / O devices. For example, the input device (409) can be an antenna, keyboard, mouse, joystick, (infrared) remote control, camera, card reader, fax machine, dongle, biometric reader, microphone, touch screen, touch pad, trackball, stylus, scanner, storage device, transceiver, video device / source, etc. The output device (410) can be a printer, fax machine, video display (e.g., cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED), plasma, plasma display panel (PDP), organic light emitting diode display (OLED), etc.), audio speaker, etc.

[0089] The processor 402 may be configured to communicate with a communications network via a network interface 403. The network interface 403 may communicate with the communications network. The network interface 403 may employ connection protocols such as, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 base-T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11a / b / g / n / x, etc. The communications network may be configured in a manner including, but not limited to, a direct interconnect, a local area network (LAN), a wide area network (WAN), a wireless network (e.g., using a wireless application protocol), the Internet, etc. The network interface 403 may employ connection protocols such as, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 base-T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11a / b / g / n / x, etc.

[0090] Communication networks include direct interconnections, e-commerce networks, peer-to-peer (P2P) networks, local area networks (LANs), wide area networks (WANs), wireless networks (e.g., using Wireless Application Protocol), the Internet, Wi-Fi, etc. The first network and the second network may be either dedicated networks or shared networks, which represent an association of different types of networks that communicate with each other using various protocols, e.g., Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), etc. Furthermore, the first network and the second network may comprise various network devices, such as routers, bridges, servers, computing devices, storage devices, etc.

[0091] In some non-limiting embodiments or aspects, the processor (402) may be configured to communicate with memory (405) (e.g., RAM, ROM, etc., not shown in FIG. 4 ) via a storage interface (404). The storage interface (404) may be configured to connect to the memory (405) including, but not limited to, memory drives, removable disk drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include drum, magnetic disk drives, magneto-optical drives, optical drives, redundant array of independent disks (RAID), solid-state memory devices, solid-state drives, etc.

[0092] The memory (405) may store a collection of program or database components, including, but not limited to, a user interface (406), an operating system (407), and a web browser (408). In some non-limiting embodiments or aspects, the computer system (400) may store user / application data, such as data, variables, and records, as described herein. Such databases may be implemented as fault-tolerant, relational, scalable, and secure databases (e.g., Oracle® or Sybase®). The memory (405) may be used to implement the memory (203) depicted in FIG. 4. The memory (405) may be communicatively coupled to the processor (402). The memory (405) stores instructions executable by one or more processors (402), which, when executed, cause the processor (402) to perform network authentication using device-level authentication controls.

[0093] An operating system (407) may facilitate resource management and operation of the computer system (400). Examples of operating systems include, but are not limited to, APPLE MACINTOSH® OS X, UNIX®, UNIX-like system distributions (e.g., BERKELEY SOFTWARE DISTRIBUTION™ (BSD), FREEBSD™, NETBSD™, OPENBSD™, etc.), LINUX DISTRIBUTIONS™ (e.g., RED HAT™, UBUNTU™, KUBUNTU™, etc.), IBM™ OS / 2, MICROSOFT™ WINDOWS™ (XP™, VISTA™ / 7 / 8, 10, etc.), APPLE® IOS™, GOOGLE® ANDROID™, BLACKBERRY® OS, etc.

[0094] In some non-limiting embodiments or aspects, the computer system (400) may be configured to implement a web browser (408) stored program component. The web browser (408) may be a hypertext viewing application, such as MICROSOFT® INTERNET EXPLORER™, GOOGLE® CHROME™, MOZILLA® FIREFOX™, APPLE® SAFARI™, or the like. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), or the like. The web browser (408) may be configured to utilize features such as AJAX™, DHTML™, ADOBE® FLASH™, JAVASCRIPT™, JAVA™, application programming interfaces (APIs), and the like. In some non-limiting embodiments or aspects, the computer system (400) may be configured to implement a mail server (not shown) stored program component. The mail server may be an Internet mail server such as Microsoft Exchange. The mail server may be configured to utilize facilities such as ASP™, ACTIVEX™, ANSI™ C++ / C#, MICROSOFT™.NET™, CGI SCRIPTS™, JAVA™, JAVASCRIPT™, PERL™, PHP™, PYTHON™, or WEBOBJECTS™. The mail server may be configured to utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT™ Exchange, Post Office Protocol (POP), or Simple Mail Transfer Protocol (SMTP).In some non-limiting embodiments or aspects, the computer system (400) may be configured to implement a mail client-stored program component. The mail client (not shown) may be a mail viewing application such as APPLE® MAIL™, MICROSOFT® ENTOURAGE™, MICROSOFT® OUTLOOK™, MOZILLA® THUNDERBIRD™, or the like.

[0095] Additionally, one or more computer-readable storage media may be utilized in implementing embodiments or aspects according to the present disclosure. A computer-readable storage medium refers to any type of physical memory in which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, such as instructions for causing one or more processors to perform steps or stages according to embodiments or aspects described herein. The term "computer-readable medium" should be understood to encompass tangible items and exclude carrier waves and transient signals (and therefore, non-transitory). Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard drives, compact discs (CD-ROMs), digital video discs (DVDs), flash drives, disks, and other known physical storage media.

[0096] The present disclosure may be configured to utilize device authentication data as part of a network authentication risk check and associated cryptographic techniques utilized as part of a device integrity determination, providing a more secure method of completing transactions. The secure transaction method disclosed herein ensures and checks whether a registered user is performing network authentication, thereby providing secure transactions for the user during such network authentication using device-level authentication controls. As an additional advantage, the present disclosure may provide an enhanced secure method of authenticating some users using network authentication using device-level authentication controls without compromising any user details due to the utilization of network authentication risk checks in device-level authentication controls. Furthermore, the present disclosure may provide enhanced convenience for users by providing a simple method of completing transactions based on on-device-level authentication controls, resulting in faster transaction completion compared to conventional solutions.

[0097] In view of the technical advances provided by the disclosed method and control module, the claimed steps are not ordinary, conventional, or well-known aspects in the art because, as discussed above, they provide the aforementioned solutions to technical problems existing in the prior art. Furthermore, because the claimed steps provide technical solutions to technical problems, the claimed steps clearly result in an improvement in the functionality of the system itself.

[0098] The words "including," "comprising," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise. The words "a," "an," and "the" mean "one or more" unless expressly specified otherwise.

[0099] A description of an embodiment in which several components are in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the broad range of possible embodiments or aspects of the present disclosure.

[0100] Where a single device or article is described in this disclosure, it will be apparent that multiple devices / articles (whether or not they cooperate) may be used in place of the single device / article. Similarly, where multiple devices / articles are described in this disclosure (whether or not they cooperate), it will be apparent that the single device / article may be used in place of the multiple devices or articles, or that a different number of devices / articles may be used in place of the number of devices or programs shown. The functionality and / or configuration of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / configuration. Thus, other non-limiting embodiments or aspects of the present disclosure need not include the device itself.

[0101] Finally, the language used herein has been chosen primarily for ease of reading and instructional purposes, and may not be chosen to delineate or limit the subject matter of the present disclosure. Accordingly, it is intended that the scope of the disclosure be limited not by this detailed description, but by the claims that issue on an application based on this specification. Accordingly, embodiments or aspects of the present disclosure are intended to be illustrative, but not limiting, of the scope of the disclosure, which is set forth in the following claims.

[0102] While embodiments or aspects have been described in detail for purposes of illustration, it should be understood that such details are for that purpose only, and the disclosure is not limited to the disclosed embodiments or aspects, but on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it will be understood that the disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. 1. A method comprising: receiving, by an authentication system, a first payment transaction request from a user device, the first payment transaction request including consent to enroll a user of the user device for authentication based on an authentication mode selected by the user; In response to receiving the consent, enabling the authentication mode by the authentication system for the user to perform authentication using the selected authentication mode; Upon successful authentication, generating a key pair for linking with the enabled authentication mode by the authentication system for further authentication of the user device in one or more further transaction requests; generating, by the authentication system, a registration completion message that enables the user device to be authenticated at the one or more further transaction requests using the registered authentication mode; and executing the first payment transaction request with the authentication system upon successful signing using the linked key pair.

2. 2. The method of claim 1, wherein the enabled authentication mode is one of a first plurality of registered authentication modes registered by the user, and the first plurality of registered authentication modes is associated with device-level authentication control.

3. 2. The method of claim 1, wherein the key pair includes a private key and a public key, the private key being used to sign one or more transactions originating from the user device and stored on the user device, and the public key being used to verify the signed transactions originating from the user device and stored in the authentication system.

4. 10. The method of claim 1, wherein receiving the first payment transaction request comprises: determining device integrity of the user device; accessing the key pair in response to a successful determination of device integrity of the user device; validating the first payment transaction request and proceeding with payment of the first payment transaction request.

5. 10. The method of claim 1, further comprising storing in a database the authentication mode registered by the user, the authentication mode selected by the user, a success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

6. 10. The method of claim 1, determining whether the user device is associated with a device-level authentication control; and in response to determining that the user device is not associated with the device-level authentication control, registering one of a second plurality of authentication modes to authenticate the one or more additional transaction requests.

7. 1. A method comprising: receiving, by the authentication system, a second payment transaction request from the user device and an authentication mode as input from the user; verifying user authentication by the authentication system based on a comparison of an input authentication mode set by the user and a pre-registered authentication mode; Upon successful verification of the user, signing, by the authentication system, one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registration authentication mode; and executing the second payment transaction request by the authentication system upon successful signing using the linked key pair.

8. The method of claim 7 , wherein the key pair is accessed in response to a successful device integrity determination of the user device.

9. 8. The method of claim 7, wherein receiving the second payment transaction request comprises: determining the integrity of the user device; storing in a database user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, a success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

10. 10. The method of claim 9, further comprising determining one or more risks associated with the user device based on user device authentication data stored in the database to determine the integrity of the user device.

11. 1. An authentication system comprising: a processor; a memory communicatively coupled to the processor, the memory, upon execution, causing the processor to: receiving a first payment transaction request from a user device, the first payment transaction request including consent to enroll a user of the user device for authentication based on an authentication mode selected by the user; In response to receiving the consent, enabling the authentication mode for the user to perform authentication using the selected authentication mode; Upon successful authentication, generating a key pair to link with the enabled authentication mode for further authentication of the user device in one or more further transaction requests; generating a registration completion message that enables the user device to be authenticated for the one or more further transaction requests using the registered authentication mode; executing the first payment transaction request upon successful signing using the linked key pair; and a memory storing instructions to cause the first payment transaction request to be executed.

12. 12. The authentication system of claim 11, wherein the enabled authentication mode is one of a first plurality of registered authentication modes registered by the user, and the first plurality of registered authentication modes is associated with device-level authentication control.

13. 12. The authentication system of claim 11, wherein the key pair includes a private key and a public key, the private key being used to sign one or more transactions originating from the user device and stored on the user device, and the public key being used to verify the signed transactions originating from the user device and stored on the authentication system.

14. 12. The authentication system of claim 11, wherein to execute the first payment transaction request, the processor: determining device integrity of the user device; accessing the key pair in response to a successful determination of device integrity of the user device; and verifying the first payment transaction request and proceeding with payment of the first payment transaction request.

15. 12. The authentication system of claim 11, wherein the processor is configured to store in a database the authentication mode registered by the user, the authentication mode selected by the user, a success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

16. 12. The authentication system of claim 11, wherein the processor: determining whether the user device is associated with a device-level authentication control; and in response to determining that the user device is not associated with the device-level authentication control, registering one of a second plurality of authentication modes to authenticate the one or more further transaction requests.

17. 1. An authentication system comprising: a processor; a memory communicatively coupled to the processor, the memory, upon execution, causing the processor to: receiving a second payment transaction request from the user device and an authentication mode as input from the user; Verifying user authentication based on a comparison between an input authentication mode set by the user and a pre-registered authentication mode; Upon successful verification of the user, signing one or more transaction elements associated with the second payment transaction request using a key pair linked to the pre-registration authentication mode; and executing the second payment transaction request using the linked key pair upon successful signing.

18. 20. The authentication system of claim 17, wherein the key pair is accessed in response to a successful determination of device integrity of the user device.

19. 18. The authentication system of claim 17, wherein for executing the second payment transaction request, the processor: determining the integrity of the user device; storing in a database user device authentication data including the authentication mode pre-registered by the user, the authentication mode selected by the user, a success or failure of device authentication, and a timestamp associated with the success or failure of the device authentication.

20. 20. The authentication system of claim 19, wherein to determine the integrity of the user device, the processor is further configured to determine one or more risks associated with the user device based on user device authentication data stored in the database.

Images