TECHNICAL FIELD [0001] The present disclosure relates to payment technology and, more particularly to, methods and systems for adapting timeout period associated with an authentication session in payment processing. BACKGROUND [0002] The world has seen a dramatic change in buying/selling of goods/services with the advent of electronic devices. Nowadays, many customers purchase from an e-commerce site or an online retailer (referred to hereinafter as 'a merchant site') at the comfort of their home via the electronic devices. The merchant site generally accepts digital payments for the goods/services from the customers. Generally, payment transactions for the goods/services are performed through a payment gateway and a payment network that act as a medium between a merchant and a customer that authenticates and processes the payment transaction securely. For instance, the payment gateway and network help in exchanging information between the customer's bank (e.g., an issuing bank) and the merchant's bank (e.g., an acquiring bank). At the time of checkout after the purchase at the merchant site, the customer is redirected to a payment gateway site and the customer provides payment card information for the payment transaction. [0003] After providing the payment card information, the identity of the customer is authenticated prior to further processing the payment transaction. The customer is usually provided a time frame (i.e. an authentication session) for validating the identity of the customer. Typically, the authentication session is predefined and non-configurable that may be inefficient at times. For instance, the authentication session may be fixed with a timeout period of 3 minutes for authenticating the identity of the customer. In an example scenario, the customer may authenticate his/her identity by means of a static password or a One-Time Password (OTP). The static password may be provided within a few seconds of commencement of the authentication session such that a time period required for providing authentication information may be quite less as compared to the authentication session of 3 minutes which is fixed for every payment transaction. However, authentication process using the OTP may take more than that of the static password. In one instance, the customer may need only 1 minute of the authentication session of 3 minutes and 2 minutes of the authentication session may be left unused. In such instances, the authentication session may be on-hold for 2 minutes that may result in inefficient utilization of resources. In addition to this, if the authentication session is on-hold, then vulnerability to fraud and unwanted situations may be high. [0004] Accordingly, there is a need for a method to overcome the above-mentioned problems and facilitate a technique that helps in managing a timeout period of the authentication session for a payment transaction. Moreover, there is a need to configure the timeout period for efficiently and securely authenticating the payment transaction. SUMMARY [0005] Various embodiments of the present disclosure provide methods and systems for managing timeout period of an authentication session for a payment transaction. [0006] In an embodiment, a method is disclosed. The method includes receiving, by a server system associated with a payment network, a payment transaction request for a payment transaction by a payment card of a user. The payment transaction request includes a payment card information of the payment card of the user. The method includes upon receiving the payment transaction request, facilitating, by the server system, a selection of an authentication option from a plurality of authentication options presented to the user on an issuer interface associated with an issuer of the payment card. The plurality of authentication options is presented for authenticating a payment transaction associated with the payment transaction request. The method further includes upon receiving the selection of the authentication option, dynamically adapting, by the server system, a timeout period of an authentication session for authenticating the payment transaction based on the selection of authentication option. [0007] In another embodiment, a server system is disclosed. The server system includes a memory that includes executable instructions and a processor. The processor is communicably configured to execute the instructions to cause the server system to at least perform receiving a payment transaction request from a merchant interface for a payment transaction by a payment card of a user. The payment transaction request includes a payment card information. The server system is caused to at least perform facilitating a selection of an authentication option from a plurality of authentication options presented to the user on an issuer interface associated with an issuer of the payment card, upon receiving the payment transaction request. The plurality of authentication options is presented for authenticating the payment transaction associated with the payment transaction request. The server system is further caused to at least perform upon receiving the authentication option, dynamically adapting a timeout period of an authentication session for authenticating the payment transaction based on the authentication option. [0008] In yet another embodiment, a method for dynamically adapting a timeout period of a payment transaction is disclosed. The method includes receiving, by a server system associated with a payment network, a payment transaction request initiated from a merchant interface for the payment transaction by a payment card of a user. The payment transaction request includes a payment card information of the payment cards of the user. The method includes provisioning, by the server system, a plurality of authentication options for the user to authenticate the payment transaction on an issuer interface associated with an issuer of the payment card, the plurality of authentication options includes a one-time password (OTP) option and a static password option, upon receiving the payment transaction request. The method includes receiving, by the server system, a selection of an authentication option among the plurality of options from the user. The method further includes adapting, by the server system, the timeout period of an authenticating session for authenticating the payment transaction based on the selection of the authentication option, and one or more of: a set of predefined rules, a plurality of usage analytics data and a user profile information. [0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows. BRIEF DESCRIPTION OF THE FIGURES [0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which: [0011] FIG. 1 illustrates an example representation of an environment, in which at least some example embodiments of the present disclosure can be implemented; [0012] FIG. 2A represents a sequence flow diagram of determining a timeout period for an authentication session based on an authentication option selected by a user, in accordance with an example embodiment of the present disclosure; [0013] FIG. 2B represents a sequence flow diagram of determining a timeout period for an authentication session based on an authentication option selected by a user, in accordance with another example embodiment of the present disclosure; [0014] FIG. 2C represents a sequence flow diagram of customizing a plurality of timers based on a user preference input provided by a user for an authentication option, in accordance with an example embodiment of the present disclosure; [0015] FIG. 3 represents a flowchart for determining a timeout period based on an authentication option selected by a user, in accordance with an example embodiment of the present disclosure; [0016] FIG. 4 illustrates a block diagram representation of sending a plurality of usage analytics data collected from a user device by a merchant site to a payment server via a payment site, in accordance with an example embodiment of the present disclosure; [0017] FIG. 5 illustrates a schematic representation of a table including user profile information of a plurality of users maintained at a server system, in accordance with an example embodiment of the present disclosure; [0018] FIG. 6 illustrates a schematic representation of a table for depicting a plurality of usage analytics data of the user collected from a user device and maintained at the server system, in accordance with an example embodiment of the present disclosure; [0019] FIG. 7 illustrates a schematic representation of a table for depicting a set of predefined rules for determining a timeout period maintained at the server system, in accordance with an example embodiment of the present disclosure; [0020] FIG. 8 shows an example representation of a UI displayed to a user on a display screen of a user device by an application interface for customizing a plurality of timers based on a user preference input, in accordance with an example embodiment of the present disclosure; [0021] FIG. 9 illustrates an example representation of a UI displayed to a user on a display screen of a user device by a merchant interface for receiving payment card information of the user for a payment transaction, in accordance with an example embodiment of the present disclosure; [0022] FIG. 10A illustrates an example representation of a UI displayed to a user on a display screen of a user device by an issuer interface depicting a timeout period for an authentication session based on a static password option selected by the user, in accordance with an example embodiment of the present disclosure; [0023] FIG. 10B illustrates an example representation of a UI displayed to a user on a display screen of a user device by the merchant interface depicting a timeout period for an authentication session based a One-Time Password (OTP) option selected by the user, in accordance with an example embodiment of the present disclosure; [0024] FIG. 11A illustrates a flow diagram depicting a method for dynamically adapting a timeout period of an authentication session for authenticating a payment transaction based on an authentication option, in accordance with an example embodiment of the present disclosure; [0025] FIG. 11B illustrates a flow diagram depicting a method for dynamically adapting a timeout period of an authentication session for authenticating a payment transaction based on an authentication option, in accordance with another example embodiment of the present disclosure; [0026] FIG. 12 is a simplified block diagram of a server system for dynamically adapting a timeout period of an authentication session for a payment transaction based on an authentication option, in accordance with an example embodiment of the present disclosure; [0027] FIG. 13 is a simplified block diagram of an issuer server used for dynamically adapting a timeout period for authenticating a payment transaction based on an authentication option, in accordance with an example embodiment of the present disclosure; [0028] FIG. 14 is a simplified block diagram of an acquirer server used for facilitating payment transactions to a merchant, in accordance with an example embodiment of the present disclosure; [0029] FIG. 15 is a simplified block diagram of a payment server used for dynamically adapting a timeout period for authenticating a payment transaction based on an authentication option, in accordance with an example embodiment of the present disclosure; and [0030] FIG. 16 shows simplified block diagram of a user device, for example, a mobile phone capable of implementing the various embodiments of the present disclosure. [0031] 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 [0032] 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. [0033] 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 are not necessarily all referring 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. [0034] 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. [0035] The term "payment account" refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit 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 PayPal®, and the like. [0036] The term "payment card", refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction 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 form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account. [0037] The term "payment network", refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different 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 configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by MasterCard®, VISA®, Discover®, American Express®, etc. OVERVIEW [0038] Various example embodiments of the present disclosure provide methods and systems for adapting timeout period of an authentication session based on an authentication option selected by a user that overcome obstacles mentioned in the background. More specifically, techniques disclosed herein enable determining a timeout period for authenticating a payment transaction based on the authentication option. Herein, the term "adapting" implies dynamically changing or adjusting the timeout period based on the authentication option and a set of predefined rules. Moreover, timeout period may be dynamically adapted based on the authentication option, the set of predefined rules, a plurality of usage analytics data and a user profile information, as described later. [0039] In many example scenarios, a user may buy goods/services at an online store (referred to hereinafter as 'a merchant interface') hosted and managed by a merchant. The online store may include e-commerce websites, online retail stores, e-business service providers, etc. The user may make a payment transaction to the merchant on the merchant interface through a payment gateway using a payment card. The payment gateway further facilitates the user to authenticate the payment transaction at an issuer interface hosted and managed by the issuer server. A payment transaction request is initiated at the merchant interface and is sent to the issuer server via a payment server. The payment transaction request includes information of the payment card of the user and a preference of the user for authenticating the payment transaction at the issuer interface. The issuer server redirects the user from the merchant interface to the issuer interface for authenticating the payment transaction. The user is provided with a plurality of authentication options to select an authentication option for validating authentication of the payment card and/or the user. Some examples of the plurality of authentication options may include, but are not limited to, a One-Time Password (OTP) option, a Quick-Response (QR) code option, a static password option and a biometric-based password option. [0040] As the user selects the authentication option of the issuer interface, the issuer interface initiates an authentication session with a timeout period for the user to complete the authentication process. The process of authenticating the payment transaction starts when the timeout period of the authentication session is initiated. In one embodiment, the timeout period may be determined based on an authentication option and a set of predefined rules. The set of predefined rules may be stored in a database, such as a rule database managed by the issuer server. The predefined rules employ a plurality of timers to define the timeout period for the authentication session. Each timer may be associated with an authentication option of the plurality of authentication options. For instance, the OTP option may be associated with a first timer and the static password option may be associated with a second timer. Likewise, the QR code option and the biometric-based password option may be associated with different timers. In one example embodiment, the plurality of timers may also be configured based on a user preference input provided by the user. [0041] In some example embodiments, the timeout period may be determined based on the authentication option, the set of predefined rules, a plurality of usage analytics data and a user profile information. The plurality of usage analytics data may be accessed from the user device of the user via the merchant interface. The plurality of usage analytics data may include one or more of a type of user device, a web browser information and a typing speed of the user. Optionally, historical usage analytics data associated with historical payment transactions may also be used to determine the timeout period. The user profile information may include a historical authentication time for authenticating historical payment transactions based on the authentication option. In one example scenario, the authentication option selected by the user may be overridden by an alternate authentication option for authenticating the payment transaction. The alternate authentication option may be selected from a remainder of the plurality of authentication options. In such cases, the issuer server looks up the set of predefined rules to determine a predefined rule that corresponds to overriding of an authentication option by the alternate authentication option. [0042] The methods and systems for dynamically adapting the timeout period of an authentication session for authenticating a payment transaction is further explained in detail with reference to FIGS. 1 to 16. [0043] FIG. 1 illustrates an example representation of an environment 100, in which at least some example embodiments of the present disclosure can be implemented. The environment 100 is depicted to include a user 102 associated with a user device 104. The user device 104 may include a smartphone, a tablet, a laptop, a computer system or any electronic device through which the user 102 can access a merchant interface 106 of a merchant for purchasing goods/services in exchange for money. The merchant interface 106 includes, but not limited to, e-commerce websites, online retail stores, and e-business service providers. The merchant interface 106 may be accessed through a mobile application or a web browser in the user device 104. [0044] When the user 102 checks out, goods/services purchased by the user 102 are collected in an e-cart that is displayed to the user 102 in the merchant interface 106. In one example embodiment, when the user 102 checks out, the user 102 may be redirected to a payment page in the merchant interface 106. In the payment page, the user 102 may be requested to provide payment information, such as, a payment amount for the merchant, payment card information of the user 102 such as card number, expiry details, CVV etc. Additionally, the user 102 may be presented with an option in the payment page for authenticating the payment transaction securely at an issuer interface. When the user 102 provides a selection input on the option, the user 102 may be redirected to the issuer interface (shown in FIG. 9). The issuer interface may be hosted and managed by an issuer server 116. The payment card information may be encrypted by a payment gateway 110. In one example, the payment gateway 110 may be associated with a payment network 108. In another example, the payment gateway 110 may be provided by a third-party service provider which enables secure payment transactions for the merchant via the merchant interface 106. In an embodiment, a payment transaction request is generated by the merchant interface 106. The payment transaction request includes the payment amount, the encrypted payment card information from the payment gateway 110 and optionally the option for authenticating the user 102 via the issuer interface. [0045] The merchant interface 106 sends the payment transaction request to an acquirer server 112 via the payment network 108. Examples of the payment network 108 include, but 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 financial transaction data between financial institutions that are members of Mastercard International Incorporated® (Mastercard is a registered trademark of Mastercard® International Incorporated located in Purchase, N.Y.). The acquirer server 112 sends the payment transaction request to a payment server 114. The payment server 114 receives the payment transaction request and forwards the payment transaction request to the issuer server 116 upon reading the option for authenticating the user 102 via the issuer interface. [0046] The issuer server 116 receives the payment transaction request and facilitates a plurality of authentication options for the user 102 to authenticate the payment transaction at the merchant interface 106 via the issuer interface. The plurality of authentication options may include, but not limited to, a One-Time password (OTP) option, a Quick-Response (QR) code, a static password option, and a biometric-based password option. The user 102 may select an authentication option from the plurality of authentication options. The user 102 has to authenticate the payment transaction within a timeout period of an authentication session in the issuer interface. The authentication of the payment transaction starts when the timeout period is initiated. The issuer server 116 is therefore configured to dynamically determine the timeout period for the authentication session based at least on the authentication option selected by the user 102. [0047] In one example embodiment, the timeout period for the authentication session may be determined based on the authentication option selected by the user 102 and a set of predefined rules. In some example embodiments, the timeout period may be dynamically adapted based on a plurality of timers. Each timer of the plurality of timers may be associated with an authentication option of the plurality of authentication options. In another example embodiment, the timeout period may be determined based on the authentication option and one or more timers of the plurality of timers associated with the authentication option, a plurality of usage analytics data and a user profile information. In at least one example embodiment, the plurality of timers may be configured based on a user preference input provided by the user 102 for the plurality of authentication options. For instance, the user 102 can preset the timeout period of an authentication session for each authentication option of the plurality of authentications options. In an example, the user can preset timeout period as 45 seconds for static passwords, 30 seconds for biometric based passwords and 2 minutes for OTP passwords. The plurality of usage analytics data may include one or more of a type of the user device 104, a web browser information and a typing speed of the user 102. The plurality of usage analytics data may be collected by the merchant interface 106 from the user device 104. The user profile information may include a set of historical authentication time for authenticating a corresponding set of historical payment transactions based on the authentication option selected for each historical payment transaction. [0048] Moreover, the user 102 may choose an alternate authentication option to override the authentication option selected prior by the user 102 for authenticating the payment transaction. The alternate authentication option may be selected from a remainder of the plurality of authentication options. For example, the user 102 may choose to authenticate the payment transaction using a static password and if the user 102 is not able to recollect the static password from memory, he/she may switch over to authenticate the payment transaction via other options, for example, using the OTP password. In such cases, assuming the static password to be associated with a first timer and the OTP password to be associated with a second timer, the timeout period may be adapted based on the first timer, the second timer or a combination of the first timer and the second timer as defined by a set of predefined rules. In an example, a predefined rule may be defined in the set of predefined rules when a choice of the static password for authentication is overridden when the user 102 swaps to authenticate the payment transaction using the OTP based password. For example, when the static password is selected the first timer may be initiated and when the user 102 swaps to select a biometric based option for authenticating the payment transaction, the issuer server 116 looks up the set of predefined rules to determine a predefined rule that may indicate that a maximum of remaining time of the first timer and the second timer (max(remaining time of the first timer, the second timer)) may be determined as the timeout period for the authentication session. The authentication session may be terminated upon expiry of the timeout period. [0049] After authenticating the payment transaction, the issuer server 116 checks a balance amount in an issuer account of the user 102 for validating the payment amount for the payment transaction. After validating the payment amount in the issuer account of the user 102, the issuer server 116 debits funds equal in amount to the payment amount from the issuer account of the user 102. The payment amount is passed to a merchant account of the merchant (hosting and managing goods/services via the merchant interface 106) to complete the payment transaction. [0050] Some non-exhaustive example embodiments of determining a timeout period and dynamically adapting the timeout period of an authentication session for authenticating a payment transaction is described with reference to FIGS. 2A-2C to 16. [0051] FIG. 2A represents a sequence flow diagram 200 of determining a timeout period of a payment transaction based on an authentication option selected by the user 102, in accordance with an example embodiment of the present disclosure. The user 102 may purchase goods/services from a merchant via the merchant interface 106. When the user 102 performs a check out, a payment transaction request is generated. [0052] At 202, the merchant interface 106 sends the payment transaction request to the acquirer server 112. The payment transaction request includes the payment card information such as including but not limited to card number, expiry date, CVV number of the payment card. [0053] At 204, the acquirer server 112 sends the payment transaction request to the payment server 114. When the payment server 114 reads the payment transaction request, the payment server 114 identifies the issuer server 116. At 206, the payment server 114 sends the payment transaction request to the issuer server 116. [0054] At 208, the issuer server 116 provides a plurality of authentication options for authenticating the payment transaction to the user 102. In an embodiment, the issuer server 116 provisions an issuer interface 201 for the user 102 to authenticate the payment transaction. The issuer interface 201 displays the plurality of authentication options for the user 102. Examples of the plurality of authentication options include but not limited to an OTP option, a QR code option, a static password option and a biometric-based password option. [0055] At 210, the user 102 selects an authentication option from the plurality of authentication options displayed on the issuer interface 201. For example, the user 102 may provide a selection input on the OTP option from the plurality of authentication options. [0056] At 212, the issuer interface 201 sends the authentication option selected by the user 102 to the issuer server 116. At 214, after receiving the authentication option, the issuer server 116 refers a set of predefined rules. In one embodiment, the set of predefined rules are defined based on one or more timers of a plurality of timers. For example, timer 1 may be defined for OTP option, timer 2 may be defined for QR code option and timer 3 may be defined for static password option. An example of a predefined rule may be to initiate timer 1 when the user 102 select the OTP option for authentication of the payment transaction. In an example scenario, the user 102 may select the static password option for authentication and may then choose to authenticate using the QR code option. In such a case, the issuer server 116 looks up the set of predefined rules to identify a predefined rule that matches with swap in choice of option for authenticating the payment transaction from the static password to QR password. In this case, the timer may be defined as max of timer 2 and timer 3. In at least some example embodiments, the plurality of timers may be customized based on a user preference input provided by the user 102. For instance, the user 102 may provide the user preference input such that, timer 1 for the OTP option may be configured for 2 minutes, timer 2 for the QR code option may be configured as 1 minute and 30 seconds and the timer 3 for the static password option may be configured for 30 second. The set of predefined rules is referred for determining a timeout period for authenticating the payment transaction. An example table depicting a sample set of predefined rules is shown and explained with reference to FIG. 7. [0057] At 216, a timeout period is determined by the issuer server 116 based on the authentication option and the set of predefined rules. In an example embodiment, the issuer server 116 may look up the predefined set of rules based on the authentication option selected by the user 102 to determine the timeout period. The predefined set of rules define the timeout period in form of plurality of timers. Each predefined rule is associated with one or more timers. The plurality of timers may be preset, or customized based on a user preference input. The timeout period indicates a time frame within which the user 102 can authenticate the payment transaction in an authentication session. A simple example of a set of predefined rules may be as follows: If authenticationoption = static password, then timer 1; and If authenticationoption = OTP, then timer 2. [0058] Assuming timer 1 = 1 minute and timer 2 = 2 minute and 30 seconds, if the user 102 chooses to authenticate the payment transaction using static password, then the timeout period for the authentication session is defined by the timer 1 of 1 minute. Alternatively, if the user 102 chooses the OTP authentication, the timeout period for the authentication session is defined as 2 minute and 30 seconds. The authentication session expires upon expiry of the timeout period. [0059] At 218, the timeout period is displayed to the user 102 during an authentication session in the issuer interface 201. For example, if the user 102 selects authentication option as static password, the issuer server 116 determines the timeout period for the authentication session as 1 minute based on a corresponding predefined rule of the predefined set of rules. The timeout period of 30 seconds is displayed on the issuer interface 201 for the user 102. [0060] At 220, the user 102 enters an authentication data corresponding to the authentication option selected in the issuer interface 201 during the authentication session. For example, if the user 102 has selected authentication option as the static password, the user 102 may be prompted to provide a fixed length password, for example, Personal Identification Number (PIN) on the issuer interface 201. In an example, the user 102 provides a string "5271" as the static password, the string "5271" is referred to as the authentication data. [0061] At 222, the authentication data is sent to the issuer server 116. The authentication data may include an OTP, a static password, a QR code or a biometric-based password, such as a fingerprint data, a facial scan data, an iris pattern data, etc. At 224, the issuer server 116 receives the authentication data and authenticates the payment transaction. For example, the issuer server 116 may compare the authentication data with a pre-stored authentication data corresponding to the authentication option selected by the user 102. If the authentication data provided by the user 102 matches with the pre-stored authentication data, the payment transaction is further processed else the payment transaction is declined. [0062] At 226, the issuer server 116 validates the payment transaction. The issuer server 116 checks availability of balance for debiting the payment amount from an issuer account of the user 102 for the good/services purchased at the merchant via the merchant interface 106. [0063] At 228, the issuer server 116 sends a notification including a payment transaction approval or decline message to the user device 104 via the payment server 114. The payment transaction approval or decline message may be displayed on the merchant interface 106 or the issuer interface 201. Optionally, the notification including the payment transaction approval or decline message is also sent to the acquirer server 112. [0064] FIG. 2B represents a sequence flow diagram 240 of determining a timeout period based on an authentication option selected by the user 102, in accordance with another example embodiment of the present disclosure. The user 102 may purchase goods/services from a merchant via the merchant site 106. The user 102 provides payment card information for making a payment transaction via the merchant interface 106. The payment transaction may be securely processed via the payment gateway 110 and an authentication session extending for a timeout period may be provided for authenticating the payment transaction. The timeout period may be determined and dynamically adapted based on an authentication option, a plurality of usage analytics data and a user profile information. [0065] At 242, the merchant interface 106 may send a permission request to the user device 104 for accessing a plurality of usage analytics data from the user device 104. In some examples, when the user 102 accesses the merchant interface 106, the merchant interface 106 may send the permission request as a pop up box requesting permission to access the plurality of usage analytics data. In one example embodiment, the permission request may be sent via Application Program Interface (API) calls to fetch details, such as a type of the user device 104, web browser details, server log details, usage activities, typing speed of the user etc. [0066] At 244, the merchant interface 106 accesses the plurality of usage analytics data in the user device 104. The user 102 may grant permission for the merchant interface 106 to read the plurality of usage analytics data from the user device 104. The merchant interface 106 reads the plurality of usage analytics data from the user device 104. It should be noted that the steps 242 and 244 may be performed at periodic intervals and can be performed at the same time of initiating the payment transaction and/or anytime before initiating the payment transaction. [0067] At 246, the user 102 sends a payment transaction request to the acquirer server 112 via the merchant interface 106. When the user 102 proceeds to check-out after purchasing goods/services via the merchant interface 106, a payment page prompts the user 102 to provide payment card information for making a transaction corresponding to a payment amount for the goods/services at the merchant interface 106. Additionally, the payment page also includes an option for the user 102 to authenticate the payment transaction at the issuer interface 201 provided by the issuer server 116. The user 102 may choose to securely authenticate the payment transaction via the issuer interface 201. When the user 102 provides the payment card information and optionally selects the option, the payment transaction request is generated by the merchant interface 106. The payment transaction request includes the payment card information, the payment amount, the plurality of usage analytics data and the option for authenticating the payment transaction at the issuer interface 201. [0068] At 248, the acquirer server 112 forwards the payment transaction request to the payment server 114. At 250, the payment server 114 reads the payment transaction request and performs a look up in a table storing user profile information for accessing a user profile information of the user 102. The user profile information of the user 102 includes a set of historical authentication times for authenticating payment transactions using each of the plurality of authentication options. For example, historical authentication time associated with each of the past five payment transactions that were authenticated using an OTP option, a biometric option and a static password option, are stored in the table as the user profile information. An example of the table storing the user profile information of a user is shown and explained with reference to FIG. 5. Optionally, the payment server 114 may also host and manage a table that stores historical usage analytics data associated with the user 102 while performing historical payment transaction using different authentication options. Additionally or alternatively, historical usage analytics data may also be used to determine the timeout period. An example of a table storing historical usage analytics data is shown and explained with reference to FIG. 6. [0069] At 252, the payment server 114 sends the payment transaction request including the user profile information to the issuer server 116. In one example embodiment, the user 102 is routed to the issuer interface 201 provided by the issuer server 116 from the merchant interface 106 as the user 102 chose to authenticate the payment transaction via the issuer interface 201. In some alternate embodiments, the user profile information and/or the historical usage analytics data may be stored at the issuer server 116, instead of the payment server 114, or may be stored at both the servers i.e. the servers 114 and 116. [0070] At 254, the issuer server 116 displays a plurality of authentication options to the user 102 on the user deice 104 via the issuer interface 201 for authenticating the payment transaction. [0071] At 256, the user 102 selects an authentication option from the plurality of authentication options. At 258, the authentication option selected by the user 102 is sent to the issuer server 116. At 260, the issuer server 116 refers a set of predefined rules after receiving the authentication option from the user 102. The set of predefined rules are used to dynamically determine a timeout period for an authentication session. A simplified example of a predefined rule would be as follows: authenticationoption = static password & historicalauthenticationtimestatic =10 seconds & typing speed = 80