Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PAYMENTS ACROSS MERCHANTS FOR A CARDHOLDER WITHOUT REPETITIVE CARDHOLDER AUTHENTICATION

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

 
METHODS AND SYSTEMS FOR PAYMENTS ACROSS MERCHANTS FOR A CARDHOLDER WITHOUT REPETITIVE CARDHOLDER AUTHENTICATION

TECHNICAL FIELD
[0001] The present disclosure relates to an authentication system and, more particularly relates to, electronic methods and systems for facilitating a consecutive set of payment transactions of a cardholder across a set of merchants without repetitive cardholder authentication.

BACKGROUND
[0002] A cardholder generally performs multiple payment transactions every month that are consecutive in nature. For example, a cardholder may perform multiple payment transactions to settle various bills such as rent, utilities, telecom, etc., among other transactions. In an exemplary scenario, when a cardholder plans a vacation, he/she may have to perform a plurality of consecutive payment transactions for flight booking, hotel booking, local taxi scheduling, etc. All such payment transactions are done on different merchant websites where the cardholder must enter details such as the card verification value (CVV) code for tokenized payment cards, or the cardholder must enter all their card details in case of some merchants.
[0003] Thus, when there are multiple payment transactions lined up on different merchant websites for a cardholder, the cardholder has to go through the same authentication process every time which seems to be very time-consuming and may sometimes deter the cardholder from completing the payment transactions while deteriorating the cardholder experience.
[0004] In some markets, regulators may require an additional factor of authentication (AFA) on recurring transactions. For example, the Reserve Bank of India (RBI), India’s central bank requires that all the standing instruction (SI) transactions should be prior-authenticated before the scheduled transaction dates of the SI transactions. Hence, banks will be required to inform customers in advance about recurring payments due and the recurring payment transaction would only be carried out following the nod or approval from the customer.
[0005] Therefore, in some scenarios, it might be possible that multiple recurring payment transactions are flagged up for a short period of time (e.g., the first five days of a month) for a single payment card since there are multiple merchants requesting payments from the single payment card. Due to such situations, the cardholder may have to redo the authentication process multiple times within a short period of time. This may lead to friction in online purchasing environments, leading to increased rates of payment transaction abandonment due to the customers' frustrations.
[0006] Thus, there exists a technological need to overcome the above-stated limitations.

SUMMARY
[0007] Various embodiments of the present disclosure provide systems and methods for facilitating a consecutive set of payment transactions across a set of merchants without repetitive cardholder authentication.
[0008] In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes receiving one or more electronic requests from a user device associated with a cardholder. The one or more electronic requests include a first payment transaction request to perform a first payment transaction to a first merchant and a green channel enablement request. The method further includes accessing a first device configuration data of the user device during the first payment transaction. The method further includes setting a plurality of data fields associated with the first payment transaction that is included within an interconnected transaction list as a first data element. The interconnected transaction list stored in a database includes a consecutive set of payment transactions performed by the cardholder after enabling a cardholder authentication bypass channel for the cardholder. The plurality of data fields associated with the first data element includes a brick hash identification field, a green channel status flag field, and a previous brick hash identification field. The method further includes transmitting a payment authorization request message associated with the first payment transaction to an issuer server associated with the cardholder. The payment authorization request message includes information associated with the first payment transaction, and a value stored in the green channel status flag field of the first data element. The method further includes initiating the cardholder authentication bypass channel for the cardholder based, at least in part, on a payment authorization response message received from the issuer server. The cardholder authentication bypass channel facilitates the consecutive set of payment transactions across a plurality of merchants without repetitive cardholder authentication. The method further includes updating one or more of the plurality of data fields of the first data element in the interconnected transaction list based, at least in part, on the payment authorization response message.

BRIEF DESCRIPTION OF THE FIGURES
[0009] For a more complete understanding of embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0010] FIG. 1 is an example representation of an environment, related to at least some embodiments of the present disclosure;
[0011] FIGS. 2A-2C, collectively, represent a sequence flow diagram for enabling a cardholder authentication bypass channel for future payment transactions of the cardholder at specific merchants, in accordance with an embodiment of the present disclosure;
[0012] FIGS. 3A and 3B, collectively, represent a sequence flow diagram for performing a payment transaction at a registered merchant after enabling the cardholder authentication bypass channel for the cardholder, in accordance with an embodiment of the present disclosure;
[0013] FIG. 4 is an example representation of an interconnected transaction list associated with a cardholder, in accordance with an embodiment of the present disclosure;
[0014] FIGS. 5A and 5B, collectively, represent a flow chart for enabling a cardholder authentication bypass channel (i.e., green channel) for future payment transactions at specific merchants, in accordance with an embodiment of the present disclosure;
[0015] FIGS. 6A and 6B, collectively, represent a flow chart for performing a payment transaction at a registered merchant after enabling the cardholder authentication bypass channel for the cardholder, in accordance with an embodiment of the present disclosure;
[0016] FIGS. 7A, 7B, and 7C represent a series of graphical user interfaces (UIs) implemented on a user device to enable cardholder authentication bypass channel (i.e., green channel), in accordance with an embodiment of the present disclosure;
[0017] FIG. 7D represents an example UI implemented on the user device engaged in a second payment transaction when the cardholder authentication bypass channel (i.e., green channel) is enabled, in accordance with an embodiment of the present disclosure;
[0018] FIG. 8 represents a flow diagram of a computer-implemented method for enabling a cardholder authentication bypass channel for a cardholder, in accordance with an embodiment of the present disclosure;
[0019] FIG. 9 is a flow diagram of a computer-implemented method for performing a second payment transaction at a registered merchant when the cardholder authentication bypass channel for a cardholder is enabled, in accordance with an embodiment of the present disclosure;
[0020] FIG. 10 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0021] FIG. 11 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure; and
[0022] FIG. 12 is a simplified block diagram of a user device capable of implementing the various embodiments of the present disclosure.
[0023] 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
[0024] 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.
[0025] 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 appearances of the phrase “in an embodiment” in various places in the specification is 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.
[0026] 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.
[0027] The term "issuer", used throughout the description, refers to a financial institution normally called an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server system called “issuer server” throughout the description.
[0028] Further, the term "acquirer", is an organization that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in question. Typically, the acquirer has an agreement with merchants, wherein the acquirer receives authorization requests for purchase transactions from the merchants and routes the authorization requests to the issuers of the payment cards being used for the purchase transactions. The terms "acquirer", "acquiring bank", "acquiring bank" or "acquirer bank" will be used interchangeably herein. Further, one or more server systems associated with the acquirer are referred to as "acquirer server" to carry out its functions.
[0029] The term "payment account", used throughout the description, refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, an e-wallet account, a checking account, and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0030] The term "payment network", used throughout the description, refers to a network or collection of systems used for the transfer of funds through the use of cash-substitutes. Payment networks may use a variety of 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 operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard®.
[0031] The term “payment card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data (e.g., a digital token) stored in a user device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0032] The term “merchant”, used throughout the description, may include a merchant that has a relationship with the payment processing network. The merchant may receive the proceeds from a purchase when the purchase is settled. The merchant is the company that is ultimately responsible for the financial transaction.
[0033] The terms "cardholder authentication bypass channel" or "green channel", interchangeably used through the description, refer to an automated payment transaction route that acts as a filter to bypass cardholder authentication for a series of subsequent payment transactions of a cardholder at specific merchants. Upon enabling the cardholder authentication bypass channel or the green channel for the cardholder, the cardholder is not required to enter card details at the specific merchants and to perform second-factor authentication. The cardholder authentication bypass channel or the green channel can be enabled at a registered merchant after successful cardholder authentication for a payment transaction at the registered merchant. The cardholder can directly route the payment transactions and bypass the repetitive cardholder authentication process.
[0034] The terms "multi-merchant green channel transaction authorization program" or "green channel program", interchangeably used through the description, refer to a service provided by a payment processor or a third-party server that would enable cardholders to perform payment transactions at multiple merchants without repetitive cardholder authentication. The merchants can enroll in this program and the cardholders who already have enabled the green channel can perform subsequent payment transactions without providing card details and CVV and/or performing second-factor authentication.
[0035] A "merchant application", used throughout the description, may be associated with a particular merchant or may be associated with a number of different merchants and may be capable of identifying a particular merchant (or multiple merchants) which are parties to a transaction. For instance, the merchant application may store information identifying a particular merchant server computer that is configured to provide a purchase environment in which the merchant server computer is capable of processing remote transactions initiated by the merchant application. Further, the merchant application may also include a general-purpose browser or other software-designed application to interact with multiple merchant server computers as long as the browser is configured to identify the merchant server computer and process a remote transaction. The merchant application may be installed on general-purpose memory of a mobile device.
[0036] A "payment service provider", may include an entity that contracts with an acquirer for the purpose of providing acceptance to a sponsored merchant, the sponsored merchant then contracts with a payment service provider to obtain payment services.
OVERVIEW
[0037] Various embodiments of the present disclosure provide methods, systems, user devices, and computer program products for facilitating a consecutive set of payment transactions across a set of merchants without repetitive cardholder authentication thereby, enabling a cardholder to perform a plurality of payment transactions across a plurality of eligible merchants without repeated cardholder authentication. To that effect, the cardholder does not require repeatedly providing details such as CVV or engaging in two-factor authentication (2FA). The present disclosure provides a seamless payment transaction experience to the cardholder and allows them to save time while performing multiple transactions while ensuring security.
[0038] The present disclosure describes a server system that is configured to enable a cardholder authentication bypass channel for a cardholder. In one embodiment, the server system is a part of a payment network. In one embodiment, the server system is configured to receive one or more electronic requests from a user device of a cardholder. In a non-limiting example, one or more electronic requests may include a first payment transaction request to perform a first payment transaction to a first merchant, and a green channel enablement request.
[0039] In one embodiment, the server system is configured to access the first device configuration data of the user device during the first payment transaction. In a non-limiting example, the first device configuration data is used by the server system to generate user device profile data associated with the user device of the cardholder. The user device profile data includes information of a browser signature of an application executing on the user device while performing the first payment transaction and device profiling parameters of the user device. In a non-limiting example, the browser signature and the device profiling parameters include at least browser plugin details, screen resolution data, and canvas fingerprint data. Further, the server system sets the user device profile data field as the user device profile data associated with the user device.
[0040] In one embodiment, the server system is configured to set a plurality of data fields associated with the first payment transaction that is included within an interconnected transaction list as a first data element. The interconnected transaction list stored in a database includes a consecutive set of payment transactions performed by the cardholder after enabling a cardholder authentication bypass channel for the cardholder. In a non-limiting example, the plurality of data fields associated with the first data element includes a brick hash identification field, a green channel status flag field, and a previous brick hash identification field. In yet another non-limiting example, the plurality of data fields may further include a payment token field associated with the cardholder, a user device profile data field, a transaction response field, a merchant identification field, and a cardholder identification field
[0041] In one embodiment, the server system is configured to transmit a payment authorization request message associated with the first payment transaction to an issuer server associated with the cardholder. The payment authorization request message includes information associated with the first payment transaction, and a value stored in the green channel status flag field of the first data element.
[0042] In one embodiment, the server system is configured to initiate the cardholder authentication bypass channel for the cardholder based, at least in part, on a payment authorization response message received from the issuer server. The cardholder authentication bypass channel facilitates the consecutive set of payment transactions across a plurality of merchants without repetitive cardholder authentication. In a non-limiting example, the payment authorization response message received from the issuer server may include information related to a green channel time window and the list of merchants enrolled in the green channel program. In one embodiment, the green channel is enabled for a green channel time window for merchants enrolled in the green channel program administrated by the server system.
[0043] In one embodiment, the server system is configured to update one or more of the plurality of data fields of the first data element in the interconnected transaction list based, at least in part, on the payment authorization response message. Then, the transaction response field is set based, at least in part, on the payment authorization response message. The server system is configured to calculate a hash value of the first data element based, at least in part, on the plurality of data fields and set the brick hash identification field of the first data element to the calculated hash value.
[0044] In one embodiment, the server system is configured to receive a first green channel payment request to perform a second payment transaction for the cardholder to a second merchant of the plurality of merchants. The second payment transaction is routed via the cardholder authentication bypass channel of the cardholder. In one embodiment, the server system is configured to determine whether the first green channel payment request is received within the green channel time window or not. In response to determining that the first green channel payment request is received within the green channel time window, the server system is configured to generate a user device profile data based, at least in part, on the second device configuration data of the user device during the second payment transaction.
[0045] In one embodiment, the server system is configured to append a second data element in the interconnected transaction list of the cardholder. The previous brick hash identification field of the second data element is set as a value of the brick hash identification field of the first data element.
[0046] In one embodiment, the server system is configured to match the content of the user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction. In response to a successful match between the content of the user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction, the server system is configured to send a payment authorization request message to the issuer server. Then, the server system is configured to update the second data element based, at least in part, on a payment authorization response message received from the issuer server.
[0047] In an alternative embodiment, if the match between the content of the user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction is unsuccessful, the server system is configured to send a flag to the issuer server for closing the cardholder authentication bypass channel of the cardholder. Further, the server system is configured to delete the interconnected transaction list of the cardholder from the database.
[0048] Various embodiments of the present disclosure offer multiple technical advantages and technical effects. For instance, the present disclosure helps in reducing the time of a cardholder for completing a series of payment transactions for specific merchants. The present disclosure allows the cardholder to set up a cardholder authentication bypass channel for a consecutive set of payment transactions on a demand basis. The present disclosure enables cardless transactions across multiple merchants with zero payment data sharing on the merchant platform. Further, the transaction conversion rate is also improved since the cardholder does not need to go through multiple authentications for the subsequent payment transactions.
[0049] The technical improvement in the online payment system as described herein is a computer-based solution to a technical deficiency or problem that is itself rooted in computer technology (e.g., the problem itself derives from the use of computer technology). More specifically, data sharing among merchants is a significant problem for transactions conducted over an electronic payment network, especially for cardless transactions and involving international payment service means. Therefore, the present disclosure provides a consumer authentication system to bypass cardholder authentications for particular merchants without sharing card details with the particular merchants.
[0050] Various embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 12.
[0051] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, performing payment transactions between a user/cardholder and a merchant while a multi-merchant transaction authorization channel, i.e., a green channel is enabled. The environment 100 generally includes a server system 102, a user device 104 and a desktop device 110 associated with a cardholder 106, a plurality of merchants 108a, 108b, and 108c (collectively represented as merchant 108), a payment network 112 including a payment server 114, an issuer server 116, and an acquirer server 118, each coupled to, and in communication with a network 120. The network 120 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber-optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in FIG. 1, or any combination thereof.
[0052] Various entities in the environment 100 may connect to the network 120 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 120 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet, etc.) through which the server system 102, the payment server 114, the plurality of merchants 108a-108c, the issuer server 116, the acquirer server 118 and the user device 104 may communicate.
[0053] In one embodiment, the cardholder 106 may be an individual, representative of a corporate entity, non-profit organization, or any other person. Examples of the user device 104 associated with the cardholder 106 may include, without limitation, a smartphone 104, tablet computers, other handheld computers, wearable devices, servers, portable media players, gaming devices, and so forth. In an embodiment, the desktop device 110 may be installed with an internet browser application that may be used by a cardholder 106 for performing payment transactions associated with the merchant 108 over the internet. In another embodiment, the user device 104 may be installed with an application or an ‘app’ that is configured to integrate various APIs for performing payment transactions associated with the merchant 108a via the internet. As it may be understood, the term “application” is used broadly to include any software program(s) capable of implementing the features described herein.
[0054] In various examples, the application may include any internet browser, API, service, application, applet, or other executable code suitable to retrieve payment information from a secure element, generate payment information (e.g., a dynamic value, etc.) for a payment transaction, and communicate with a server system application, merchant application, mobile gateway, and/or any other application in order to securely communicate with a server computer (e.g., remote key manager, mobile gateway, payment processing network, third-party service provider, etc.). The application may be configured to share user device data including but not limited to application signature data, application agent data, application plugin data, application data, hardware data associated with the user device 104, and driver data of the user device 104 associated with the cardholder 106, etc., among other required data with the server system 102. Further, the application may be configured to obtain stored information including user private key, payment credentials, third party keys, and mobile gateway credentials, and may be capable of communicating with an issuer to obtain issuer updates.
[0055] In some examples, the cardholder 106 may operate the user device 104 to conduct a payment transaction through a payment gateway application. The cardholder 106 has established a card-on-file relationship with a merchant (e.g., merchant 108a). The cardholder 106 provides payment card information to the merchant 108a, thereby allowing the merchant 108a to periodically charge the cardholder 106 for a product or a service. For example, the cardholder 106 enters the payment card information into a web browser and submits the payment card information to the merchant 108a. Thereafter, the merchant 108a stores the payment card information in a database and/or server. The payment card information used by the merchant may include the cardholder's name as it appears on the payment card, a billing address, an account number or card number of the payment card, and/or expiration date of the payment card. In other words, the cardholder 106 authorizes the merchant 108a to store the card details of the cardholder 106 and to bill the cardholder 106 for recurring transactions using the stored card details.
[0056] In one embodiment, the issuer server 116 is a financial institution that manages cardholder accounts (i.e., payment accounts) of multiple cardholders. Payment account details of the payment accounts established with the issuer server 116 are stored in cardholder profiles of the cardholders 106 in memory of the issuer server 116 or on a cloud server associated with the issuer server 116. The issuer server 116 approves or denies an authorization request, and then routes, via the payment network 112, an authorization response back to the acquirer server 118. The acquirer server 118 sends the approval to the merchant 108a. The payment account details may include an account balance, an available credit line, details of an account holder, transaction history of the cardholder 106, account information, or the like. The details of the cardholder 106 may include name, age, gender, physical attributes, registered contact number, alternate contact number, registered e-mail ID, or the like of the cardholder 106. The cardholder account may be associated with one or more payment means that enable the cardholder 106 to facilitate the payment transaction.
[0057] Examples of one or more payment means may include, payment cards, Unified Payment Interface (UPI) links, and/or the like. Methods for processing transactions via the issuer server 116 will be apparent to a person of ordinary skill in the art and may include processing the transactions via the traditional four-party system. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
[0058] In one embodiment, the acquirer server 118 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants 108a-108c, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0059] In one embodiment, the plurality of merchants 108a, 108b, and 108c represents authorized accepters of payment cards for the payments for goods/services sold by the plurality of merchants 108a-108c. In one embodiment, the merchant (any one of 108a, 108b, and 108c) is associated with an acquirer server 118.
[0060] In one non-limiting example, to initiate a payment transaction, the cardholder (i.e., cardholder 106) may open a merchant application operated by the merchant 108a on the user device 104 and initiates the transaction with the merchant 108a. The cardholder 106 may enter payment card information or the user device 104 reads already stored payment card information. Thereafter, the merchant application extracts merchant account information to generate a payment authorization request message. Meanwhile, the payment transaction is authenticated based on 3DS authentication methods and the cardholder 106 is verified whether he/she is a genuine user or not. During the 3DS authentication method, the cardholder device 104 receives an OTP (One-time Password) from an authentication server (such as the server system 102), and then the cardholder 106 enters the OTP on the merchant application to proceed with the payment transaction. The payment authorization request message typically includes the payment card account number (PAN), the amount of the transaction, and other information, such as merchant identification and location. The payment authorization request message is sent to the issuer server 116 that issued the cardholder’s payment card.
[0061] In some scenarios (not in accordance with embodiments of the present disclosure), when the cardholder 106 wishes to perform a consecutive set of online payment transactions at multiple merchant applications within a specific time period, the cardholder 106 needs to perform certain actions such as, entering card details or entering secure code in case of the tokenized card at a merchant application, performing two-factor authentication, etc. repetitively at the multiple merchant applications for conducting the consecutive set of online payment transactions. Due to the repetitiveness of such actions for performing the online payment transactions, the cardholder 106 may face friction in online payment transactions and the processing burden on the cardholder 106 to complete the consecutive payment transactions is increased.
[0062] Thus, there is a technical need for a system that can bypass repetitive cardholder authentication for consecutive payment transactions.
[0063] In one embodiment, the server system 102 is configured to perform one or more operations described herein. In one example, the server system 102 is configured to facilitate a consecutive set of payment transactions across the plurality of merchants 108a-108c without repetitive cardholder authentication. In one example, the server system 102 is coupled with a database. The server system 102 is configured in a manner (described in connection with the next set of figures) that facilitates the implementation of a green channel program for a cardholder engaged in a consecutive set of payment transactions. The phrase “consecutive set of payment transactions” refers to a set of payment transactions that occur within a defined time period from a first transaction. For example, in a scenario where a cardholder is planning a vacation, he/she may perform a set of transactions such as flight booking, hotel booking, movie bookings, museum ticket bookings, etc., among other such travel-related transactions, this set of payment transactions may be referred as a consecutive set of transactions. In another example, a set of transactions related to various bill payments may also be considered a consecutive set of payment transactions. Thus, the server system 102 is configured to facilitate a consecutive set of payment transactions with a plurality of merchants without the need to reenter card details or additional details such as CVV or 2FA in a seamless fashion.
[0064] The server system 102 is a separate part of the environment 100, and may operate apart from (but still in communication with, for example, via the network 120) the payment server 114, the issuer server 116, the acquirer server 118, and any third party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 114, the issuer server 116, or the acquirer server 118. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 120, which may be specifically configured, via executable instructions, to perform as described herein, and/or embodied in at least one non-transitory computer-readable media. In one embodiment, the server system 102 is connected with a database 126. The database 126 is configured to store one or more of a list of merchants enrolled in the green channel program, interconnected transaction lists for a consecutive set of payment transactions when the green channel is activated, data elements associated with the interconnected list, a plurality of data fields associated with each data element and other necessary instructions for implementing the green channel program.
[0065] In one embodiment, the payment network 112 may be used by the payment card issuing authorities as a payment interchange network. The payment network 112 may include a plurality of payment servers such as, the payment server 114. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0066] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks, and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0067] FIGS. 2A-2C, collectively, are a sequence flow diagram 200 for enabling a cardholder authentication bypass channel for future payment transactions of the cardholder 106 at specific merchants, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0068] At 202, the cardholder 106 initiates an online payment transaction 'T1' on an application associated with a merchant 108a accessible on the user device 104. In an embodiment, the application may be any web-browser application that can be a mobile or desktop application and can be used to access a merchant website, third-party websites, or an application with an application programming interface (API) provided by the merchant 108a using which the cardholder 106 may purchase goods or services from a remote location. In an example, the cardholder 106 may select one or more products and/or services offered by the merchant 108a for purchase on the application. The cardholder 106 may then initiate the payment transaction 'T1' by pressing, for example, “pay”, “checkout” or “proceed to pay” on a user interface of the application.
[0069] At 204, on a payment checkout UI page, the merchant 108a facilitates provisioning an option for enabling a cardholder authentication bypass channel (i.e., "green channel") for the cardholder 106 on the user device 104 where the merchant 108a is already enrolled for a multi-merchant transaction authorization program or a green channel program. Further, on the payment checkout UI page, the cardholder 106 may be requested to enter card details of a payment card of the cardholder 106 and to perform cardholder authentication.
[0070] In other words, the user device 104 may load a UI for receiving consent from the cardholder 106 for enabling the cardholder authentication bypass channel for future payment transactions at specific merchants. For example, the merchant 108a or the issuer server 116 may provide an API on the user device 104 to enter cardholder preference for the cardholder authentication bypass channel for future payment transactions at the specific merchants that are already enrolled for the multi-merchant transaction authorization program or the green channel program.
[0071] At 206, the cardholder 106 may select a user-selectable icon on the payment checkout UI page to opt-in for the cardholder authentication bypass channel for future payment transactions.
[0072] At 208, after submitting the card details, the user device 104 may send a user consent message along with information of the payment transaction to an acquirer server 118 via the merchant 108a. The user consent message may include, but is not limited to, information of cardholder input and cardholder identification.
[0073] At 210, the acquirer server 118 may determine whether the merchant 108a is a part of a list of merchants who have already enrolled for the multi-merchant green channel transaction authorization program.
[0074] At 212, the acquirer server 118 or the merchant 108a may send a payment transaction request along with a cardholder authentication bypass channel enablement request i.e., a green channel enablement request for the cardholder 106 to the server system 102.
[0075] At 214, upon successful second-factor authentication process performed for the payment transaction 'T1', the server system 102 or a payment server 114 associated with a payment network 112 may tokenize payment card details and generate a payment token associated with the cardholder 106.
[0076] Upon receiving the green channel enablement request, at 216, the server system 102 captures device configuration data associated with the user device 104. The device configuration data may include, but is not limited to, configuration details of the web browser application and device profiling parameters of the user device 104.
[0077] At 218, the server system 102 generates a user device profile associated with the cardholder 106 based, at least in part, on the device configuration data of the user device 104. The device configuration data may include browser signature or unique browser biometric associated with the application executing in the user device 104 and the device profiling parameters. In an example, the user device 104 can be a mobile device with any operating system (OS) that has a merchant application installed on it. In another example, the user device 104 can be a desktop or a computer associated with the cardholder 106 that has a web-browser application installed on it.
[0078] In one embodiment, the browser signature when the user device 104 has a web-browser application installed on it includes information such as browser version, name, operating system, User-Agent (received as a part of User-agent header in the client request), accepted file types (in HTTP Accept header field), the locale, and language (in HTTP Accept-Language header field), the supported encoding types (in HTTP Accept-Encoding header field), supported character set (in HTTP Accept-Charset header field), system fonts, browser plugin details, Time zone offset, etc. The device profiling parameters may include information retrieved from various system related fields such as RAM, screen resolution, and canvas fingerprint-related data, among other hardware-level data such as but not limited to driver information, video card information, hardware concurrency data, user device memory data, GPU, and CPU parameters, etc.
[0079] In an alternate embodiment, the browser signature, when the user device 104 has a merchant application installed on it, includes information such as application version, name, mobile operating system, User-Agent (received as a part of User-agent header in the client request), accepted file types (in HTTP Accept header field), the locale, and language (in HTTP Accept-Language header field), the supported encoding types (in HTTP Accept-Encoding header field), supported character set (in HTTP Accept-Charset header field), supported color scheme, system fonts, application plugin details, Time zone offset, etc. The device profiling parameters may include information retrieved from various system related fields such as RAM, screen resolution, and canvas fingerprint-related data, among other hardware-level data such as but not limited to driver information, video card information, hardware concurrency data, user device memory data, GPU, and CPU parameters, etc. As noted above, the unique browser signature may be generated or accessed in response to the selection of the green channel enablement request option that the specific browser instance and the user device 104 are sought to be registered. The browser signature may be generated based on the header information in the received electronic request, while the device signature may be retrieved, for example, using a Flash Object embedded in the web page used for providing authentication information. In one embodiment, the server system 102 is configured to perform hashing operations over the browser signature and store the browser signature corresponding to user device profile portions of the cardholder 106 in the database 126.
[0080] At 220, the server system 102 initializes an interconnected transaction list for the cardholder 106 with the information of the payment transaction'T1'. In particular, the interconnected transaction list may be an ordered list of a plurality of data elements or blocks or bricks, where each block or brick is associated with a single payment transaction. Each brick contains a plurality of data fields. The plurality of data fields may include:
[0081] (a) a brick hash identification field: This field contains a hashed value of a complete brick (i.e., a hashed value of the next data fields (b) to (g), where the hash value is computed by the server system 102 based at least on the data fields (b) to (g)),
[0082] (b) a cardholder identification field: This field contains an identifier associated with the cardholder 106,
[0083] (c) user device profile data field (i.e., browser signature field): This field contains a hashed value of the browser signature of a web-browser application executing in the user device 104 and the device profiling parameters,
[0084] (d) merchant identification field: This field contains the merchant identifier of the merchant 108a,
[0085] (e) a payment token field: This field contains a value pointing to the payment token associated with the payment transaction 'T1' performed by the cardholder 106,
[0086] (f) a green channel status flag field: This field contains a value representing whether the green channel for the cardholder 106 is opted-in or not,
[0087] (g) a transaction response field: This field contains the payment authorization response of the payment transaction 'T1' from the issuer server 116, and
[0088] (h) a previous brick hash identification field: This field indicates a hash identification value of the previous block or brick in the interconnected transaction list. For genesis brick (or the first brick), it contains a null value.
[0089] Thus, the server system 102 may set the first data element of the interconnected transaction list based on the information of the payment transaction. For example, a cardholder identification field in the first data element is set as "cardholder A", and a browser signature field is set as the hash value calculated based on the browser signature of the web-browser application executing in the user device 104 while performing the payment transaction 'T1'.
[0090] At 222, the server system 102 may send a payment transaction authorization request message to an issuer server 116 associated with the cardholder 106. The payment transaction authorization request message may include information about the payment transaction 'T1' and a green channel request status flag for enabling the cardholder authentication bypass channel (i.e., green channel). In particular, the payment authorization request message may include a sample token for green channel creation in tokenized format along with conventional transaction data for the payment transaction 'T1'. For example, the sample token may include:
{
"TxnId": "1561533871082",
"BlockId": "Xa11031##",
"merchantId": "some_merchant_id"
"GreenChannelService": "Opted/NotOpted"
"Green channel initial validation Result": "Success",
"IssuerResponse": “Pass/Fail”,
}

[0091] At 224, the issuer server 116 may perform internal validation and risk analysis to determine whether the cardholder 106 should be allowed to facilitate payment transactions at specific merchants without repeated authentication process or not.
[0092] When the issuer server 116 confirms that the cardholder 106 can perform payment transactions at specific merchants without repeated authentication process, at 226, the issuer server 116 may further determine a green channel time window (i.e., a time period within which the cardholder 106 is allowed to perform payment transactions at specific merchants without repeated authentication process).
[0093] Further, the issuer server 116 may also set up a list of merchants where the payment transactions for the cardholder 106 can be facilitated without authentication. Additionally or alternatively, the issuer server 116 may set up a list of allowed merchant categories (maybe a list of allowed Merchant Category Code’s (MCC) where the payment transactions for the cardholder 106 can be facilitated without authentication
[0094] For example, the issuer server 116 may determine that a green channel window of 30 minutes may be allowed for the cardholder 106 and this access may only be provided by merchants related to bill payment-related activities, i.e., merchants with having a MCC for bill payment-related activities such as utility service providers. Further, the green channel time window may be determined by the issuer server 116 based on a plurality of factors such as, but not limited to, an Average Minimum Balance (AVB) of the cardholder 106, a cardholder profile, a credit risk score of the cardholder 106, a Merchant Category Code (MCC) of the merchant 108a, a transaction category, an amount of the first transaction, etc., among other suitable factors. Additionally, the merchants who may be allowed for the green channel transactions may be determined by the issuer server 116 based on an internal risk assessment. For example, merchants related to gambling activities may not be allowed by the issuer 116 to participate in the green channel associated with a particular cardholder during the green channel window, however, another cardholder may be allowed to transact with a merchant related to gambling activities during the green channel window.
[0095] In one embodiment, the issuer server 116 provides a user interface to the cardholder 106 to set up maximum and minimum transaction amounts for green channel payment transactions.
[0096] At 228, the server system 102 receives a payment authorization response message and an issuer response associated with the green channel enablement request for the cardholder 106, from the issuer server 116. In one example, the issuer server 116 may send the sample token updated with the issuer response associated with the green channel enablement request for the cardholder 106. In another example, the sample token may include at least the time period for the green channel window, the list of allowed merchants, and/or the list of allowed merchant categories.
[0097] At 230, the server system 102 may enable cardholder authentication bypass channel for the cardholder 106 at specific merchants for payment transactions within a particular time window (i.e., green channel time window).
[0098] At 232, the server system 102 may update the first data element in the interconnected transaction list based on the payment authorization response message and the issuer response. In particular, the server system 102 may update the transaction response field and the green channel status field of the first data element in the interconnected transaction list. For example, the transaction response field in the first data element is set as "Y" (i.e., ‘yes’ in this scenario as the transaction T1 is assumed to be a success), and the green channel status field is set as “Yes” indicating that the green channel program is enabled for the cardholder 106 for the green channel window. Thereafter, the server system 102 calculates a hash value of the complete block of the first data element and sets the brick hash identification field value of the block as the calculated hash value.
[0099] At 234, the server system 102 sends a notification to the user device 104 to inform that the green channel for future payment transactions is enabled for specific merchants.
[00100] FIGS. 3A and 3B, collectively, represent a sequence flow diagram 300 for performing a payment transaction at a registered merchant after enabling a cardholder authentication bypass channel for the cardholder 106, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00101] The sequence flow diagram 300 explains the process of performing a payment transaction at a registered merchant 108b after enabling the cardholder authentication bypass channel i.e., a green channel for the cardholder 106. The registered merchant 108b is already enrolled for the multi-merchant green channel transaction authorization program that is administered by the server system 102. As explained previously, the cardholder authentication bypass channel is already set up for the cardholder 106 after performing the payment transaction 'T1' at the merchant 108a.
[00102] At 302, the cardholder 106 initiates an online payment transaction 'T2' on a web-browser application associated with a merchant 108b accessible on the user device 104. The web-browser application can be a mobile or desktop application and can be used to access a merchant website, third-party websites, or an application with an application programming interface (API) provided by the merchant 108b using which the cardholder 106 may purchase goods or services from a remote location.
[00103] Since the cardholder authentication bypass channel is enabled for the cardholder 106, at 304, the cardholder 106 may select or click on a user-selectable option (e.g., “Pay via green channel route") for directly performing the payment transaction 'T2' via the cardholder authentication bypass channel. Additionally, on a payment checkout UI page, the merchant 108b or the payment server 114 facilitates an option for the cardholder 106 to proceed with the payment transaction 'T2' using a different payment method or card.
[00104] At 306, the user device 104 sends a payment transaction request for the cardholder 106 to the acquirer server 118 associated with the merchant 108b. In the illustrated example, the acquirer server 118 is depicted to be the same across the merchants 108a-108c, however, this should not be construed to be a limitation and a plurality of different acquires may engage in the multi-merchant green channel transaction authorization program simultaneously as well.
[00105] Upon intercepting that the merchant 108b is already enrolled for the multi-merchant green channel transaction authorization program, at 308, the acquirer server 118 sends a first green channel payment request of the payment transaction 'T2' to the server system 102. The first green channel payment request may include information of the payment transaction and a flag indicating that the payment transaction 'T2' is routed via the cardholder authentication bypass channel.
[00106] Upon receiving the flag indicating that the payment transaction 'T2' is routed via the cardholder authentication bypass channel, at 310, the server system 102 checks whether the merchant 108b is included in the plurality of merchants or MCCs where the cardholder 106 can perform payment transactions via the cardholder authentication bypass channel. For example, if the merchant 108b is related to special medical drugs or gambling activities and the issuer server 116 has already restricted the green channel for such MCCs, the server system 102 may not forward the first green channel payment request further and notify the cardholder 106 that the payment transaction at the merchant 108b may not be processed via the cardholder authentication bypass channel.
[00107] At 312, the server system 102 determines whether the first green channel payment request is received within the green channel time window (i.e., determines whether the green channel time window is active or not). If the first green channel payment request is received after the green channel time window, the server system 102 may not forward the first green channel payment request further and notify the cardholder 106 that the payment transaction at the merchant 108b may not be processed via the cardholder authentication bypass channel.
[00108] At 314, upon determining that the payment transaction 'T2' request is received within the green channel time window, the server system 102 generates user device profile data associated with the user device 104 while performing the payment transaction 'T2' based, at least in part, on captured device configuration data of the user device 104. As described earlier, the user device profile data may include browser signature or unique browser biometric associated with a web browser application executing in the user device 104 and the device profiling parameters. In one embodiment, the server system 102 is configured to perform hashing operations over the user device profile data and store it corresponding to user device profile portions of the cardholder 106 in the database 126.
[00109] At 316, the server system 102 appends the next data element i.e., a second data element in the interconnected transaction list of the cardholder 106. The second data element is connected with the first data element (i.e., genesis brick) by populating a previous brick hash identification field of the second data element with a brick hash identification value of the first data element.
[00110] At 318, the server system 102 accesses the content of the user device profile data field of a recent data element in the interconnected transaction list stored in the database 126. Since the payment transaction 'T2' is the first green channel payment request after initiating the green channel, the recent data element is pointed to the first data element in the interconnected transaction list.
[00111] At 320, the server system 102 matches the content of the user device profile data field of the recent data element (i.e., first data element) with the user device profile data generated while performing the payment transaction 'T2' determined at step 314. It is to be understood, that the server system 102 may compare hash values of the user device profile data of the first data element and the user device profile data generated at the step 314.
[00112] In one scenario, when the content of the user device profile data field of the current data element (i.e., first data element) is not matched with the user device profile data generated while performing the payment transaction 'T2', the server system 102 may not forward the payment transaction 'T2' for further processing and a flag is passed to the issuer server 116 to close the cardholder authentication bypass channel for the cardholder 106. Further, the server system 102 also deletes a chain of bricks included in the interconnected transaction list.
[00113] At 322, upon a successful match, the server system 102 may send a payment authorization request message to the issuer server 116. The payment authorization request message may include information of the payment transaction 'T2' and a flag for indicating that indicating that the payment transaction 'T2' is routed via the cardholder authentication bypass channel. In some embodiments, the payment authorization request message may be sent along with a sample token for indicating green channel payment transaction in tokenized format along with conventional transaction data for the payment transaction 'T2'. For example, the sample token may include:
{
"TxnId": "1561533871032",
"Block Id": "Xa13301##",
"merchant Id": "XYZGrocery"
"Green Channel Status Flag": "Opted"
"Green channel payment initial validation result": "Success",
"IssuerResponse": undefined,
}

[00114] The “green channel payment initial validation result” is indicated as "Success" based at least on different checks performed in steps 310, 312, and 320.
[00115] Thereafter, the issuer server 116 authorizes the payment transaction 'T2' based on the payment authorization request message and the sample token. In an alternate embodiment, the steps 310 and 312 may be performed by the issuer server 116.
[00116] At 324, the server system 102 receives a payment authorization response message from the issuer server 116.
[00117] When the payment transaction 'T2' is successfully authorized, at 326, the server system 102 may update one or more of a plurality of data fields of the second data element. For example, the payment token field of the second data element is populated with a payment token contained in a payment token field in the first data element, and the transaction response field of the second data element is set for indicating a successful payment transaction. Further, the server system 102 may calculate a hash value of the complete brick of the second data element and sets a brick hash identification field value of the second data element as the calculated hash value.
[00118] In a similar manner, the cardholder 106 can perform consecutive green channel payment transactions at different merchants without cardholder authentication till the green channel time window is not expired.
[00119] FIG. 4 is an example representation 400 of an interconnected transaction list associated with a cardholder, in accordance with an embodiment of the present disclosure. The interconnected transaction list includes a plurality of data elements (see, 402a, 402b…402n, where ‘n’ is a natural number). The term ‘data element’ is interchangeably referred to hereafter as ‘brick’. It is to be understood that each of the plurality of data elements of the interconnected transaction list represents a plurality of consecutive transactions that occur during a green channel time window. Each data element may include a plurality of data fields. In an example, the plurality of data fields may include a brick hash identification field, cardholder identification field, a previous brick hash identification field, a user device profile field, a green channel activation field, a merchant identification field, and a transaction response field. In various examples, other data fields such as a merchant characterization code (MCC) field, transaction amount field, green channel window field, etc., among other suitable fields may also be present within each of the plurality of data elements.
[00120] FIGS. 5A and 5B, collectively, represent a flow chart 500 for enabling a cardholder authentication bypass channel (i.e., green channel) for future payment transactions at specific merchants, in accordance with an embodiment of the present disclosure. The sequence of operations of the flow chart 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the flow chart 500, references may be made to elements described in FIG. 1.
[00121] The flow chart 500 explains the process of transaction flow for enabling cardholder authentication bypass channel (i.e., green channel) for future payment transactions of the cardholder 106 at specific merchants while performing a payment transaction at a first merchant (e.g., merchant 108a). The first merchant 108a is already enrolled or registered for a multi-merchant green channel transaction authorization program configured by the server system 102.
[00122] At 502, the server system 102 receives a payment transaction request for a first payment transaction and a green channel enablement request from an acquirer 118 associated with the first merchant 108a. The green channel enablement request is generated by the acquirer 118 upon receiving user consent for enabling the cardholder authentication bypass channel (i.e., green channel) for the cardholder 106 while performing the first payment transaction.
[00123] At 504, upon receiving the green channel enablement request, the server system 102 may access the first device configuration data of the user device 104 while performing the first payment transaction. The first device configuration data may include, but is not limited to, configuration details of the web browser application and device profiling parameters of the user device 104.
[00124] At 506, the server system 102 may generate user device profile data associated with the cardholder 106 based, at least in part, on the first device configuration data of the user device 104. The user device profile data may include browser signature or unique browser biometric associated with a web browser application executing in the user device 104 and the device profiling parameters. The browser signatures may include the following metrics: (i) User Agent from headers in client request (e.g., Chrome/96.0.4664.110 Safari/537.36), (ii) HTTP Accept Headers (e.g., text/html, */*; q=0.01 gzip, deflate, br en-US,EN; q=0.9), (iii) Browser plugin details, (iv) Timezone offset, time zone for figuring out location, (v) a list of system fonts (that is, in general, be consistent on the user device 104 and linked to a particular OS), (vi) information of Platform (OS), Video card hardware, video driver, Hardware concurrency and Device memory (RAM), (vii) screen resolution data and canvas fingerprint data.
[00125] An example pseudo-code for accessing screen resolution of the user device 104 is given below:
Define function for getting ScreenResolution
{
return (screen.height>screen.width)?[screen.height,screen.width] : [screen.width, screen.height];
}

[00126] Further, an example pseudo-code for generating canvas fingerprint data from the accessed application canvas-related data is given below:
{
Initiate variable canvas=document.createElement(‘canvas’);
Initiate var ctx = canvas.getContext(‘2d’);
Initiate var txt = "merchantWebsite 1.0";
ctx.textBaseline = "top";
ctx.font = "14px 'Courier New'";
ctx.textBaseline = "alphabetic";
ctx.fillStyle = "#f60";
ctx.fillRect(125,1,62,20);
ctx.fillStyle = "#034";
ctx.fillText(txt, 2, 15);
ctx.fillStyle = "rgba(221, 118, 9, 1.2)";
ctx.fillText(txt, 6, 18);
return canvas.toString();
}

[00127] In one embodiment, the server system 102 may perform hashing operation over the user device profile data. An example pseudo-code for generating a hash associated with the first user device profile data field is given below:
function hashCode(canvasString, screenresolution){
var hashValue=0;
if (canvasString.length ===0){
return hashValue;}
for(var j=0;j< canvasString.length;j++)
{ char = I * ( ( hashValues<<5)-hashValue)+char;
hashValue = hashValue & hashValue;
}
Return hashValue;
}

[00128] At 508, the server system 102 generates and stores an interconnected transaction list for the cardholder 106. The interconnected transaction list may include a consecutive set of payment transactions performed by the cardholder 106 after enabling a cardholder authentication bypass channel for the cardholder 106 and the first payment transaction. The interconnected transaction list is an ordered list of bricks or data elements where each brick or data element is associated with a single payment transaction. Each brick or data element contains a brick hash identification field, a green channel status flag field, a previous brick hash identification field of the previous brick, a payment token field associated with the cardholder, user device profile data field, a transaction response field, a merchant identification field, and a cardholder identification field.
[00129] At 510, the server system 102 sets a first data element of the interconnected transaction list based at least on the information of the first payment transaction. In particular, the payment token field of the first data element can be populated with a payment token of the cardholder 106 that is generated upon successful authentication of the cardholder 106 for the first payment transaction. The cardholder identification field and the merchant identification field of the first data element can also be populated based on information included in the payment transaction request. The user device profile data field of the first data element is populated with a hash value of the user device profile data (which is generated at step 508). The previous brick hash identification field of the first data element is set as a particular value (e.g., Null) since the first data element is a genesis brick. Further, the green channel status flag field of the first data element is set to a second value, where the second value represents that the cardholder authentication bypass channel (i.e., green channel) for the cardholder 106 is not enabled.
[00130] At 512, the server system 102 may send a payment authorization request message to an issuer server 116 for authorization processing and performing internal validation and risk analysis of the green channel enablement request initiated by the cardholder 106. The payment authorization request message may include information of the first payment transaction and a green channel request status flag for enabling the cardholder authentication bypass channel (i.e., green channel). In one embodiment, the server system 102 may a payment authorization request message and a sample token for the green channel creation to the issuer server 116.
[00131] At 514, the server system 102 receives a payment authorization response message and an issuer response associated with the green channel enablement request for the cardholder 106, from the issuer server 116.
[00132] At 516, the server system 102 checks whether the green channel enablement request for the cardholder 106 is approved or not. In one scenario, when the issuer server 116 confirms that the green channel enablement request for the cardholder 106 is approved, the issuer response may include a flag for indicating approval of the green channel enablement request, green channel time window set by the issuer server 116, and a plurality of merchants where the cardholder 106 can perform payment transactions through the cardholder authentication bypass channel.
[00133] When the green channel enablement request is approved, at 518, the server system 102 may initiate the cardholder authentication bypass channel for the cardholder 106 at specific merchants for payment transactions within a particular time window (i.e., green channel time window). In one embodiment, the server system 102 may send a notification regarding enablement of the cardholder authentication bypass channel along with payment transaction response of the first payment transaction, to the cardholder 106 via the acquirer server 118.
[00134] At 520, the server system 102 may update the first data element in the interconnected transaction list based on the payment authorization response message and the issuer response. In particular, the server system 102 may update the transaction response field and the green channel status field of the first data element in the interconnected transaction list. Thereafter, the server system 102 calculates a hash value of the complete block of the first data element and sets the brick hash identification field value of the first data element as the calculated hash value.
[00135] In another scenario, when the green channel enablement request is not approved, at 522, the server system 102 may destroy or delete the interconnected transaction list of the cardholder 106 from the database 126.
[00136] FIGS. 6A and 6B, collectively, represent a flow chart 600 for performing a payment transaction at a registered merchant after enabling cardholder authentication bypass channel for the cardholder 106, in accordance with an embodiment of the present disclosure. The sequence of operations of the flow chart 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. It is to be noted that to explain the flow chart 500, references may be made to elements described in FIG. 1.
[00137] The flow chart 600 explains a process of transaction flow for performing a second payment transaction at a second merchant 108b after enabling the cardholder authentication bypass channel i.e., a green channel for the cardholder 106. The second merchant 108b is already enrolled for multi-merchant green channel transaction authorization program that is administered by the server system 102.
[00138] At 602, the server system 102 receives a first green channel payment request for the cardholder 106 from the acquirer server 118 associated with the second merchant 108b. The first green channel payment request may include information of the payment transaction and a flag indicating that the second payment transaction is routed via the cardholder authentication bypass channel.
[00139] At 604, upon receiving the first green channel payment request, the server system 102 checks whether the second merchant 108b is included in a plurality of merchants or MCCs (i.e., allowed merchants for the cardholder) where the cardholder 106 can perform payment transactions via the cardholder authentication bypass channel.
[00140] When the second merchant is not included in the plurality of merchants or MCCs, at 606, the server system 102 denies or cancels the first green channel payment request and notifies the cardholder 106 that the second payment transaction at the merchant 108b may not be processed via the cardholder authentication bypass channel.
[00141] Otherwise, at 608, the server system 102 checks whether the first green channel payment request is received within a time window (i.e., the green channel time window) or not.
[00142] If the first green channel payment request is not received within the green channel time window, at 610, the server system 102 denies or cancels the first green channel payment request and notifies the cardholder 106 that the second payment transaction at the second merchant 108b may not be processed via the cardholder authentication bypass channel.
[00143] Otherwise, at 612, the server system 102 generates user device profile data associated with the cardholder 106 based, at least in part, on the second device configuration data of the user device 104 accessed during the second payment transaction.
[00144] At 614, the server system 102 appends the next data element i.e., a second data element in the interconnected transaction list of the cardholder 106. In one alternate embodiment, the step 614 can be executed upon performing step 618.
[00145] At 616, the server system 102 accesses the content of the user device profile data field of a recent data element (i.e., first data element) in the interconnected transaction list stored in the database 126.
[00146] At 618, the server system 102 matches the content of the user device profile data field of the recent data element (i.e., first data element) with the user device profile data generated while performing the second payment transaction 'T2' determined at step 612.
[00147] At 620, the server system 102 checks the matching result. On determining an unsuccessful match between the content of the user device profile data field of the recent data element (i.e., first data element) and the user device profile data generated while performing the second payment transaction, at 622, the server system 102 denies or cancels the second payment transaction and forwards a flag to the issuer server 116 to close the cardholder authentication bypass channel for the cardholder 106.
[00148] At 624, the server system 102 sends a payment authorization request message for the second payment transaction to the issuer server 116.
[00149] At 626, the server system 102 updates one or more of a plurality of data fields of the second data element based on a payment authorization response message received from the issuer server 116.
[00150] FIGS. 7A, 7B, and 7C, collectively, represent a series of exemplary user interfaces (UIs) implemented on a user device 104 to enable cardholder authentication bypass channel (i.e., green channel), in accordance with an embodiment of the present disclosure. The UI 700 includes a checkout page of an e-commerce website associated with a merchant (such as merchant 108a). In the illustrated example, the cardholder 106 is depicted to be booking a flight ticket from New York to Los Angeles. After the cardholder 106 selects the checkout option associated with the webpage of the e-commerce website, the webpage changes to a payment initiation page (see, user interface 720 represented by FIG. 7B) where the cardholder 106 provides their card details to initiate a first payment transaction (such as payment transaction ‘T1’). After initiating the first payment transaction, the webpage changes to a payment gateway webpage (see, the payment user interface 740 represented by FIG. 7C) where the cardholder 106 is requested to enter their credentials such as a one-time password associated with the payment transaction ‘T1’ or any other suitable two-factor authentication (2FA) related credential. Further, the UI 740 includes an option (see, 742) for the cardholder 106 to enable the green channel program.
[00151] FIG. 7D represents an exemplary graphical user interface (GUI) implemented on the user device 104 engaged in a second payment transaction when the cardholder authentication bypass channel (i.e., green channel) is enabled, in accordance with an embodiment of the present disclosure. The UI 760 includes a green channel payment option (see, 762) for the cardholder 106 to directly complete the payment without the need to provide any credentials or card details. In the illustrated example, the second payment transaction (such as payment transaction ‘T2‘) can directly be completed by the cardholder 106 by selecting the ‘Pay through green channel program’ button. The UI 760 further includes a checkout option, the cardholder 106 may select this option to complete the second payment transaction using a different payment method such as, cash on delivery, another payment card, net banking, etc., among other suitable payment methods.
[00152] It is to be understood, that although the UI 760 depicts user-selectable icons, however, this should not be construed to be a limitation and other suitable techniques may also be used to enable the green channel.
[00153] FIG. 8 represents a flow diagram of a computer-implemented method 800 for enabling a cardholder authentication bypass channel for a cardholder 106, in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by the server system (such as server system 102) which may be a standalone server or a server as a whole incorporated into another server system. In another embodiment, the method 800 depicted in the flow diagram may be executed by the payment server 114 which may be standalone server or a server as whole incorporated in another server system. Operations of the method 800, and combinations of operation in the method 800, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions.
[00154] In certain implementations, the method 800 may be performed by a single processing thread. Alternatively, the method 800 may be performed by two or more processing threads, each processing thread implementing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing the method 800 may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing the method 800 may be executed asynchronously with respect to each other. The method 800 starts at operation 802.
[00155] At 802, the method 800 includes receiving, by a server system 102, one or more electronic requests from a user device 104 associated with a cardholder 106. In an embodiment, the one or more electronic requests may include a first payment transaction request to perform a first payment transaction (such as payment transaction T1) to a first merchant (such as merchant 108a), and a green channel enablement request. In one example, the one or more electronics requests may be generated by an acquirer server (such as acquirer 118) associated with the first merchant 108a in response to receiving a user consent message shared by the cardholder 106 to the acquirer 118 for enabling the green channel.
[00156] At 804, the method 800 includes accessing, by the server system 102, a first device configuration data of the user device 104 associated with the cardholder 106 during the first payment transaction. In an embodiment, the server system 102 may capture the device configuration data to generate a user device profile data associated with the cardholder 106.
[00157] At 806, the method 800 includes setting, by the server system 102, a plurality of data fields associated with the first payment transaction that is included within a first data element of an interconnected transaction list. The interconnected transaction list stored in a database 126 includes a consecutive set of payment transactions performed by the cardholder 106 after enabling a cardholder authentication bypass channel (i.e., the green channel) for the cardholder 106. It is to be understood, that the plurality of data fields associated with the first data element includes a brick hash identification field, a green channel status flag field, and a previous brick hash identification field. In an embodiment, the plurality of data fields further includes a payment token field associated with the cardholder 106, user device profile data field, a transaction response field, a merchant identification field, and a cardholder identification field.
[00158] At 808, the method 800 includes transmitting, by the server system 102, a payment authorization request message associated with the first payment transaction to an issuer server 116 associated with the cardholder 106. The payment authorization request message includes information associated with the first payment transaction, and a value stored in the green channel status flag field of the first data element.
[00159] At 810, the method 800 includes initiating, by the server system 102, the cardholder authentication bypass channel for the cardholder 106 based, at least in part, on a payment authorization response message received from the issuer server 116. In an embodiment, the cardholder authentication bypass channel facilitates the consecutive set of payment transactions across a plurality of merchants (such as 108a-108c) without repetitive cardholder authentication.
[00160] At 812, the method 800 includes updating, by the server system 102, one or more of the plurality of data fields of the first data element in the interconnected transaction list based, at least in part, on the payment authorization response message.
[00161] FIG. 9 is a flow diagram of a computer-implemented method 900 for performing a second payment transaction at a registered merchant when the cardholder authentication bypass channel for a cardholder 106 is enabled, in accordance with an embodiment of the present disclosure. The method 900 depicted in the flow diagram may be executed by the server system (such as server system 102) which may be a standalone server or a server as wholly incorporated in another server system. In another embodiment, the method 900 depicted in the flow diagram may be executed by the payment server 114 which may be standalone server or a server as whole incorporated in another server system. Operations of the method 900, and combinations of operation in the method 900, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions.
[00162] In certain implementations, the method 900 may be performed by a single processing thread. Alternatively, the method 900 may be performed by two or more processing threads, each processing thread implementing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing the method 900 may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing the method 900 may be executed asynchronously with respect to each other. The method 900 starts at operation 902.
[00163] At 902, the method 900 includes receiving, by the server system 102, a first green channel payment request to perform a second payment transaction for the cardholder 106 to a second merchant of the plurality of merchants 108a-108c. The second payment transaction routed via the cardholder authentication bypass channel of the cardholder 106.
[00164] At 904, the method 900 includes determining, by the server system 102, whether the first green channel payment request is received within the green channel time window or not. In an embodiment, the green channel time window is determined by the issuer server 116 based on an internal risk assessment and shared with the server system 102 via the payment authorization response message.
[00165] At 906, in response to determining that the first green channel payment request is received within the green channel time window, the method 900 includes generating, by the server system 102, a user device profile data based, at least in part, on second device configuration data of the user device 104 during the second payment transaction.
[00166] At 908, the method 900 includes appending, by the server system 102, a second data element in the interconnected transaction list of the cardholder 106. In an embodiment, the previous brick hash identification field of the second data element is set as a value of the brick hash identification field of the first data element.
[00167] At 910, the method 900 includes matching, by the server system 102, the content of the user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction.
[00168] At 912, in response to a successful match between the content of the user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction, the method 900 includes sending, by the server system 102, a payment authorization request message to the issuer server 116.
[00169] At 914, the method 900 includes updating, by the server system 102, the second data element based, at least in part, on a payment authorization response message received from the issuer server 116.
[00170] Referring now to FIG. 10, a simplified block diagram of a server system 1000 is shown, in accordance with an embodiment of the present disclosure. The server system 1000 is similar to the server system 102. In some embodiments, the server system 1000 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
[00171] In one embodiment, the server system 1000 includes a computer system 1002 and a database 1004. The computer system 1002 includes at least one processor 1006 for executing instructions, a memory 1008, and a communication interface 1010. The one or more components of the computer system 1002 communicate with each other via a bus 1012.
[00172] In some embodiments, the database 1004 is integrated within computer system 1002. For example, the computer system 1002 may include one or more hard disk drives as the database 1004. A storage interface 1014 is any component capable of providing the processor 1006 with access to the database 1004. The storage interface 1014 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 1006 with access to the database 1004. In one embodiment, the database 1004 is configured to store consent tokens of users and encrypted payment credential data associated with the consent tokens.
[00173] The processor 1006 includes suitable logic, circuitry, and/or interfaces to execute computer-readable instructions for managing and sharing user consent among multiple applications installed on a user device. Examples of the processor 1006 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphical processing unit (GPU) processor, a field-programmable gate array (FPGA), and the like. The memory 1008 includes suitable logic, circuitry, and/or interfaces to store a set of computer readable instructions for performing operations. Examples of the memory 1008 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 1008 in the server system 1000, as described herein. In another embodiment, the memory 1008 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 1000, without departing from the scope of the present disclosure.
[00174] The processor 1006 is operatively coupled to the communication interface 1010 such that the processor 1006 is capable of communicating with a remote device 1016, or communicating with any entity connected to the network 120 (as shown in FIG. 1). It is noted that the server system 1000 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 1000 may include fewer or more components than those depicted in FIG. 10.
[00175] FIG. 11 is a simplified block diagram of a payment server 1100, in accordance with an embodiment of the present disclosure. The payment server 1100 is an example of the payment server 114 of FIG. 1. A payment network may be used by the payment server 1100 as a payment interchange network. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The payment server 1100 includes a processing system 1105 configured to extract programming instructions from a memory 1110 to provide various features of the present disclosure. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1100 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof. In one embodiment, the payment server 1100 is configured to determine authenticity of the payment card based on the card image and send a payment transaction request to the issuer server 116 via the acquirer server 118 and the payment network 112.
[00176] Via a communication interface 1115, the processing system 1105 receives a payment authorization request from a remote device 1120 such as the server system 102, the acquirer server 118, or administrators managing server activities. The payment server 1100 may also perform similar operations as performed by the server system 102. For the sake of brevity, the detailed explanation of the payment server 1100 is omitted herein with reference to FIG. 11.
[00177] FIG. 12 is a simplified block diagram of a user device 1200 for example a mobile phone or a desktop computer capable of implementing the various embodiments of the present disclosure. For example, the user device 1200 may correspond to the user device 104 of FIG. 1. In one embodiment, for example, the user device 1200 may correspond to the user device 104 of FIG. 1. The user device 1200 is depicted to include one or more applications such as the applications 1206. In one embodiment, the applications 1206 comprise the first application and the second application. In another embodiment, the applications 1206 comprise the first merchant application and the second merchant application. The applications 1206 can be an instance of an application downloaded from a third-party server or a merchant server. In an embodiment the as the applications 1206 is capable of communicating with the server system 102 for facilitating transaction processing. In another embodiment the as the applications 1206 is capable of communicating with the server system 204 for facilitating payment transaction processing.
[00178] It should be understood that the user device 1200 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the user device 1200 may be optional and thus in an embodiment may include more, less or different components than those described in connection with the embodiment of the FIG. 12. As such, among other examples, the user device 1200 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00179] The illustrated user device 1200 includes a controller or a processor 1202 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1204 controls the allocation and usage of the components of the user device 1200 and support for one or more payment applications programs (see, applications 1206) such as the payment gateway application and merchant applications, that implements one or more of the innovative features described herein. In addition, applications 1206 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, and messaging applications) or any other computing application.
[00180] The illustrated user device 1200 includes one or more memory components, for example, a non-removable memory 1208 and/or removable memory 1210. The non-removable memory 1208 and/or the removable memory 1210 may be collectively known as a database in an embodiment. The non-removable memory 1208 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1210 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1204 and applications 1206. The user device 1200 may further include a user identity module (UIM) 1212. The UIM 1212 may be a memory device having a processor built in. The UIM 1212 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1212 typically stores information elements related to a mobile subscriber. The UIM 1212 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA11000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00181] The user device 1200 can support one or more input devices 1220 and one or more output devices 1230. Examples of the input devices 1220 may include, but are not limited to, a touch screen/a display screen 1222 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1224 (e.g., capable of capturing voice input), a camera module 1226 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1228. Examples of the output devices 1230 may include, but are not limited to a speaker 1232 and a display 1234. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1222 and the display 1234 can be combined into a single input/output device.
[00182] A wireless modem 1240 can be coupled to one or more antennas (not shown in the FIG. 12) and can support two-way communications between the processor 1202 and external devices, as is well understood in the art. The wireless modem 1240 is shown generically and can include, for example, a cellular modem 1242 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1244 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1246. The wireless modem 1240 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the user device 1200 and a public switched telephone network (PSTN).
[00183] The user device 1200 can further include one or more input/output ports 1250, a power supply 1252, one or more sensors 1254 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the user device 1200 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1256 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1260, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00184] The disclosed methods with reference to FIGS. 8 and 9, or one or more operations of the server system 102 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means includes, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00185] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal-oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00186] Particularly, the server system 102 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00187] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00188] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:CLAIMS
We claim:

1. A computer-implemented method, comprising:
receiving, by a server system, one or more electronic requests from a user device associated with a cardholder, the one or more electronic requests comprising a first payment transaction request to perform a first payment transaction to a first merchant, and a green channel enablement request;
accessing, by the server system, a first device configuration data of the user device during the first payment transaction;
setting, by the server system, a plurality of data fields associated with the first payment transaction that is included within an interconnected transaction list as a first data element, the interconnected transaction list stored in a database comprising a consecutive set of payment transactions performed by the cardholder after enabling a cardholder authentication bypass channel for the cardholder, the plurality of data fields associated with the first data element comprising a brick hash identification field, a green channel status flag field, and a previous brick hash identification field;
transmitting, by the server system, a payment authorization request message associated with the first payment transaction to an issuer server associated with the cardholder, the payment authorization request message comprising an information associated with the first payment transaction, and a value stored in the green channel status flag field of the first data element;
initiating, by the server system, the cardholder authentication bypass channel for the cardholder based, at least in part, on a payment authorization response message received from the issuer server, the cardholder authentication bypass channel facilitating the consecutive set of payment transactions across a plurality of merchants without repetitive cardholder authentication; and
updating, by the server system, one or more of the plurality of data fields of the first data element in the interconnected transaction list based, at least in part, on the payment authorization response message.

2. The computer-implemented method as claimed in claim 1, wherein the plurality of data fields further comprises a payment token field associated with the cardholder, user device profile data field, a transaction response field, a merchant identification field, and a cardholder identification field.

3. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, user device profile data associated with the user device of the cardholder based, at least in part, on the first device configuration data, the user device profile data comprising information of a browser signature of an application executing in the user device while performing the first payment transaction, and device profiling parameters of the user device; and
setting, by the server system, the user device profile data field as the user device profile data associated with the user device.

4. The computer-implemented method as claimed in claim 3, wherein the browser signature and the device profiling parameters comprise at least browser plugin details, screen resolution data and canvas fingerprint data.

5. The computer-implemented method as claimed in claim 1, wherein updating one or more of plurality of data fields comprises:
setting, by the server system, the green channel status flag field to a first value, wherein the first value represents enablement of the cardholder authentication bypass channel;
setting, by the server system, the transaction response field based, at least in part, on the payment authorization response message;
calculating, by the server system, a hash value of the first data element based, at least in part, on the plurality of data fields; and
setting, by the server system, the brick hash identification field of the first data element to the calculated hash value.

6. The computer-implemented method as claimed in claim 1, wherein the cardholder authentication bypass channel is enabled for a green channel time window, and wherein the plurality of merchants is already enrolled for multi-merchant green channel transaction authorization program administrated by the server system.

7. The computer-implemented method as claimed in claim 6, further comprising:
receiving, by the server system, a first green channel payment request to perform a second payment transaction for the cardholder to a second merchant of the plurality of merchants, the second payment transaction routed via the cardholder authentication bypass channel of the cardholder;
determining, by the server system, whether the first green channel payment request is received within the green channel time window or not;
in response to determining that the first green channel payment request is received within the green channel time window, generating, by the server system, user device profile data based, at least in part, on second device configuration data of the user device during the second payment transaction;
appending, by the server system, a second data element in the interconnected transaction list of the cardholder, wherein previous brick hash identification field of the second data element is set as a value of the brick hash identification field of the first data element; and
matching, by the server system, a content of user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction.

8. The computer-implemented method as claimed in claim 7, further comprising:
in response to a successful match between the content of user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction, sending, by the server system, a payment authorization request message to the issuer server; and
updating, by the server system, the second data element based, at least in part, on a payment authorization response message received from the issuer server.

9. The computer-implemented method as claimed in claim 7, further comprising:
in response to an unsuccessful match between the content of user device profile data field associated with the first data element and the user device profile data generated during the second payment transaction, sending, by the server system, a flag to the issuer server for closing the cardholder authentication bypass channel of the cardholder; and
deleting, by the server system, the interconnected transaction list of the cardholder from the database.

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

11. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.