Claims:CLAIMS
We claim:

1. A computer-implemented method for obtaining real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder, the computer-implemented method comprising:
receiving, by a server system, a payment authorization request message for a payment transaction associated with a cardholder, the payment transaction initiated via an application accessible on a cardholder device of the cardholder;
determining, by the server system, whether the payment transaction requires a predefined card control to be enabled by the cardholder to process the payment transaction;
in response to determining that the payment transaction requires the predefined card control to be enabled, generating, by the server system, a wait response message indicating placing the payment transaction on hold;
transmitting, by the server system, a consent request message for enabling the predefined card control to the cardholder device, the consent request message encrypted using a combination of merchant public key and a user private key of the cardholder;
receiving, by the server system, a consent response message from the cardholder device associated with the cardholder, the consent response message comprising a cardholder input in response to the consent request message;
determining, by the server system, whether the cardholder opts-in the predefined card control or not based, at least in part, on the consent response message; and
facilitating, by the server system, the payment transaction based, at least in part, on the determining step.

2. The computer-implemented method as claimed in claim 1, wherein the consent request message comprises an opt-in service identifier data field, an opt-in choice data field, and a transaction amount data field, and wherein the consent request message is decrypted using the user private key at the cardholder device.

3. The computer-implemented method as claimed in claim 1, wherein the consent response message comprises an opt-in service identifier corresponding to the predefined card control and the cardholder input included in an opt-in choice data field.

4. The computer-implemented method as claimed in claim 3, further comprising:
validating, by the server system, the consent response message received from the cardholder, the consent response message validated by matching the opt-in service identifier of the consent response message with stored opt-in service identifier of the predefined card control.

5. The computer-implemented method as claimed in claim 3, wherein determining whether the cardholder opts-in the predefined card control or not comprises:
comparing, by the server system, a value in the opt-in choice data field of the consent response message with a particular data value.

6. The computer-implemented method as claimed in claim 5, further comprising:
authorizing, by the server system, the payment transaction when the value in the opt-in choice data field of the consent response message is equal to the particular data value; and
declining, by the server system, the payment transaction when the value in the opt-in choice data field of the consent response message is not equal to the particular data value.

7. The computer-implemented method as claimed in claim 6, further comprising:
in response to authorizing the payment transaction, storing, by the server system, the value in the opt-in choice data field of the consent response message corresponding to the predefined card control for the cardholder in a database, wherein the stored value is utilized for authorizing future transactions associated with the cardholder.

8. The computer-implemented method as claimed in claim 1, further comprising:
facilitating, by the server system, an actionable button for enabling the predefined card control on a user interface associated with the application, wherein the actionable button is accessed by the cardholder upon providing the user private key.

9. The computer-implemented method as claimed in claim 1, wherein the server system is an issuer server associated with the cardholder.

10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.
, 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 OBTAINING REAL-TIME CARDHOLDER INPUT FOR CARD CONTROLS IN ONLINE PAYMENT PROCESSING

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 OBTAINING REAL-TIME CARDHOLDER INPUT FOR CARD CONTROLS IN ONLINE PAYMENT PROCESSING

TECHNICAL FIELD
[0001] The present disclosure generally relates to an electronic payment technology and, more particularly to, electronic methods and systems for obtaining real-time cardholder input for predefined card controls in processing online payment transactions.

BACKGROUND
[0002] Nowadays a huge volume of electronic payment transactions is either performed by customer’s mobile devices or by using several payment cards such as credit cards, debit cards, prepaid cards, etc., for performing payment transactions. The payment cards are increasingly used for making payments through various channels such as physical card swipe at point-of-sale (POS) terminals, digital payments, contactless payments, etc. The digital payment industry is moving towards providing a better experience for both customers and merchants. Customers can digitize the payment cards into mobile phones, wearable devices, etc., using technologies, such as tokenization, Card-on-File (COF) transactions, digital wallets, and the like.
[0003] The payment cards issued by issuers have a plurality of card controls (such as, control on e-commerce transactions, control on international transactions, etc.) that can be enabled by the cardholders or the issuers. Earlier, some card controls were enabled by the issuers by default. But currently, regulators have mandated disabling of the plurality of card controls for a payment card while issuing the payment card and require the cardholder to manually opt-in the card controls so that fraudulent transactions can be minimized. For example, the Reserve Bank of India (RBI), India’s central bank have made it mandatory for a cardholder to opt-in for a transaction service (e.g., digital payment transactions like e-commerce/ NFC/ ATM/ cross-border etc.) that the cardholder would like to have on his/her payment card. The cardholder voluntarily has to visit the issuer bank’s website, call the bank, or go to the nearest issuer branch to turn on these opt-in transaction services.
[0004] Although there has been a huge surge in e-commerce transactions, there have also been huge transaction declines due to this mandate, primarily because the cardholders are either not aware of such a mandate or they are not willing to take the hassle of visiting the bank or logging into the bank’s website to choose such opt-ins. The above methodologies result in the cardholder opting for alternate modes of payments such as Unified Payment Interface (UPI) or cash, ultimately leading to huge losses to card transactions and the payment networks. Though the issuers are making an effort to send information SMS messages to curb such declines, these controls are completely outside the preview of the issuers, and the acquirers or the merchants.
[0005] Thus, there exists a technological need to overcome the above-stated limitations.

SUMMARY
[0006] Various embodiments of the present disclosure provide methods and systems for obtaining real-time cardholder input for predefined card controls for processing online payment transactions.
[0007] In an embodiment, a computer-implemented method for obtaining real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder is disclosed. The computer-implemented method performed by a server system includes receiving a payment authorization request message for a payment transaction associated with a cardholder. The payment transaction is initiated via an application accessible on a cardholder device of the cardholder. The method includes determining whether the payment transaction requires a predefined card control to be enabled by the cardholder to process the payment transaction. The method includes generating a wait response message indicating placing the payment transaction on hold in response to determining that the payment transaction requires the predefined card control to be enabled. The method includes transmitting a consent request message for enabling the predefined card control to the cardholder device. The consent request message is encrypted using a combination of a merchant public key and a user private key of the cardholder. The method includes receiving a consent response message from the cardholder device associated with the cardholder. The consent response message includes cardholder input in response to the consent request message. The method includes determining whether the cardholder opts-in the predefined card control or not based, at least in part, on the consent response message. The method includes facilitating the payment transaction based, at least in part, on the determining step.

BRIEF DESCRIPTION OF THE FIGURES
[0008] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0009] FIG. 1 is an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0010] FIGS. 2A and 2B, collectively, represent a sequence flow diagram for obtaining real-time cardholder approval for payment transactions associated with a payment card of the cardholder, in accordance with an embodiment of the present disclosure;
[0011] FIGS. 3A and 3B, collectively, represent a flowchart of a process flow for obtaining real-time cardholder authentication for enabling card controls for online transactions associated with a cardholder, in accordance with an embodiment of the present disclosure;
[0012] FIGS. 4A, 4B, 4C, and 4D collectively, represent a series of exemplary graphical user interfaces (GUIs) implemented on a cardholder device to obtain real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder, in accordance with an embodiment of the present disclosure;
[0013] FIG. 5 represents a flow diagram of a computer-implemented method for obtaining real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder, in accordance with an embodiment of the present disclosure;
[0014] FIG. 6 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0015] FIG. 7 is a simplified block diagram of an issuer server, in accordance with one embodiment of the present disclosure; and
[0016] FIG. 8 is a simplified block diagram of a cardholder device capable of implementing the various embodiments of the present disclosure.
[0017] 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
[0018] 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.
[0019] 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 are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0020] 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.
[0021] The term “issuer”, used throughout the description, refers to a financial institution normally called as 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 as “issuer server” throughout the description.
[0022] 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.
[0023] 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.
[0024] The term “payment network”, used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be 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.
[0025] 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 cardholder 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.
[0026] 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.
OVERVIEW
[0027] Various example embodiments of the present disclosure provide methods, systems, user devices, and computer program products for obtaining real-time cardholder input for a predefined card control for processing a payment transaction associated with a payment card of a cardholder. More specifically, techniques disclosed herein enable cardholders to enable card controls in real-time during the payment transaction to avoid declines of payment transactions.
[0028] Now-a-days, online transactions are facing high decline rates because of the non-enablement of one or more card controls on payment cards of cardholders. Further, in some markets, regulators may mandate cardholder opt-in for digital transactions. The cardholders must opt-in for the transaction service that they would like to have on their payment cards. All cards that are issued by the issuer have all card controls turned off. The cardholder voluntarily and manually needs to visit the bank’s website/call the bank or go to the nearest branch to switch on these opt-in features such as e-commerce/ NFC/ ATM/ cross-border etc. Such regulation is directed at reducing online fraud, but often at the expense of customer and merchant satisfaction. For example, forcing customers to enable the payment card controls manually for completing the online transactions within that market increases friction in online purchasing environments, leading to increased rates of abandonment due to the customers’ frustrations.
[0029] At least one of the technical problems addressed by the present disclosure includes high decline rates for payment transactions due to the manual process of enabling card controls.
[0030] To overcome such problems or limitations, the present disclosure describes a server system that is configured to perform real-time cardholder opt-in for predefined card control during payment transactions within merchant applications or wallet applications. In one embodiment, the server system is an issuer server.
[0031] In one embodiment, the server system is configured to receive a payment authorization request message for a payment transaction from a cardholder device of the cardholder via an acquirer server of a merchant involved in the payment transaction. The payment authorization request message is initiated via an application (e.g., wallet application, merchant application, etc.) accessible on the cardholder device. The server system is configured to determine a set of transaction parameters associated with the payment authorization request message and determine whether the payment transaction requires a particular card control to be enabled by the cardholder or not, to process the payment transaction. In other words, when the probable reason of decline of the payment transaction is because of disabled card control, the server system is configured to hold the authorization process of the payment transaction. In particular, the server system is configured to generate a wait response message to inform the merchant about delaying the authorization process of the payment transaction.
[0032] To obtain real-time approval to enable the particular card control, the server system is configured to generate a consent request message including opt-in service identifier data field, opt-in choice data field, transaction amount data field, merchant identifier, etc. The consent request message is also encrypted using a combination of merchant public key and user private key of the cardholder. The server system is configured to send the consent request message to the merchant which partially decrypts the consent request message and forwards the partially decrypted consent request message to the cardholder device that is displayed on the application.
[0033] In one embodiment, the server system is configured to prompt the cardholder to input the user private key to access the consent request message on a user interface of the application. When the cardholder does not enter the correct user private key, the consent request message is not decrypted and a consent response message with blank data in the opt-in choice data field is forwarded to the server system after a threshold number of input trials. In such a scenario, the server system is configured to decline the payment transaction.
[0034] When the cardholder enters the correct user private key, the consent request message is decrypted and information of the particular card control that needs to be enabled for the payment transaction is displayed on the user interface on the application. Further, actionable buttons are also rendered or displayed to allow and deny enablement of the particular card control for the cardholder.
[0035] In one embodiment, when the cardholder selects an actionable button to enable the particular card control, the cardholder device sends a consent response message indicating enablement of the particular card control for the cardholder. Thereafter, the server system is configured to authorize the payment transaction and store opt-in choice data indicating enable of the particular card control for the cardholder for future transactions in a database.
[0036] In another embodiment, when the cardholder selects an actionable button to deny enable of the particular card control, the cardholder device sends a consent response message indicating disabling of the particular card control for the cardholder. Thereafter, the server system is configured to decline the payment transaction.
[0037] Various embodiments of the present disclosure offer multiple technical advantages and technical effects. For instance, the present disclosure eliminates need for manual opt-ins for card controls where the cardholder had to visit the bank or website associated with the bank to opt-in for card controls. The present disclosure enables lesser payment transaction declines as a cardholder can perform real-time opt-ins for card controls on a merchant application or a wallet application. The present disclosure provides an end-to-end digital experience without any manual intervention. The present disclosure enables easy and faster means of opting-in for the card controls to facilitate payment transactions. The present disclosure can be extended to all e-commerce transactions with minor modifications. Further, the present disclosure enables to ensure cardholder stickiness to payment card transactions without resorting to other digital channels (e.g., UPI) or use of cash.
[0038] 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, fraud is a significant problem for transactions conducted over an electronic payment network, especially for card-not-present transactions. Therefore, the present disclosure provides consumer authentication system to opt-in card controls for reducing frauds in payments such that approval rates for payment transactions are increased.
[0039] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 8.
[0040] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example 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, obtaining real-time cardholder input for enabling predefined card controls in online payment transactions. The environment 100 generally includes a server system 102, a cardholder device 104 associated with a cardholder 106, a merchant 108, a payment network 110 including a payment server 112, an issuer server 114, an acquirer server 116, a wallet service provider 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.
[0041] 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 merchant 108, the payment server 112, the issuer server 114, the acquirer server 116, the wallet service provider 118 and the cardholder device 104 may communicate.
[0042] In one embodiment, the cardholder 106 may be any individual, representative of a corporate entity, non-profit organization, or any other person. Examples of the cardholder device 104 associated with the cardholder 106 may include, without limitation, smart phone, tablet computer, other handheld computers, wearable devices, laptop computers, desktop computers, servers, portable media players, gaming devices, and so forth. The cardholder device 104 may be installed with an application 122. Examples of the application 122 include merchant application associated with a merchant (e.g., merchant 108) and a digital wallet application associated with the wallet service provider 118. In one embodiment, the cardholder device 104 may be installed with the application 122 that is configured to integrate various APIs for performing payment transactions with the merchant 108. The term “application” is used broadly to include any software program(s) capable of implementing the features described herein.
[0043] In some embodiments, the application 122 may include any 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, wallet service provider 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 include or be configured to obtain stored information including cardholder private key, payment credentials, third party keys, mobile gateway credentials, and may be capable of communicating with an issuer to obtain issuer updates.
[0044] In one embodiment, the issuer server 114 is a financial institution that manages payment accounts of multiple cardholders. Account details of the payment accounts established with the issuer server 114 are stored in cardholder profiles of the cardholders in a memory of the issuer server 114 or on a cloud server associated with the issuer server 114. The issuer server 114 approves or denies an authorization request, and then routes, via the payment network 110, an authorization response back to the acquirer server 116. The acquirer server 116 sends the approval to the merchant 108. The account details may include an account balance, an available credit line, details of an account holder, transaction history of the cardholder, account information, or the like. The details of the cardholder may include name, age, gender, physical attributes, registered contact number, alternate contact number, registered e-mail ID, or the like of the cardholder. The payment account of the cardholder may be associated with one or more payment means that enable the cardholder to facilitate the payment transaction. Examples of one or more payment means may include, payment card, Unified Payment Interface (UPI) links, and/or the like. Methods for processing transactions via the issuer server 114 will be apparent to a person of ordinary skill in the art and may include processing the transactions via the traditional four-party system.
[0045] In one embodiment, the issuer server 114 may manage a set of predefined card or account controls for the cardholder 106, where some card controls are enabled upon issuing the payment card or the payment account by default. Some card controls are disabled initially and can be enabled upon receiving cardholder’s approvals. Examples of the set of predefined card controls, which may be checked during authorization process, may include, but are not limited to, a limit on contactless transactions (i.e., card-not-present transactions), a block on specific types of transactions, such as blocking E-commerce, MCC, group of MCCs, and/or ATM transactions; a limit on the geographic use of the payment card based on the type of transaction, e.g., block non-domestic ATM transactions; a limit on the days of the week when a payment card may be used, such as the payment card may only be used Monday through Friday; and/or, a limit on the time of the day when a payment card may be used, e.g., block use between the hours of 1 AM and 5 AM. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
[0046] In one embodiment, the merchant 108 represents authorized accepter of payment cards for the payments for good/services sold by the merchant. In one embodiment, the acquirer server 116 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, 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.
[0047] 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 108 on the cardholder device 104 and initiates the transaction with the merchant 108. The cardholder device 104 reads the payment card information and extracts merchant account information to generate a payment authorization request message. The payment authorization request message typically includes payment card account number, 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 114 that issued the cardholder’s payment card.
[0048] In one scenario (not in accordance with the present disclosure), the issuer server 114 is configured to decline the payment transaction upon determining that a particular card control required to process the payment transaction is not enabled for the cardholder 106.
[0049] In one embodiment, the server system 102 is configured to perform one or more operations described herein. In one example, the server system 102 coupled with a database is embodied in the payment network 112. In another example, the server system 102 is a part of the issuer server 114. In general, the server system 102 is configured to facilitate card control opt-in for the cardholder 106 in real-time during payment transactions within the application 122 so that the payment transactions are not declined. The server system 102 is configured in a manner (described in connection with next set of figures) that enables the cardholder 106 to opt-in card control in real time while transacting with the merchant 108. Thus, the server system 102 is configured to facilitate creation of a consent message requesting the cardholder 106 to provide a response by opting for a desired card control option to proceed with the payment transaction. 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 112, the issuer server 114, the acquirer server 116, 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 112, the issuer server 114, or the acquirer server 116. 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 124.
[0050] In one embodiment, the payment network 110 may be used by the payment cards issuing authorities as a payment interchange network. The payment network 110 may include a plurality of payment servers such as, the payment server 112. 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.).
[0051] 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.
[0052] FIGS. 2A and 2B, collectively, represent a sequence flow diagram 200 for obtaining real-time cardholder approval for payment transactions associated with a payment card of the cardholder, 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.
[0053] At 202, the cardholder 106 initiates a payment transaction on an application 122 (e.g., merchant application, wallet application, etc.) installed on the cardholder device 104. In particular, the cardholder 106 enters cardholder credential data on the application protocol interface displayed on the application 122. In one embodiment, the cardholder credential data may be a virtual account number associated with the application 122 and a service password. It should be noted that the virtual account number can be an identifier (e.g., cardholdername@bankXYZ) of the cardholder 106 on the application 122. Alternatively, or additionally, the cardholder credential data may be in the form of biometric data. The biometric data may include, but is not limited to, fingerprints of the cardholder 106, facial identification data of the cardholder 106, fingerprints of the cardholder 106, and the like. In another embodiment, the cardholder 106 may enter cardholder credential data on a merchant application present on a merchant device of the merchant 108.
[0054] At 204, the cardholder 106 also enters payment transaction details on the application protocol interface of the application 122. The payment transaction details may include merchant information, payment transaction amount, etc.
[0055] At 206, the cardholder device 104 sends the cardholder credential data and the payment transaction details to the merchant 108 or the wallet service provider 118. The merchant 108 or the wallet service provider 118 transmits the cardholder credential data and the payment transaction details to a payment server 112 of the payment network 110 for authentication. The payment server 112 compares the cardholder credential data received from the merchant 108 via the acquirer server 116 with the cardholder credential data already stored in a database 124.
[0056] After authenticating the cardholder credential data, at 208, the payment server 112 sends a payment authorization request message to the server system 102 using the cardholder credential data, and the payment transaction details. In case, the cardholder credential data received from the merchant 108 or the wallet service provider 118 does not match with the cardholder credential data already stored in a database, the payment server 112 declines the payment transaction and the cardholder 106 is notified about the failed transaction due to incorrect cardholder credential data provided on the application 122.
[0057] At 210, the server system 102 analyzes the payment authorization request message associated with the cardholder 106. The server system 102 is configured to determine a set of transaction parameters associated with the payment authorization request message. The set of transaction parameters may include card product type, transaction channel (i.e., cross-border, domestic), card-present transaction indicator, transaction amount, etc.
[0058] Based on the set of transaction parameters, at 212, the server system 102 identifies whether the payment transaction requires a particular or predefined card control to be enabled for the cardholder 106 or not. In one embodiment, the server system 102 is configured to store a list of enabled predefined card controls for the cardholder 106. The server system 102 is configured to determine the particular card control that needs to be enabled for the payment transaction based on the set of transaction parameters.
[0059] In case when the particular card control is not enabled or opted-in by the cardholder 106 in the past time, at 214, the server system 102 places hold on authorization process of the payment transaction. In other words, when the server system 102 intercepts reason of decline of the payment transaction due to the non-enablement of the particular card control for the cardholder 106, the server system 102 may delay authorization process of the payment transaction. Alternatively, the server system 102 may temporarily store the payment authorization request message in memory, such as in the database 124.
[0060] At 216, the server system 102 generates a wait response message to the merchant or the wallet service provider to indicate delaying of authorization of the payment transaction. In one embodiment, the wait response message is transmitted as an API message to the merchant or the wallet service provider. In one embodiment, the server system 102 may insert a unique wait identifier or code into one of the data components of the wait response message.
[0061] At 218, the server system 102 generates a consent request message for enabling the particular card control to the cardholder device 104 via the merchant 108 or the wallet service provider 118. The consent request message includes a plurality of data elements as shown in the table 1:
Data Element
1 Opt-in Service Identifier
2 Opt-in Choice Data
3 Transaction Amount
4 Wallet ID or Merchant ID
5 Transaction Header and Footer
Table 1
[0062] The "opt-in service identifier" may represent an identifier associated with the particular card control that requires to be enabled by the cardholder 106 to proceed the payment transaction. In one example, the "opt-in service identifier" may refer to details of the particular card control that needs to be enabled.
[0063] The "opt-in choice data" may represent cardholder input field that needs to contain a status (i.e., enable/disable) of the particular card control for the cardholder 106.
[0064] At 220, the server system 102 encrypts the consent request message based, at least in part, on using a combination of merchant public key or wallet public key and user private key associated with the cardholder 106. The encryption is performed using double encryption-asymmetric encryption techniques with the user private key (e.g., PIN of the cardholder) and the merchant public key. It is to be noted that the cardholder 106 already registers the PIN with the server system 102 in a registration process.
[0065] At 222, the server system 102 transmits the wait response message and the consent request message to the merchant 108 or the wallet service provider 118.
[0066] At 224, the merchant 108 or the wallet service provider 118 partially decrypts the consent request message using the merchant private key. The wait response message informs about delay in authorization process to the merchant 108 or the wallet service provider 118.
[0067] At 226, the merchant 108 or the wallet service provider 118 transmits the partial decrypted consent request message to the cardholder device 104.
[0068] At 228, the cardholder device 104 prompts the cardholder 106 to enter the user private key (i.e., PIN) to access the consent request message. In one example, the cardholder device 104 displays a user interface on the application 122 to request the cardholder 106 to enter PIN associated with the payment card. When the cardholder 106 enters the correct PIN, the consent request message is successfully decrypted using the PIN. The content of the consent request message is displayed on the application protocol interface of the application 122. When the cardholder does not enter the correct PIN, the consent request message is not decrypted and the consent response message is automatically sent to the server system 102 with a blank value in the "opt-in choice data" data field, which leads to a decline of the payment transaction.
[0069] When the cardholder 106 enters the correct PIN, at 230, the cardholder device 104 prompts an input from the cardholder 106, without any delay, to enable the particular card control for the payment card to complete the payment transaction. In particular, the cardholder device 104 displays a user interface (as shown in FIG. 4B) to allow/deny enabling of the particular card control. Based on the cardholder response, a consent response message is generated by populating the "opt-in choice data" data field according to the cardholder input. In one example, when the cardholder 106 allows enabling the particular card control, the "opt-in choice data" data field may include a first data value (i.e., '1'). In another example, when the cardholder 106 denies enabling the particular card control, the "opt-in choice data" data field may include a second data value (i.e., '0').
[0070] The consent response message may also include "opt-in service identifier", transaction amount, wallet identifier or merchant identifier, etc.
[0071] At 232, the cardholder device 104 sends the consent response message to the server system 102 via the merchant 108 or the wallet service provider 118.
[0072] At 234, the server system 102 validates the consent response message by matching the "opt-in service identifier" received in the consent response message with the "opt-in service identifier" associated with the consent request message.
[0073] At 236, the server system 102 determines whether the particular card control is enabled by the cardholder 106 or not based on the "opt-in choice data" of the consent response message. In case when the "opt-in choice data" indicates the disable of the particular card control, the server system 102 declines the payment transaction and sends an authorization response to the cardholder 106 via the merchant 108 indicating decline of the payment transaction.
[0074] At 238, when the "opt-in choice data" indicates the enable of the particular card control, the server system 102 authorizes the payment transaction. In one embodiment, the server system 102 may send a request to the issuer server 114 to authorize the payment transaction. In one embodiment, the issuer server 114 processes the payment transaction to transfer the funds from the payment account of the cardholder 106 to the merchant 108.
[0075] At 240, the server system 102 stores the "opt-in choice data" mapping to the particular card control for the cardholder 106 in a database (see, the table 2). The server system 102 stores and maps the "opt-in service ID" and "opt-in choice data", only if the "opt-in choice data" is ‘1’. For every subsequent ecommerce transaction that happens for this payment card or token of the payment card, the server system 102 sends these details in the authorization request to the issuer 114 and populates "On-Behalf Approval" flag as ‘1’ indicating that the transaction can be approved by issuer 114. The following table 2 lists a number of data elements that indicate opt-in or enablement of a particular card control for the cardholder 106 for the subsequent transactions. For example, at least some of these data elements may be included in the consent response message received from the cardholder device 104. The stored "opt-in choice data" value corresponding to the cardholder 106 is stored in the database as shown in table 2:
Data Element Exemplary Data Values
Cardholder Identifier “123456212221”
Opt-in Service Identifier “987654” (corresponding to e-commerce transactions)
Issuer Identifier “ABC123”
Opt-in Choice Data ‘1’
Table 2
[0076] In one embodiment, the server system 102 may also store a set of transaction variables or parameters that need to be analyzed in a payment authorization request message corresponding to a particular card control. The server system 102 identifies and matches the multiple transaction variables or parameters with the stored variables and retrieves the "opt-in choice data" value successfully if the transaction variables match with the stored multiple transaction variables. In one embodiment, the server system 102 may send the "opt-in choice data" in the payment authorization request message to the issuer server 114 or populates "On-Behalf Approval" flag as ‘1’ in the payment authorization request message indicating that the payment transaction can be approved by issuer server 114.
[0077] For subsequent transactions, the server system 102 analyzes a payment authorization request message of a payment transaction and determines the set of transaction parameters. Based on the set of transaction parameters, the server system 102 determines which particular card control requires to be enabled for the payment transaction.
[0078] Thereafter, the server system 102 retrieves the "opt-in choice data" value mapped to the particular card control from the database by running a query in a database based on the opt-in service identifier of the particular card control and populates a data field in the payment authorization request message indicating that the payment transaction can be approved by issuer server 114. For example, the cardholder "John" tenders to buy shoes on e-commerce platform. The e-commerce platform sends a payment transaction request to the server system 102. The server system 102 determines that the e-commerce transactions for the cardholder "John" are not enabled. In conventional scenarios, in such cases, the issuer server 114 would decline the payment transaction. In contrast, in the present disclosure, the server system 102 holds the payment transaction and sends a consent request message with "opt-in service identifier" referring to the e-commerce transactions to the cardholder device in real-time. If the cardholder "John" enables the card control for the e-commerce transactions, the payment transaction request is authorized by the issuer server 114. When the cardholder “John” performs the subsequent transactions, the server system 102 searches the database based on opt-in service identifier for opt-in choice data value and retrieves the opt-in choice data value if the "opt-in choice data" is stored in the database and then proceeds with the payment transaction.
[0079] FIGS. 3A and 3B, collectively, represent a flowchart 300 of a process flow for obtaining real-time cardholder authentication for enabling card controls for online transactions associated with a cardholder, in accordance with an embodiment of the present disclosure. The flow chart 300 explains authorization process for a payment transaction which would be declined by the issuer 114 if a particular card control is not enabled by the cardholder 106.
[0080] At 302, the server system 102 receives a payment authorization request message from the cardholder device 104 associated with the cardholder 106 via the merchant 108 or the wallet service provider 118. The cardholder 106 launches a merchant application or a tokenized wallet application to initiate the payment transaction request. The payment transaction request may include payment card details, merchant details, transaction amount, etc. In some examples, the merchant 108 may receive a payment transaction request from the cardholder 106 and the merchant 108 sends the payment transaction request to the acquirer server 116 which generates the payment authorization request message including the payment account information and additional transaction information (e.g., merchant identifier). The acquirer server 116 may transmit the payment authorization request message, including the payment account information, to an interchange network, such as the payment network 110 (shown in FIG. 1) (e.g., by way of a network, etc.). The payment network 110 routes the payment authorization request message to the server system 102.
[0081] At 304, the server system 102 determines a set of transaction parameters of the payment authorization request message. As described herein, the payment authorization request message may be formatted as an ISO 8583 message type identifier (MTI) message and include at least a first data component configured to store the cardholder's PAN associated with the cardholder's payment account for funding the transaction. The payment authorization request message may include additional data components configured to store other requisite transaction data. The set of transaction parameters is determined based on the transaction data received in the payment authorization request message.
[0082] At 306, the server system 102 identifies whether the payment transaction is required a particular or predefined card control to be enabled based, at least in part, on the set of transaction parameters. The server system 102 may assess the payment authorization request message to determine one or more predefined card controls required to be enabled for processing the payment transaction based on payment authorization rules or regulations. The server system 102 may compare the one or more predefined card controls with a list of enabled predefined card controls corresponding to the cardholder’s payment account and determine which card control from the one or more predefined card controls is not included in the list of enabled predefined card controls. Each predefined card control is associated with "opt-in service identifier".
[0083] In one non-limiting example, the card controls include, but are not limited to, a control on e-commerce payment transactions, a control on contactless payment transactions, ATM transactions, cross-border payment transactions, and any other payment modes of digital payment known in the art. Further, in some regulated environments or markets, when the cardholder wants to perform a cryptocurrency transaction on a mobile application, the cardholder may have to provide his/her consent to enable the cryptocurrency related transactions on cardholder’s payment account.
[0084] At 308, when the one or more required predefined card controls are enabled previously by the issuer server 114 or the cardholder 106, the payment transaction is authorized.
[0085] In case the particular card control from the one or more predefined card controls is not enabled by the cardholder 106, at 310, the server system 102 generates a wait response message and sends the wait response message to the merchant 108 or the wallet service provider 118. The wait response message includes a unique wait identifier indicating delaying authorization response of the payment transaction due to non-enablement of the particular card control to complete the payment transaction and an opt-in service identifier of the particular card control. In one embodiment, the server system 102 delays processing of the payment transaction for a threshold time window (e.g., 2 minutes) and stores the payment authorization request message into the database 124. In one embodiment, the wait response message sent by the server system 102 may be an ISO message or an API message sent to the merchant 108. In one embodiment, the ISO message sent by the server system 102 may be converted to an API message by the payment network 110 and then sent to the merchant 108.
[0086] At 312, the server system 102 generates a consent request message based on transaction data and the information of the particular card control. As shown in the table 1, the consent request message includes, but is not limited to, opt-in service identifier, opt-in choice data field, transaction amount field, merchant identifier of the merchant application or wallet identifier of the wallet application, and transaction header and footer. In one embodiment, the consent request message is generated to get use consent for enabling the particular card control, without any delay, during the payment transaction so that the payment transaction cannot be declined.
[0087] At 314, the server system 102 encrypts the consent request message using a combination of merchant public key or communication session key and user private key (i.e., PIN) of the cardholder 106. The objective of encrypting the consent request message is to avoid PIN transmission to the server system 102 for validating the cardholder input in response to the consent request message.
[0088] At 316, the server system 102 transmits the encrypted consent request message on the application 122 to the cardholder device 104 associated with the cardholder 106. The consent request message may cause a notification to be displayed on the cardholder device 104 when the application 122 authentication is running. In some embodiments, the application 122 may be, e.g., tokenized wallet application (e.g., Masterpass by Mastercard), a banking application, a merchant application, etc. The notification may indicate that the consent request message was received and cardholder input may be required. The consent request message may cause media output component (e.g., a display, touch screen, etc.) of the cardholder device 104 to display an interface requesting from the cardholder 106 authentication information, such as, a PIN, an alphanumeric password, etc. to respond to the consent request message.
[0089] At 318, the server system 102 prompts the cardholder 106 to enter user private key (e.g., PIN) to access or decrypt the consent request message. Upon entering the correct user private key, the cardholder device 104 displays the "opt-in service identifier" corresponding to the particular card control and requests the cardholder 106 to input opt-in choice data to enable the particular card control.
[0090] At 320, the cardholder 106 inputs the opt-in choice data to enable the particular card control for the cardholder 106. In one embodiment, the cardholder 106 may check a box indicating that the particular card control can be enabled or disabled. The cardholder input may be received by the application 122 via the cardholder device 104.
[0091] At 322, the server system 102 receives a consent response message from the cardholder device 104. The consent response message may include cardholder input at the cardholder device 104 and the "opt-in service identifier" corresponding to the particular card control. The consent response message is encrypted under the user private key of the cardholder 106. Since the server system 102 stores the user private key in the database during cardholder registration, the server system 102 can only decrypt the consent response message.
[0092] At 324, the server system 102 matches the opt-in service identifier received in the consent response message with stored opt-in service identifier of the particular card control to validate that the consent response message is received for the particular card control from the cardholder device 104
[0093] After determining validity of the consent response message, at 326, the server system 102 checks the content of the opt-in choice data field of the consent response message. In particular, the server system 102 compares a value in the opt-in choice data field of the consent response message with a particular data value.
[0094] When the value in the opt-in choice data field is not equal to a particular data value (e.g., ‘1’), at 328, the server system 103 declines the payment transaction. At 330, the server system 102 sends a decline reason code (e.g., cardholder not opted-in the particular card control) to the cardholder device 104 and the merchant 108. In particular, the server system 102 may inject or populate a field of the payment authorization response message with a decline code and transmit it to the acquirer 116 as the payment authorization response message.
[0095] When the value in the opt-in choice data field is equal to a particular data value (e.g., ‘1’), at 332, the server system 102 may authorize the payment transaction and release the funds from cardholder’s account to the merchant 108. The server system 102 also sends a payment authorization response message indicating that the payment transaction has been approved to the merchant 108.
[0096] At 334, the server system 102 stores the opt-in choice data value corresponding to the particular card control for the cardholder 106 at the database 124. In one embodiment, the server system 102 stores the opt-in choice data value only if the opt-in choice data value = ‘1’. In one embodiment, the opt-in choice data value is stored at the payment server 112 associated with a payment network 110. For every subsequent similar payment transaction performed by the cardholder 106, the server system 102 may send these details in the payment authorization request message to the issuer server 114 and populates "On-Behalf Approval" flag as ‘1’ in the payment authorization request message indicating that the payment transaction can be approved by issuer server 114.
[0097] In one embodiment, when the cardholder 106 wants to opt-out manually the particular card control (for example, disable cross-border transactions), the server system 102 needs to trigger a notification message (i.e., ‘Notify API’) requesting the payment network 110 to reset the opt-in service identifier and the opt-in choice data value associated with the payment card of the cardholder 106. The notification message includes data fields such as, payment card number, country code, date of opt-out, and time of opt-out. The payment network 110 then resets opt-in choice data value based on the server system’s request. When the cardholder 106 attempts to perform a payment transaction using the cardholder device 104 upon resetting the opt-in choice data value, the cardholder 106 has to again opt-in for card control as described in the present disclosure.
[0098] FIGS. 4A, 4B, 4C, and 4D collectively, represent a series of exemplary graphical user interfaces (GUIs) implemented on a cardholder device 104 to obtain real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder 106, in accordance with an embodiment of the present disclosure. The UI 400 includes a payment initiation page where the cardholder 106 first selects a payment card from a plurality of available payment cards (see, 402a, 402b, 402c) associated with the cardholder 106. After selecting a particular payment card, the cardholder 106 enters payment card details. The cardholder 106 then clicks on “Pay” button 404 to proceed with the payment transaction with the merchant on the merchant application.
[0099] The UI 410 includes a consent request message in an encrypted format. The UI 400 is displayed or rendered upon determining that the payment transaction requires a particular card control (for example, control on e-commerce transaction) to be enabled by the cardholder 106. The UI 410 includes a password field 412 to enter user private key i.e., PIN associated with the payment card of the cardholder 106. The consent request message can be viewed by the cardholder 106 if the entered user private key is correct and it is able to decrypt the consent request message. The cardholder 106 can view the consent request message by clicking on view field 414 and the UI 420 is shown upon clicking on the view field 414.
[00100] The UI 420 includes information of a particular or predefined card control that is required to be enabled to process the payment transaction. The UI 420 includes actionable buttons 422 and 424 to provide the cardholder input. When the actionable button 422 is clicked by the cardholder 106, a consent response message is generated with a data value ‘0’ in the opt-in choice data field indicating not to enable the particular card control and the server system 102 declines the payment transaction. When the actionable button 424 is clicked, a consent response message is generated with a data value ‘1’ in the opt-in choice data field indicating to enable the particular card control for the cardholder 106. Hence, by clicking the actionable button 424, the particular card control is enabled for the cardholder during the payment transaction and the payment transaction is successfully authorized. The UI 430 depicts payment authorization response along with a message field 432 indicating that the opt-in choice data with enable status of the particular card control is stored in the database 124 and the opt-in choice data of the particular card control can be used by the server system 102 or the issuer server 114 to authorize subsequent payment transactions, for example, e-commerce transactions.
[00101] FIG. 5 represents a flow diagram of a computer-implemented method 500 for obtaining real-time cardholder input for a predefined card control for a payment transaction associated with a cardholder 106, in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by the server system 102 which may be standalone server or a server as whole incorporated in another server system. Operations of the method 500, and combinations of operation in the method 500, 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.
[00102] In certain implementations, the method 500 may be performed by a single processing thread. Alternatively, the method 500 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 500 may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing the method 500 may be executed asynchronously with respect to each other. The method 500 starts at operation 502.
[00103] At 502, the method 500 includes receiving a payment authorization request message for a payment transaction associated with a cardholder 106. The payment transaction is initiated via an application 122 accessible on a cardholder device 104 of the cardholder 106.
[00104] At 504, the method 500 includes determining whether the payment transaction requires a predefined card control from the cardholder to process the payment transaction.
[00105] At 506, the method 500 includes generating a wait response message indicating placing the payment transaction on hold in response to determining that the payment transaction requires the predefined card control.
[00106] At 508, the method 500 includes transmitting a consent request message for enabling the predefined card control to the cardholder device 104. The consent request message includes, but is not limited to, opt-in service identifier data field, opt-in choice data field, transaction amount data field. The consent request message is encrypted using a combination of merchant public key and a user private key of the cardholder 106.
[00107] At 510, the method 500 includes receiving a consent response message from the cardholder device 104 associated with the cardholder 106. The consent response message includes cardholder input in response to the consent request message. In particular, the consent response message includes, but is not limited to, opt-in service identifier, opt-in choice data value in opt-in choice data field.
[00108] At 512, the method 500 includes determining whether the cardholder opts-in the predefined card control or not based, at least in part, on the consent response message.
[00109] At 514, the method 500 includes facilitating the payment transaction based, at least in part, on the determining step.
[00110] FIG. 6 is simplified block diagram of a server system 600, in accordance with an embodiment of the present disclosure. The server system 600 includes a computer system 602 and a database 604. In an embodiment, the server system 600 is integrated, but not limited to, in the issuer server 114.
[00111] The computer system 602 includes at least one processor 606 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 608. The components of the computer system 602 provided herein may not be exhaustive and that the computer system 602 may include more or fewer components than that of depicted in FIG. 6. 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 computer system 602 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00112] The processor 606 is operatively coupled to a communication interface 610 such that the computer system 602 is capable of communicating with a remote device 614 such as a cardholder device 104, the merchant 108, the payment server 112 associated with the payment network 110, the issuer server 114, acquirer server 116, and the wallet service provider 118, respectively or communicated with any entity connected to the network 120 (shown in FIG. 1). In an embodiment, the communication interface 610 is configured to receive a payment authorization request message from the merchant 108 and a consent response message from the cardholder device 104 associated with the cardholder 106. The communication interface 610 is further configured to send a wait response message and an authorization response message to the merchant 108, and an encrypted consent request message to the cardholder device 104 associated with the cardholder 106. In other embodiments, the database 604 is external to the computer system 602 and may be accessed by the computer system 602 using a storage interface 612. The storage interface 612 is configured to store opt-in choice data value 126 received from the cardholder device 104 associated with the cardholder 106 for performing subsequent payment transactions.
[00113] The processor 606 may also be operatively coupled to the database 604. The database 604 is an example of the database 124. The database 604 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of a merchant, transaction data generated as part of sales activities conducted over a payment network including data relating to merchants, payees, or customers, and purchases. The database 604 may also store an opt-in choice data. The database 604 may also include instructions for settling transactions including merchant bank account information. The database 604 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 604 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00114] In some embodiments, the database 604 is integrated within computer system 602. For example, the computer system 602 may include one or more hard disk drives as the database 604. The storage interface 612 is any component capable of providing the processor 606 with access to the database 604. The storage interface 612 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 606 with access to the database 604.
[00115] The processor 606 is configured to analyze the payment authorization request. If the payment authorization request is valid, the processor 606 is configured to identify whether the payment transaction requires a predefined card control or not. Further, the processor 606 is configured to generate a consent request message and encrypt the consent request message using an asymmetric key encryption algorithm. Thereafter, the processor 606 is configured to transmit the encrypted consent request message to the cardholder device (e.g., 104 of FIG. 1) associated with the cardholder (e.g., 106 of FIG. 1) for receiving a consent to perform the payment transaction. The processor 606 is configured to receive an opt-in choice data value in a consent response message for proceeding with the authorization of the payment transaction. In response to receiving the consent response message and authorizing the payment transaction, the processor 606 is configured to store the opt-in choice data value 616 in the database 604 for subsequent transactions.
[00116] FIG. 7 is a simplified block diagram of an issuer server 700, in accordance with one embodiment of the present disclosure. The issuer server 700 is associated with an issuer bank/issuer, in which a cardholder (e.g., the cardholder 106) may have an account. The issuer server 700 is an example of the issuer server 114 of FIG. 1, or may be embodied in the issuer server 114. The issuer server 700 includes a processor 705 communicably coupled to a database 710 and a communication module 715. The components of the issuer server 700 provided herein may not be exhaustive, and the issuer server 700 may include more or fewer components than those of depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 700 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00117] The database 710 includes information associated with the cardholder 106, such as, but not limited to, a primary account number (PAN one or more parameters), payment card number, a name, a city, a postal code, a payment card PIN and the like.
[00118] Via a communication module 715, the processor 705 may receive information from a remote device 720 such as server system 102, the acquirer server 116, and the payment server 112. In an embodiment, the processor 705 may communicate the information related to the cardholder 106 to the server system 102 for facilitating real-time cardholder opt-in for digital payment transactions.
[00119] FIG. 8 is simplified blocks diagram of a cardholder device 800 for example a mobile phone or a desktop computer capable of implementing the various embodiments of the present disclosure. For example, the cardholder device 800 may correspond to the cardholder device 104 of FIG. 1. The cardholder device 800 is depicted to include one or more applications such as a mobile application. The mobile application can be an instance of an application downloaded from a third-party server or an issuer server. The mobile application is capable of communicating with the merchant 108, the payment server 112, acquirer server 116, the wallet service provider 118 or the issuer server 700 for facilitating processing of payment transaction and for providing real time cardholder opt-in for digital payment transactions.
[00120] It should be understood that the cardholder device 800 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the cardholder device 800 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 8. As such, among other examples, the cardholder device 800 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.
[00121] The illustrated cardholder device 800 includes a controller or a processor 802 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 804 controls the allocation and usage of the components of the cardholder device 800 and support for one or more payment transaction applications programs (see, the applications 806) such as the merchant application or the wallet application, that implements one or more of the innovative features described herein. In addition, to the merchant application, the applications 806 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00122] The illustrated cardholder device 800 includes one or more memory components, for example, a non-removable memory 808 and/or removable memory 810. The non-removable memory 808 and/or the removable memory 810 may be collectively known as a database in an embodiment. The non-removable memory 808 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 810 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 804 and the applications 806. The cardholder device 800 may further include a user identity module (UIM) 812. The UIM 812 may be a memory device having a processor built in. The UIM 812 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 812 typically stores information elements related to a mobile subscriber. The UIM 812 in 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), CDMA5000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00123] The cardholder device 800 can support one or more input devices 820 and one or more output devices 830. Examples of the input devices 820 may include, but are not limited to, a touch screen / a display screen 822 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 824 (e.g., capable of capturing voice input), a camera module 826 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 828. Examples of the output devices 830 may include, but are not limited to a speaker 832 and a display 834. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 822 and the display 834 can be combined into a single input/output device.
[00124] A wireless modem 840 can be coupled to one or more antennas (not shown in the FIG. 8) and can support two-way communications between the processor 802 and external devices, as is well understood in the art. The wireless modem 840 is shown generically and can include, for example, a cellular modem 842 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 844 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 846. The wireless modem 840 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the cardholder device 800 and a public switched telephone network (PSTN).
[00125] The cardholder device 800 can further include one or more input/output ports 850, a power supply 852, one or more sensors 854 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the cardholder device 800 and biometric sensors for scanning biometric identity of an authorized cardholder, a transceiver 856 (for wirelessly transmitting analog or digital signals) and/or a physical connector 860, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00126] The disclosed method with reference to FIG. 5, 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.
[00127] 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).
[00128] 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.
[00129] 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.
[00130] 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.