Description:[0001] The present disclosure relates to artificial intelligence-based processing systems within financial domain, particularly focusing on electronic methods and complex processing systems for authentication of payment transactions.
BACKGROUND
[0002] In recent times, payments have undergone a significant transformation, greatly reducing transactional friction. This evolution has transitioned from traditional methods such as paper-based transactions using a checkbook to electronic methods such as swiping payment cards on a Point of Sale (POS) terminal at the merchant’s end, to embracing digital technologies such as net banking, Unified Payment Interface (UPI) payment systems, and the like. Nowadays, the majority of payments made between cardholders and merchants are made digitally. Most of these financial transactions include the use of payment cards, including credit cards, debit cards, and similar cards. Additionally, the majority of these payment transactions take place between the cardholder and the merchant on a digital platform that is hosted by the merchant. For example, a cardholder can input their payment card details into a payment gateway connected to the merchant’s application on their smartphone to make purchases or pay for services. It is extremely important to authenticate the identity of the cardholder during such payment transactions to prevent fraudulent payment transactions from taking place. To that end, various authentication techniques have been developed for authenticating a cardholder’s identity and preventing fraud. Some notable examples of authentication techniques include One-time passwords (OTPs), public-key infrastructure, smart cards, Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA), Multi-factor Authentication (MFA) process, biometric, three-domain secure (3DS), etc.
[0003] However, it should be noted that the introduction of multiple layers of authentication during transaction processing often results in cardholders experiencing the burden of navigating through multiple steps to verify their own identity. This frequently leads to instances of cart abandonment (checkout abandonment) by the cardholders, and subsequently reduces the likelihood of the return of the cardholders to the payment channel. For instance, in the case of 3DS, alternatively known as 3DS-version 1 (3DS1), where the merchant redirects the cardholder’s browser to the issuing bank’s website, requiring the cardholder to authenticate using a one-time password typically sent through email or text message. While this method offers enhanced security, it still causes friction, albeit less than conventional methods, that culminates in transaction abandonment by several cardholders.
[0004] To address the problem of friction, a new version of 3DS called 3DS-version 2 (3DS2) is introduced in the payment card networks. In this upgraded authentication process, the merchant uses a back channel to communicate with the issuing bank, circumventing reliance on the cardholder’s browser to send transaction and cardholder data. The issuing bank evaluates the fraud risk associated with transactions using the provided information, and can exempt the cardholder from authenticating for the low-risk transactions. However, it can still cause friction as most of the cardholders may have no idea about the regulatory changes and how exactly the 3DS2 works in the backend. Additionally, a security vulnerability may arise when the 3DS2 configuration is implemented on a native merchant’s application rather than a web browser via which the cardholders access the merchant’s site. The security flaw exposes the system to potential attacks by malicious merchants or personnel with malicious intent operating within the merchant’s setup. Consequently, the responsibility falls upon merchants and/or payment gateways to not only ensure protection from fraud and abuse, but also ensure easier and quicker online transactions for balancing between the risks and rewards that come with streamlining checkouts or frictionless checkouts.
[0005] Thus, there exists a need for technical solutions or methods and systems for the authentication of payment transactions aimed at addressing the above-mentioned limitations. The technical solution, along with providing streamlining transactions without any friction or with the least friction, should also prioritize safeguarding transactions against fraudulent activities.
SUMMARY
[0006] Various embodiments of the present disclosure provide methods and systems for authentication of payment transactions.
[0007] In an embodiment, a method for authentication of payment transactions is disclosed. The method performed by a server system includes receiving a payment initiation request from an electronic device for a payment transaction being performed between a cardholder and a merchant. The payment initiation request includes a selected payment card and transaction-related information. Herein, the transaction-related information includes at least a Personal Account Number (PAN) of the selected payment card. The method further includes accessing stored payment card-related data associated with the selected payment card from a database of the server system based, at least in part, on the PAN of the selected payment card. The stored payment card-related data includes a card-specific Personal Identification Number (PIN) and consent information. Further, the method includes generating and transmitting a cardholder authentication request to the electronic device. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card. Further, upon receiving a cardholder authentication response message including a PIN from the electronic device, the method includes performing an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN. Furthermore, upon successful authentication, the method includes determining a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information. Upon determining that the payment transaction is valid, the method includes generating and transmitting a payment authentication message to an issuer server associated with the cardholder.
[0008] In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a payment initiation request from an electronic device for a payment transaction being performed between a cardholder and a merchant. The payment initiation request includes a selected payment card and transaction-related information. The transaction-related information includes at least a Personal Account Number (PAN) of the selected payment card. The server system is further caused to access stored payment card-related data associated with the selected payment card from a database of the server system based, at least in part, on the PAN of the selected payment card. The stored payment card-related data includes a card-specific Personal Identification Number (PIN) and consent information. Further, the server system is caused to generate and transmit a cardholder authentication request to the electronic device. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card. Furthermore, upon receiving a cardholder authentication response message including a PIN from the electronic device, the server system is caused to perform an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN. Upon successful authentication, the server system is caused to determine a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information. Further, upon determining that the payment transaction is valid, the server system is caused to generate and transmit a payment authentication message to an issuer server associated with the cardholder.
[0009] In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a payment initiation request from an electronic device for a payment transaction being performed between a cardholder and a merchant. The payment initiation request includes a selected payment card and transaction-related information. Herein, the transaction-related information includes at least a Personal Account Number (PAN) of the selected payment card. The method further includes accessing stored payment card-related data associated with the selected payment card from a database of the server system based, at least in part, on the PAN of the selected payment card. The stored payment card-related data includes a card-specific Personal Identification Number (PIN) and consent information. Further, the method includes generating and transmitting a cardholder authentication request to the electronic device. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card. Further, upon receiving a cardholder authentication response message including a PIN from the electronic device, the method includes performing an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN. Furthermore, upon successful authentication, the method includes determining a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information. Upon determining that the payment transaction is valid, the method includes generating and transmitting a payment authentication message to an issuer server associated with the cardholder.

BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates a schematic representation of an environment related to at least some example embodiments of the present disclosure;
[0012] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0013] FIG. 3A illustrates a block diagram representation depicting a high-level flow of authenticating a cardholder during a first-time checkout, in accordance with an embodiment of the present disclosure;
[0014] FIGS. 3B and 3C collectively illustrate a process flow diagram of a detailed flow of authenticating the cardholder during the first-time checkout, in accordance with an embodiment of the present disclosure;
[0015] FIG. 4A illustrates a block diagram representation depicting a high-level flow of authenticating a cardholder during a subsequent checkout, in accordance with an embodiment of the present disclosure;
[0016] FIG. 4B illustrates a process flow diagram of a detailed flow of authenticating the cardholder during the subsequent checkout, in accordance with an embodiment of the present disclosure;
[0017] FIGS. 5A-5F collectively illustrate Graphical User Interfaces (GUIs) that are implemented on an electronic device for authenticating the cardholder during the first-time checkout, in accordance with an embodiment of the present disclosure;
[0018] FIGS. 6A-6D collectively illustrate GUIs that are implemented on an electronic device for authenticating the cardholder during the subsequent checkout, in accordance with an embodiment of the present disclosure;
[0019] FIGS. 7A-7C collectively illustrate GUIs that are implemented on an electronic device for authenticating the cardholder for a forgotten Personal Identification Number (PIN) event, in accordance with an embodiment of the present disclosure;
[0020] FIGS. 8A and 8B collectively illustrate GUIs that are implemented on an electronic device for facilitating the cardholder to revoke their consents associated with a process of authentication of the cardholder, in accordance with an embodiment of the present disclosure;
[0021] FIG. 9 illustrates a flow diagram depicting a method for authentication of payment transactions, in accordance with an embodiment of the present disclosure;
[0022] FIG. 10 illustrates a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0023] FIG. 11 illustrates a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure; and
[0024] FIG. 12 illustrates a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
[0025] 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
[0026] 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. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0027] 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.
[0028] 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.
[0029] Embodiments of the present disclosure may be embodied as an apparatus, a system, a method, or a computer program product. Accordingly, embodiments of the present disclosure may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “engine”, “module”, or “system”. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
[0030] The terms “payment transaction”, “financial transaction”, “e-commerce transactions”, “digital transaction”, and “transaction” are used interchangeably throughout the description and refer to a transaction of payment of a certain amount being initiated by the cardholder. More specifically, refers to electronic financial transactions including, for example, online payment, payment at a terminal (e.g., point of sale (POS) terminal, ATM, self-service kiosks, and the like. It may be understood that online payments can be performed on Electronic-commerce (E-commerce) platforms that are either provided on web browsers or by merchants in the form of mobile applications. For instance, by inputting various payment card details on a payment gateway connected to the merchant on the merchant application, a cardholder may carry out a payment transaction on a merchant’s application installed on their smartphone to buy items or pay for services.
[0031] The terms “account holder”, “user”, “cardholder”, “consumer”, and “buyer” are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
[0032] The term “merchant”, used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity.
[0033] The terms “merchant application” and “merchant platform” used, interchangeably, throughout the description, may refer to a software application associated with a particular merchant or may be associated with a number of different merchants. The merchant application may be capable of identifying a particular merchant (or multiple merchants) that is participating in a transaction with a cardholder. 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 cardholder on the merchant application. Further, the merchant application may also include a general-purpose browser or other software-designed application configured to interact with multiple merchant server computers as long as the browser is configured to identify the merchant server computer and process a payment transaction. The merchant application may be installed on the general-purpose memory of an electronic device of the cardholder. To that end, the merchant application is configured to allow a cardholder to perform a payment transaction with a merchant in exchange for goods or services.
[0034] 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 called “issuer server” throughout the description.
[0035] Further, the term “acquirer”, is a financial institution (e.g., a bank) that processes financial transactions for merchants. In other words, this can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., the shopping cart platform providers and the in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0036] The term “payment account” used throughout the description refers to a financial account that is used to fund a financial transaction interchangeably referred to as “payment transaction” or “transaction”). Examples of the financial account include, but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The financial 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, the financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like.
[0037] The terms “payment network” and “card network” are used interchangeably throughout the description and refer 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. Payment networks are companies that connect an issuing bank with an acquiring bank to facilitate online payment. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes that may include payment cards, letters of credit checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
[0038] 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 presented to a merchant or any such facility to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in the form of data 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.
[0039] The term “payment service provider”, may include an entity that contracts with an acquirer for the purpose of providing acceptance to a merchant, the merchant then contracts with the payment service provider to obtain payment services.
[0040] The term “authorization” used throughout the description may refer to a process of giving someone the ability to access a resource. Further, the terms “payment authorization”, “payment transaction authorization”, “transaction authorization”, “cardholder authorization”, “payment card authorization”, and “card authorization” used, interchangeably, throughout the description may refer to a process through which merchants request approval for a debit card or a credit card transaction from the cardholder’s bank i.e., the issuer.
[0041] The term “authentication” is used throughout the description, and may refer to a process of proving some fact, some document, or identity or a person is genuine. Further, the terms “payment authentication”, “payment transaction authentication”, “transaction authentication”, “cardholder authentication”, “payment card authentication”, and “card authentication” used, interchangeably, throughout the description may refer to a process of confirming a cardholder’s identity for making a particular payment transaction on a digital platform using a payment card associated with the cardholder through at least one of the following authentication factors: knowledge, inherence, ownership, and user location. An example of authentication through knowledge includes a scenario in which an online store requires the cardholder to input a password or Personal Identification Number (PIN) associated with the payment card that only the cardholder would know before completing the corresponding payment transaction. Similarly, an example of inherence-based authentication includes the merchants that use a cardholder’s biometric such as fingerprint, facial, palm, or voice recognition, to authenticate that the cardholder is indeed the one who he/she is claiming to be. Further, an example of an ownership-based authentication includes the action of signing a receipt. Finally, an example of user location-based authentication includes a scenario where the cardholder uses their card at a location that they usually don’t use, and in such scenarios, the transaction will be declined. It may be noted that for performing cardholder authentication in case of payment transactions several authentication techniques have been developed in recent times, and an example of one of the largest cardholder authentication programs may be Mastercard® Identity Check (IDC®). More specifically, it may be noted that the very latest implementation of the cardholder authentication process may be based on Three-Domain Secure-version 2 (3DS2).
[0042] The terms “Three-Domain Secure”, “3D secure”, “3DS”, “3DS-version 1”, and “3DS1” interchangeably used throughout the description, refer to an authentication process used to authenticate a cardholder during card-not-present (CNP) transactions such as e-commerce transactions. The three domains of the 3DS authentication process include the issuer domain, the interoperability domain, and the acquiring domain. The issuer domain includes issuer banks that deploy an Access Control Server (ACS) for receiving 3D secure XML messages to authenticate the cardholder. The acquiring domain includes the merchants that deploy a Merchant Plug-in (MPI) to initiate a payment transaction. The interoperability domain includes a Directory Server (DS) deployed by a payment processor in a payment network to authenticate and allow communication between the MPI and the ACS.
[0043] The term “3DS program” or “3DS service” interchangeably used through the description, refers to the optional service provided to a cardholder by his/her issuer through which the cardholder may engage in CNP payment transactions with the 3DS authentication process. In various non-limiting examples, the cardholder may be required to voluntarily enroll in the 3DS program or a regulating entity may mandate the 3DS service for all payment transactions. Further, the term “3DS payment network” refers to a payment network or architecture within which payment transactions are authenticated using the 3DS authentication process. It is noted that during the 3DS authentication process, the ACS authenticates the identity of the cardholder by transmitting an OTP to the cardholder and further receiving the OTP from the cardholder through a payment gateway that may be associated with the DS. Further, the ACS compared the received OTP with the transmitted OTP to validate the identity of the cardholder. If the comparison is successful, then the ACS requests the issuer to approve the transaction. Otherwise, the ACS requests the issuer to decline the transaction. In both these scenarios, the ACS informs the DS whether the transaction status is approved or declined. Further, the DS is configured to inform the merchant through MPI of the transaction status.
[0044] The terms “Three-Domain Secure-version 2”, “3D secure-version 2”, and “3DS2” interchangeably used throughout the description, refer to an authentication process for authenticating card-not-present (CNP) transactions which is a new version of the 3DS process. In 3DS2, the merchant uses a back channel to communicate with the issuing bank instead of the cardholder’s browser to send transaction and cardholder data. The issuing bank evaluates the transaction’s risk of fraud using the information and waives authentication for low-risk transactions. Further, it may be noted that for providing the 3DS2 services, a 3DS2 program may be implemented in a way similar to how 3DS1 may be implemented.
OVERVIEW
[0045] Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for authentication of payment transactions in a frictionless manner using an additional factor of authentication along with consent. In an embodiment, the present disclosure describes a server system for authenticating payment transactions, where the server system may be embodied within a payment server associated with a payment network. In an embodiment, assuming that the payment card used by the cardholder for performing payment transactions is already registered on the merchant application and is enabled with the frictionless payment option, the server system receives a payment initiation request from the electronic device, corresponding to a payment transaction being performed between a cardholder and a merchant. The payment initiation request may include a selected payment card and transaction-related information. The electronic device may be associated with at least one of the merchant and the cardholder.
[0046] In an example embodiment, the server system enables receipt of the payment initiation request through the display of a first graphical user interface (GUI) on the electronic device. The first GUI may be configured to prompt the cardholder to select the payment card from one or more payment cards for performing the payment transaction. Further, as may be understood, the payment card is enabled with the frictionless payment option. Subsequently, the server system receives the payment card selection along with transaction-related information linked to the selected payment card, accomplished through a merchant plug-in interface (MPI) associated with the electronic device.
[0047] Additionally, it should be noted that, for the authentication of the payment transaction, the server system accesses relevant payment card-related data, which is securely stored within its database. This data is directly associated with the chosen payment card and is accessed by utilizing the Primary Account Number (PAN) of the aforementioned payment card as the foundational identifier. The stored payment card-related data includes a card-specific Personal Identification Number (PIN) in addition to consent information. Herein, in an embodiment, it may be noted that the consent information may be merchant, card, and device specific. Thus, it should be understood that if consent is taken from the cardholder for a specific merchant, a specific card, and a specific device, then the same consent cannot be used for other merchants, other payment cards, and other devices.
[0048] The server system further generates and transmits a cardholder authentication request to the electronic device. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card. In simpler terms, the cardholder authentication request refers to a prompt displayed on a GUI on the electronic device, asking the cardholder to provide a PIN to authenticate their identity. The cardholder then provides the PIN as a cardholder authentication response.
[0049] Further, upon receiving the cardholder authentication response message including a PIN from the electronic device, the server system performs an authentication of the cardholder identity. This authentication is primarily based on comparing the PIN and the card-specific PIN.
[0050] Furthermore, following a successful authentication, the server system proceeds to determine a validity of the payment transaction. This is determined based on the consent information and the transaction-related information. It is important to highlight that in cases where the cardholder identity authentication is not successful, the server system may generate and transmit a payment failure message to the electronic device.
[0051] Moreover, it is important to note that for the payment transaction to be valid, the consent that the cardholder might have agreed upon, as indicated in the consent information, must match the specific transaction that the cardholder intends to execute.
[0052] Finally, once it is confirmed that the payment transaction meets the criteria of validity, the server system proceeds to generate and transmit a payment authentication message to an issuer server, which is directly associated with the cardholder.
[0053] In an embodiment, the server system may be configured to transmit a transaction successful notification to at least one of the merchant and the cardholder when the payment transaction is completed between the issuer server and the acquirer server associated with the merchant.
[0054] In an embodiment, in situations where it is determined that the payment transaction lacks validity, the server system can be configured to generate and transmit a payment failure message to the electronic device, resulting in the unsuccessful completion of the payment transaction.
[0055] In certain scenarios, it is possible that the cardholder may forget their PIN during the checkout process. To assist the cardholder in proceeding with making the payment transaction, the server system may receive a forgot PIN message from the cardholder via the electronic device in response to the cardholder authentication request.
[0056] Further, the server system may facilitate a display of a second GUI on the electronic device. The second GUI is specially designed to prompt the cardholder to set a new card-specific PIN for the authentication of the cardholder identity. Upon receiving the new card-specific PIN, the server system may transmit a cardholder authentication request to the issuer server to authenticate the cardholder to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information.
[0057] In an embodiment, following successful authentication by the issuer server, the server system can store the new card-specific PIN against the PAN of the selected payment card. The storage process involves linking a card Identifier (ID) of the payment card having the above-mentioned PAN with the consent information. In an embodiment, the card ID may also be linked with other parameters such as a device ID, a merchant ID, and a consent type. The new card-specific PIN can be used for subsequent transactions, enhancing the overall process.
[0058] In certain embodiments, while conducting a checkout on the merchant application, the cardholder may wish to revoke consent for a specific payment card of one or more payment cards associated with the cardholder. In such cases, the server system may further facilitate a display of a third GUI on the electronic device. The third GUI is configured to prompt the cardholder to select a consent revocation option, allowing them to take this specific action.
[0059] Furthermore, the server system can then receive a selected consent revocation option associated with the payment card from the electronic device, utilizing the MPI associated with the electronic device. Once this selection is received, the server system proceeds to update the stored consent-related information, incorporating the cardholder’s explicit revocation of consent for the specified consent description. This ensures that the consent status is appropriately updated based on the cardholder’s decision.
[0060] It may be noted that, in scenarios when the cardholder may be using the merchant application for the first time using a payment card that is enabled with the frictionless payment option for making transactions with another merchant, the payment card may have to be first registered with the merchant application and get the frictionless payment option enabled for the payment card for that particular merchant. Therefore, in an embodiment, the server system may facilitate a display of a fourth GUI on the electronic device. The fourth GUI may be configured to prompt the cardholder to select the frictionless payment option from one or more payment options (or payment methods) to perform a new payment transaction when using a new payment card on the electronic device that is not registered for the frictionless payment option.
[0061] The server system may further receive a selection of the new payment card and new transaction-related information associated with the new payment card from the electronic device via the MPI associated with the electronic device. The new transaction-related information may include at least a PAN of the new payment card.
[0062] Further, the server system may access new payment card-related data associated with the new payment card from the database. The server system may further perform a verification of the PAN of the new payment card to be linked with a card-specific PIN associated with the consent information based, at least in part, on the new payment card-related data.
[0063] Upon successful verification, the server system may facilitate a display of a fifth GUI on the electronic device. The fifth GUI may be configured to prompt the cardholder to provide a consent response for a consent description being displayed to the cardholder via the fifth GUI based, at least in part, on the consent information. It may be noted that the successful varication may indicate the presence of the card-specific PIN associated with the consent information that is been linked with the PAN of the new payment card in the database.
[0064] Once a valid consent response is received, the server system can then store this received consent response for the corresponding consent description in the database as updated consent information against the PAN of the new payment card. This storage process involves linking a card ID of the new payment card having the above-mentioned PAN with the updated consent information. In an embodiment, the card ID may also be linked with other parameters such as a device ID, a merchant ID, and a consent type. In other words, the server system can store the received consent response as the updated consent information against a combination string including the card ID, the device ID, the merchant ID, and the consent type. Further, when the authentication request is received, the combination string may be formed at run time and queried the data to find the consent response. Upon successful storage of the received consent response, the server system may register the new payment card on the electronic device for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data and the received consent response.
[0065] In an embodiment, it may be noted that upon unsuccessful verification, the server system may facilitate a display of the fifth GUI on the electronic device. The fifth GUI may be configured to prompt the cardholder to provide a consent response for a consent description being displayed to the cardholder via the fifth GUI.
[0066] Upon receiving a valid consent response, the server system may facilitate a display of a sixth GUI on the electronic device. The sixth GUI may be configured to prompt the cardholder to provide a new card-specific PIN for the authentication of the cardholder identity.
[0067] Further, upon receiving the new card-specific PIN, the server system may transmit a cardholder authentication request to the issuer server to authenticate the cardholder to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information. Herein, the authentication process performed at the issuer server is an OTP-based authentication. Upon successful authentication, the server system may store the received consent response for the corresponding consent description as new consent information and the new card-specific PIN based, at least in part, on linking the new consent information and the new card-specific PIN with the PAN of the new payment card. In addition, the issuer server may respond with a successful authentication message and transmit the same to the merchant via the merchant application.
[0068] Upon successful storage of the received consent response and the new card-specific PIN, the server system may register the new payment card on the electronic device for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data, the received consent response, and the new card-specific PIN.
[0069] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure provides streamlined payment transactions minimizing or eliminating friction, while concurrently ensuring robust protection against fraudulent activities. This streamlined approach leads to swift and uncomplicated checkout processes, resulting in reduced cart abandonment rates and fewer interrupted payments. Moreover, it contributes to enhanced conversion rates, making the solution presented in this disclosure notably effective and advantageous for both merchants and consumers. These advantages can extend to increased consumer loyalty and satisfaction, a rise in the number of customers visiting stores, improved operational efficiencies, and other valuable outcomes.
[0070] Additionally, the inclusion of a PIN alongside the consent feature adds an extra layer of authentication, primarily employed for cardholder verification at the payment gateway level. This innovation eliminates the necessity of contacting the issuer for each subsequent transaction, significantly streamlining the process. Consequently, the combination of the PIN and consent significantly reduces friction for cardholders when conducting payment transactions, all the while maintaining the security of these transactions at a high level
[0071] Additionally, it is important to highlight that a PIN is associated with a PAN of a payment card of the cardholder, and it is not specific to a device or a merchant. This means that the cardholder can use the PIN on any device and for any merchant if the cardholder has accepted consent on that device and for that merchant. This distinctive structure allows a sequential process where the cardholder is initially authenticated using the PIN and subsequently authenticated based on the associated consent, significantly mitigating the risks of fraudulent or unintended transactions commonly observed in conventional authentication methods. In other words, during the authentication, the method proposed in the present disclosure first checks if the PIN is correct or not for the corresponding PAN. If the PIN is correct, then the method checks if consent is present for the corresponding device and the merchant or not. If both are true then the cardholder is authenticated for making the corresponding payment transaction and eliminates the need for a One-time Password (OTP). Therefore, by eliminating the need for OTP with every transaction, the authentication process gains rapidity. The approach presented in this disclosure not only optimizes security but also enriches the cardholder’s experience by delivering a seamless, swift, and secure enhanced digital payment journey.
[0072] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 12.
[0073] FIG. 1 illustrates a schematic 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, implementing a process for authenticating payment transactions performed by a cardholder in a frictionless manner using an additional faction of authentication along with consents.
[0074] The environment 100 generally includes a plurality of entities such as a server system 102, a cardholder 104 associated with an electronic device 106, a merchant 108, a payment network 110 including a payment server 112, a database 114, an issuer server 116, an Access Control Server 118 (referred hereafter as ‘ACS 118’), an acquirer server 120, and a merchant plug-in (MPI) server 122 (referred hereafter as interchangeably as ‘MPI server 122’ or ‘MPI 122’) each coupled to, and in communication with a network 124. The network 124 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.
[0075] Various entities in the environment 100 may connect to the network 124 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 124 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 112, the merchant 108, the issuer server 116, the ACS 118, the acquirer server 120, the MPI 122, and the electronic device 106 may communicate.
[0076] In an embodiment, the cardholder (e.g., the cardholder 104) may be any individual, representative of a corporate entity, non-profit organization, or any other person who is presenting payment account details or payment card details during an electronic payment transaction. The cardholder (e.g., the cardholder 104) may have a payment account issued by an issuing bank (not shown in figures) and may be provided a payment card with financial or other account information encoded onto the payment card such that the cardholder (i.e., the cardholder 104) may use the payment card associated with a payment account at the issuing bank to initiate and complete a payment transaction. Generally, the term “payment transaction” refers to an agreement that is carried out between a buyer and a seller to exchange assets for a form of payment (e.g., cash, currency, etc.). For example, the cardholder 104 may enter details of the payment card on an e-commerce platform to buy goods or products. In an example, the cardholder (e.g., the cardholder 104) may transact at the merchant 108.
[0077] The cardholder 104 may be associated with the electronic device 106 and may use the electronic device 106 to access a mobile application or a website associated with the issuing bank, a merchant 108, or any third-party payment application to perform a transaction. In some embodiments, the electronic device 106 may be associated with the merchant 108, and the cardholder 104 may use the electronic device 106 to access the mobile application for performing a payment transaction.
[0078] In various non-limiting examples, the electronic device 106 may include any portable communication devices such as a smartphone, tablet, Personal Digital Assistant (PDA), phablet, wearable device, smartwatch, laptop computer, an Augmented Reality (AR) headset, a Virtual Reality (VR) headset, and the like. In some other examples, the electronic device 106 may include any fixed communication device such as a desktop, mainframe computer, workstation, and the like. In one exemplary implementation, the electronic device 106 may be equipped with one or more applications (such as an instance of a merchant application associated with the merchant 108 described later on) for communicating with the server system 102 over the network 124. In particular, one or more applications may be installed on the electronic device 106 by the cardholder 104. Further, the one or more applications may be capable of communicating with the server system 102. In various non-limiting examples, the one or more applications may correspond to a web browser, an application associated with the issuer server 116, an application associated with the merchant 108, an Application Programming Interface (API) associated with the issuer server 116, an application associated with the server system 102, an API associated with the server system 102, and the like.
[0079] In one scenario, the cardholder 104 may use their corresponding payment card to conduct payment transactions with the merchant 108. In an example, the cardholder 104 may enter payment card details on a mobile device to perform an online payment transaction. In another example, the cardholder 104 may utilize a payment card to perform an offline payment transaction.
[0080] In one embodiment, the cardholder 104 may be associated with an issuer server such as the issuer server 116. In one embodiment, the issuer server 116 is associated with a financial institution normally called an “issuer bank”, “issuing bank” or simply “issuer”, in which a cardholder (e.g., the cardholder 104) may have a payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder (e.g., the cardholder 104).
[0081] In some examples, the cardholder 104 may operate the electronic device 106 to conduct a payment transaction through a payment gateway application, i.e., a CNP transaction. The cardholder 104 may have established a card-on-file relationship with a merchant (e.g., the merchant 108). It should be understood that the cardholder 104 is enrolled in a three-domain secure (3DS) service (e.g., 3DS-version 1 or 3DS-version 2) offered by the payment processor associated with the issuer bank of the cardholder 104. Further, it should be understood that the 3DS service may be offered by various payment processors under different names while the underlying technology and architecture generally remain the same. For example, 3DS services offered by payment processors include Mastercard SecureCode® (offered by Mastercard®), Verified by Visa® (offered by Visa®), J/Secure® (offered by JCB International®), American Express SafeKey® (offered by American Express®) or the like.
[0082] In an embodiment, the merchant 108 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where cardholders visit to perform the financial transactions in exchange for any goods and/or services or any financial transactions. In another embodiment, the merchant 108 may provide a merchant application (e.g., the merchant application 126) that may be installed by a cardholder 104 on their electronic device 106. The merchant application 126 may enable the cardholder 104 to perform a payment transaction in exchange for goods or services with the merchant 108. The merchant application 126 may enable the cardholder 104 to perform the payment transaction through various methods such as using payment cards, Net-banking, Unified Payments Interface (UPI), Cash-on-Delivery (COD), and so on.
[0083] In an embodiment, the merchant 108 is associated with an acquirer server (e.g., the acquirer server 120). In one embodiment, the acquirer server 120 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, merchants (e.g., the merchant 108), or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0084] 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 cardholder 104 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 authentication request, and then routes, via the payment network 110, an authentication response back to the acquirer server 120. The acquirer server 120 sends the approval to the merchant 108. The payment account details may include an account balance, an available credit line, account holder details, transaction history of the cardholder 104, account information, or the like. The details of the cardholder 104 may include name, age, gender, physical attributes, registered contact number, alternate contact number, registered e-mail ID, and the like. The cardholder account may be associated with one or more payment means that enable the cardholder 104 to facilitate the payment transaction. Examples of one or more payment means may include, payment cards, Unified Payment Interface (UPI) links, and/or the like.
[0085] In one embodiment, the ACS 118 is associated with the issuer 116 and authenticates the cardholder 104 during CNP transactions such as e-commerce transactions in the 3DS payment network. The ACS 118 is responsible for facilitating and supporting cardholder authentication. In an embodiment, the ACS 118 is maintained by the issuer 116 of the cardholder 104. The ACS 118 authenticates the cardholder 104 by performing various authentication processes such as, but not limited to, requiring a username and password from the cardholder 104 to authenticate a payment transaction, performing two-factor authentication (2FA) (by requiring a One-Time Password (OTP) from the cardholder 104). In an embodiment, the ACS 118 may be associated with an authentication certificate (referred to hereafter as ‘certificate’) that is essential for determining the authenticity of the ACS 118 within the 3DS payment network by various entities such as the server system 102, issuer 116, and the MPI 122.
[0086] In one embodiment, the MPI server 122 is a financial platform that integrates merchants (such as the merchant 108) with the 3DS payment network. The MPI server 122 can be a platform that allows the cardholder 104 to initiate a payment transaction by sharing their payment card details with the merchant’s 3DS-enabled application or website. It should be understood that in various non-limiting examples, the MPI server 122 may be a software-enabled platform or a software-based module that integrates with the merchant website or application through an API or other suitable integration techniques. The MPI software module may be associated with the acquirer server 120 to facilitate the payment transaction process. The terms “MPI”, “MPI platform” or MPI server” will be used interchangeably herein.
[0087] As described earlier, the conventional techniques for performing authentication of the cardholder 104 are not always secure and are regularly subjected to fraud. Furthermore, the conventional techniques are slow and might be cumbersome for the cardholder 104 while performing multiple transactions. As may be understood, most payment transactions nowadays are performed on merchant applications associated with different merchants. It is noted that the conventional techniques do not provide an integrated approach to facilitate a safer, faster, and frictionless mode for performing such transactions. For instance, the cardholder 104 may have to manually add the OTP that is received on their electronic device 106 from the issuer (or the ACS) for authenticating their identity to complete the payment transaction every time they checkout even if they are checking out from the same merchant or checking out from the same device.
[0088] The above-mentioned technical problem among other problems is addressed by one or more embodiments implemented by the server system 102 of the present disclosure. In one embodiment, the server system 102 is configured to perform one or more of the operations described herein.
[0089] In one embodiment, the server system 102 is configured to facilitate the payment network (e.g., the payment network 110), the merchant (e.g., the merchant 108), digital wallets, and/or Payment Service Providers (PSP) to provide secure and frictionless authentication services to the cardholder (e.g., the cardholder 104) at checkout. In some embodiments, the server system 102 may be deployed as a standalone server or may be implemented in the cloud as software as a service (SaaS). In another embodiment, the server system 102 is configured to facilitate an instance of the merchant application 126 running on the electronic device 106 to perform certain operations, so that the server system 102 can authenticate the cardholder 104 to perform payment transactions via the merchant application 126. In another embodiment, the server system 102 may facilitate the electronic device 106 to perform certain operations so that the server system 102 can authenticate the cardholder 104 to perform the payment transactions using the electronic device 106. In some embodiments, the electronic device 106 may be facilitated to perform the corresponding operations via the merchant application 126 that may be installed on the electronic device 106. In one embodiment, it may be noted that the server system 102 utilizes the merchant application 126 to authenticate the payment transactions. In one embodiment, the merchant application 126 may be an application provided by a merchant (e.g., the merchant 108), and the server system 102 is configured to provide the merchant application 126 with one or more functionalities using various Application Programming Interfaces (APIs). In particular, the server system 102 may communicate with the merchant application 126 installed on the electronic device 106 of the cardholder 104 using a plurality of API calls to provide these one or more functionalities.
[0090] In an embodiment, the merchant application 126 may be configured to generate one or more graphical user interfaces (GUIs) in response to communication with the server system 102 for facilitating the authentication of a cardholder (such as the cardholder 104) in a frictionless manner associated with consent of the cardholder 104.
[0091] In one embodiment, the electronic device 106 is communicably coupled with the server system 102 through the network 124 and the electronic device 106 is capable of interacting with the merchant application 126 associated with the merchant 108 through a web browser or an Application Programming Interfaces (APIs) installed on the electronic device 106. In other words, the electronic device 106 of the cardholder 104 is capable of performing one or more operations using the merchant application 126. In one implementation, the merchant application 126 utilizes communication APIs to communicate back and forth with the electronic device 106.
[0092] In an example, the merchant application 126 utilizes various distribution methods for sharing one or more messages, requests, or responses with the electronic device 106 of the cardholder 104, the merchant application 126, the issuer server 116, the server system 102, the ACS, and the like. In various non-limiting examples, the distribution methods may include short message service (SMS), electronic mail (email), communication APIs, embeddable widgets, and the like. In an example, the merchant application 126 utilizes communication APIs to share the results of their various operations with the server system 102 or the electronic device 106.
[0093] In some embodiments, other examples of APIs that may be used by the merchant application 126 may include a supported version API, a preparation API, and the like. Herein, it is understood that the term “API” generally refers to a set of programming standards and/or instructions for web-based applications and tools. For instance, “communication APIs” refer to APIs specifically designed to enable communication (e.g., voice calls, e-mail functionality, third-party messaging functionality, other communication functionality, etc.).
[0094] Further, the term “supported version API” refers to an API that is provided by the DS for the merchants, so that merchants can fetch information regarding what versions of different components of the payment network 110 are supported by the cardholder 104 who is accessing a merchant application for making payment transactions. Herein, the components may include ACS, MPI, issuer server, acquirer server, etc. Similarly, the term “preparation API” refers to an API that is used by merchants and accepts PAN from the merchants via API calls, based on which the preparation API searches for PIN associated with the PAN.
[0095] In some scenarios, the merchant application 126 may include a mobile application or “app”. Herein, in various examples, the electronic device 106 may be an Android®-based smartphone, an iOS®-based iPhone®, iPadOS®-based iPad®, a Windows®-based computer, a macOS®-based computer, an augmented reality (AR) device, a virtual reality (VR) device, and the like. The merchant application 126 may also include a “plug-in” or an “extension” to another application, such as a pre-existing application (i.e., a third-party application) or API associated with the third-party application. In an implementation, the merchant application 126 is managed, hosted, or executed by the server system 102. In another implementation, the merchant application 126 is managed, hosted, or executed by a communication device (not shown in figures) associated with the merchant 108. In this scenario, the merchant application 126 is able to communicate with the server system 102 to perform various operations (described later on).
[0096] Further, it may be noted that, in an example, the server system 102 coupled with the database 114 is embodied within the payment server 112, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer server 116 and the acquirer server 120. The database 114 may be incorporated in the server system 102 or maybe an individual entity connected to the server system 102 or maybe a database stored in cloud storage.
[0097] In an embodiment, the server system 102 is associated with a database such as the database 114. In various non-limiting examples, the database 114 may include one or more Hard Disk Drives (HDD), Solid-State Drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a Redundant Array of Independent Disks (RAID) controller, a Storage Area Network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 114. In one implementation, the database 114 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 114.
[0098] In another embodiment, the server system 102 is configured to authenticate and allow communication between the MPI server 122 and the ACS 118. Therefore, the server system 102 authenticates and validates the various 3DS requests within the 3DS payment network. In a non-limiting example, the server system 102 may be a Directory Server (DS) in the interoperability domain of the 3DS payment network, and the server system 102 may be associated with the payment network 110. Further, the server system 102 may store various data elements associated with the various entities in the environment 100 in the database 114. In various examples, the data elements may include at least authentication certificates of various entities, cardholder details, issuer information, ACS information, MPI information, acquirer information, etc., among other suitable data elements. In an embodiment, the server system 102 is further configured to store one or more certificate attributes of the certificate associated with the ACS 118 when the ACS 118 is initialized in the 3DS payment network.
[0099] In an embodiment, assuming that the payment card used by the cardholder 104 for performing payment transactions is already registered on the merchant application 126 and is enabled with the frictionless payment option, the server system 102 is configured to receive a payment initiation request from the electronic device 106. The payment initiation request may correspond to a payment transaction being performed between a cardholder (e.g., the cardholder 104) and a merchant (e.g., the merchant 108). The payment initiation request may include a selected payment card and transaction-related information. In an embodiment, the transaction-related information may include at least a Personal Account Number (PAN) of the selected payment card. It is noted that the PAN is associated with a card number (card identifier (ID)) of a particular payment card held by the cardholder 104. Moreover, the PAN indicates an account number associated with a bank account of the cardholder 104.
[00100] In some embodiments, the transaction-related information may further include at least one of a transaction amount, a transaction date, a transaction time, a device ID associated with the electronic device 106, merchant information, authentication information, and the like. Moreover, it may be noted that the electronic device 106 may be associated with at least the merchant 108 and the cardholder 104.
[00101] In an example embodiment, for the server system 102 to be able to receive the payment initiation request, the server system 102 may further be configured to facilitate a display of a first GUI on the electronic device 106. Herein, the first GUI may be configured to prompt the cardholder 104 to select the payment card from one or more payment cards for performing the payment transaction. Further, as may be understood, the payment card is enabled with the frictionless payment option. Further, the server system 102 may be configured to receive a selection of the payment card and the transaction-related information associated with the selected payment card from the electronic device 106 via the MPI 122 associated with the electronic device 106.
[00102] Further, it may be noted that for authenticating the payment transaction, the server system 102 is configured to access stored payment card-related data associated with the selected payment card from the database 114 of the server system based, at least in part, on the PAN of the selected payment card. The stored payment card-related data may include a card-specific Personal Identification Number (PIN) and consent information. The term “card-specific PIN” refers to a PIN that is set by the cardholder 104 for authenticating a cardholder identity for performing payment transactions digitally, thereby securing the payment transactions from fraud. In an embodiment, the main motive of having the PIN is associated with the fact of making the performing of payment transactions more frictionless or reducing the friction for providing streamlining payment transactions.
[00103] Further, the term “consent” refers to an action to agree to something or allow something. Therefore, it may be noted that in an embodiment, the consent information may include information related to consent received from the cardholder 104, the consent being associated with the corresponding payment transaction. Herein, in an embodiment, it may be noted that the consent may be merchant, card, and device specific. Thus, it should be understood that if consent is taken from the cardholder 104 for a specific merchant, a specific card, and a specific device, then the same consent cannot be used for other merchants, other payment cards, and other devices. In an example embodiment, the consent information may include at least a consent description, a consent response, a consent type, a consent language, a consent ID, a consent language ID, and the like. It may be noted that the consent description may include a description of a predefined condition for which the consent of the cardholder 104 may be needed to facilitate the cardholder 104 to proceed with the payment transaction when enabled with the frictionless payment option. In other words, the consent description may include terms and conditions that are applied on the payment transaction that the cardholder 104 has to accept before proceeding with the payment transaction enabled with the frictionless payment option. For example, the predefined condition or the terms and conditions may include skipping sending of a One-time Password (OTP) for payment transactions below a predefined amount of transaction. In some scenarios, the predefined amount may correspond to small token values.
[00104] Furthermore, the server system 102 is configured to generate and transmit a cardholder authentication request to the electronic device 106. Herein, the cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card. In other words, the cardholder authentication request refers to a request that is displayed on a GUI on the electronic device 106 asking the cardholder 104 to provide a PIN for authenticating the cardholder identity. The cardholder 104 may provide a PIN as a cardholder authentication response.
[00105] Further, upon receiving the cardholder authentication response message including a PIN from the electronic device 106, the server system 102 is configured to perform an authentication of the cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN. In an embodiment, upon comparison, the server system 102 may generate one of a positive comparison result and a negative comparison result. Therefore, in an example embodiment, the server system 102 may generate a positive comparison result if the PIN matches with the card-specific PIN. Herein, the generation of the positive comparison result may correspond to a successful authentication of the cardholder identity.
[00106] Alternatively, in an embodiment, the server system 102 may generate a negative comparison result if the PIN does not match with the card-specific PIN. Herein, the generation of the negative comparison result may correspond to an unsuccessful authentication of the cardholder identity. Thus, it may be noted that upon unsuccessful authentication of the cardholder identity, the server system 102 may generate and transmit a payment failure message to the electronic device 106.
[00107] Further, upon successful authentication, the server system 102 is further configured to determine a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information. It may be noted that for the payment transaction to be valid, the consent that the cardholder 104 might have agreed upon as mentioned in the consent information may have to match with a transaction that the cardholder 104 is willing to make. For example, if the cardholder 104 has agreed that the OTP can be skipped for transactions of smaller token value such as at least Rupees 2000, then when the frictionless payment option is enabled for the payment card, then the cardholder 104 can make a transaction that is less than or equal to the smaller token values such as Rupees 2000. In an embodiment, it may be noted that the smaller token value may be any value for a transaction that may be associated with lower fraud risk or a transaction that is allowed by the government or a central bank to be processed without generating any OTP.
[00108] Finally, upon determining that the payment transaction is valid, the server system 102 is configured to generate and transmit a payment authentication message to an issuer server (e.g., the issuer server 116) associated with the cardholder 104. Herein, it may be noted that the payment authentication message may indicate a message informing the issuer to authenticate the cardholder 104 to perform the payment transaction as the transaction is valid and instructions for the issuer to transfer the amount corresponding to the payment transaction from the issuer bank associated with the cardholder 104 to the acquirer bank associated with the merchant 108.
[00109] Further, in an embodiment, the server system 102 may be configured to transmit a transaction successful notification to at least one of the merchant 108 and the cardholder 104 when the payment transaction is completed between the issuer server 116 and the acquirer server 120 associated with the merchant 108.
[00110] In an embodiment, upon determining that the payment transaction is invalid, the server system 102 may be configured to generate and transmit, a payment failure message to the electronic device 106, and hence the payment transaction fails.
[00111] In some scenarios, while checking out the cardholder 104 might forget the PIN. Therefore, to facilitate the cardholder 104 to proceed with making the payment transaction, the server system 102 may be configured to receive a forgot PIN message from the cardholder 104 via the electronic device 106 in response to the cardholder authentication request.
[00112] Further, the server system 102 may be configured to facilitate a display of a second GUI on the electronic device 106. Herein, the second GUI is configured to prompt the cardholder 104 to set a new card-specific PIN for the authentication of the cardholder identity. Upon receiving the new card-specific PIN, the server system 102 may be configured to transmit a cardholder authentication request to the issuer server 116 for authenticating the cardholder 104 to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information.
[00113] In an embodiment, the server system 102 may transmit the cardholder authentication request via the MPI 122 to the ACS 118 of the issuer server 116. Upon receiving the cardholder authentication request, the ACS 118 may prompt the issuer server 116 to generate an OTP and transmit the same to the cardholder 104 on the electronic device 106 in the form of a text message or an e-mail. Upon receiving the OTP, the cardholder 104 may receive a display of an issuer-based GUI via the merchant application 126, prompting the cardholder 104 to enter the OTP on the issuer-based GUI. The OTP is then transmitted to the issuer server 116. Upon receiving the OTP, the issuer server 116 compares it with the OTP that the issuer server 116 had shared with the cardholder 104 via the text message or the e-mail. Upon comparison, if the OTP matches, the issuer server 116 may respond with a successful authentication message and transmit the same to the merchant 108 via the merchant application 126. Alternatively, if the OTP does not match, then the issuer server 116 may respond with an unsuccessful authentication message and transmit the same to the merchant 108 via the merchant application 126. In this scenario, the cardholder 104 may be provided with a predefined count of trails to re-enter the correct OTP or re-generate a new OTP, if the OTP is not received, or abandon the transaction.
[00114] In an embodiment, upon successful authentication by the issuer server 116, i.e., upon receiving the successful authentication message, the server system 102 may be configured to store the new card-specific PIN against the PAN based, at least in part, on linking a card ID of the payment card having the PAN with the consent information. Herein, the new card-specific PIN can be used for subsequent transactions.
[00115] In some embodiments, while checking out on the merchant application 126, the cardholder 104 might want to revoke consent for a specific payment card of one or more payment cards that may be associated with the cardholder 104. Therefore, during such scenarios, the server system 102 may further be configured to facilitate a display of a third GUI on the electronic device 106. The third GUI is configured to prompt the cardholder 104 to select a consent revocation option.
[00116] Further, the server system 102 may be configured to receive a selection of the consent revocation option associated with the payment card from the electronic device 106 via the MPI 122 associated with the electronic device 106. Upon receiving the corresponding selection, the server system 102 may be configured to update the stored consent-related information with a revocation of the consent by the cardholder 104 for the consent description.
[00117] It may be noted that, in scenarios when the cardholder 104 may be using the merchant application 126 for the first time using a payment card that is enabled with the frictionless payment option for making transactions with another merchant, the payment card may have to be first registered with the merchant application 126 and get the frictionless payment option enabled for the payment card. Therefore, in an embodiment, the server system 102 may be configured to facilitate a display of a fourth GUI on the electronic device 106. The fourth GUI may be configured to prompt the cardholder 104 to select the frictionless payment option from one or more payment options (or payment methods) to perform a new payment transaction when using a new payment card on the electronic device 106 that is not registered for the frictionless payment option.
[00118] The server system 102 may further be configured to receive a selection of the new payment card and new transaction-related information associated with the new payment card from the electronic device 106 via the MPI 122 associated with the electronic device 106. The new transaction-related information may include at least a PAN of the new payment card.
[00119] Further, the server system 102 may be configured to access new payment card-related data associated with the new payment card from the database 114. The server system may further be configured to perform a verification of the PAN of the new payment card to be linked with a card-specific PIN associated with the consent information based, at least in part, on the new payment card-related data.
[00120] Upon successful verification, the server system 102 may be configured to facilitate a display of a fifth GUI on the electronic device 106. The fifth GUI may be configured to prompt the cardholder 104 to provide a consent response for a consent description being displayed to the cardholder 104 via the fifth GUI based, at least in part, on the consent information. Herein, it may be noted that the successful varication may indicate the presence of the card-specific PIN associated with the consent information that is been linked with the PAN of the new payment card in the database 114.
[00121] Upon receiving a valid consent response, the server system 102 may be configured to store the received consent response for the corresponding consent description in the database 114 as updated consent information based, at least in part, on linking a card ID of the new payment card having the PAN with the received consent response. Herein the valid consent response may correspond to a consent response including a consent approval flag. Moreover, this consent response might match with the consent response associated with the consent information stored in the database 114. However, if the consent response is invalid i.e., the consent response includes a consent denial flag, then it may be noted that the new payment card cannot be registered for the frictionless payment option and an unsuccessful registration message may be sent to the electronic device 106. This is because, for the cardholder 104 to register for the frictionless payment option, the cardholder 104 may have to provide their consent by accepting the predefined condition mentioned in the consent description.
[00122] Upon successful storage of the received consent response, the server system 102 may be configured to register the new payment card on the electronic device 106 for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data and the received consent response.
[00123] In an embodiment, it may be noted that upon unsuccessful verification, the server system 102 may facilitate a display of the fifth GUI on the electronic device 106. The fifth GUI may be configured to prompt the cardholder 104 to provide a consent response for a consent description being displayed to the cardholder 104 via the fifth GUI.
[00124] Upon receiving a valid consent response, the server system may facilitate a display of a sixth GUI on the electronic device 106. The sixth GUI may be configured to prompt the cardholder 104 to provide a new card-specific PIN for the authentication of the cardholder identity.
[00125] Further, upon receiving the new card-specific PIN, the server system 102 may transmit a cardholder authentication request to the issuer server 116 for authenticating the cardholder 104 to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information. Herein, the authentication process performed at the issuer server 116 is an OTP-based authentication. Upon successful authentication, the server system 102 may store the received consent response for the corresponding consent description as new consent information and the new card-specific PIN based, at least in part, on linking the new consent information and the new card-specific PIN with the PAN of the new payment card. In addition, the issuer server 116 may respond with a successful authentication message and transmit the same to the merchant 108 via the merchant application 126.
[00126] However, upon unsuccessful authentication, the issuer server 116 may respond with an unsuccessful authentication message and transmit the same to the merchant 108 via the merchant application 126. Moreover, in this scenario, the cardholder 104 may be provided with a predefined count of trails to re-enter the correct OTP or re-generate a new OTP if the OTP is not received, or abandon the transaction.
[00127] Upon successful storage of the received consent response and the new card-specific PIN, the server system 102 may register the new payment card on the electronic device 106 for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data, the received consent response, and the new card-specific PIN.
[00128] In one embodiment, the payment network 110 may be used by the payment card issuing authorities as a payment interchange network. Examples of payment interchange networks include but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of electronic payment transaction data between issuers and acquirers that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[00129] 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 is shown in FIG. 1 may be implemented as multiple, distributed systems or devices. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 124, which may be specifically configured, via executable instructions, to perform steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
[00130] FIG. 2 illustrates a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. The server system 200 is identical to the server system 102 of FIG. 1. In one embodiment, the server system 200 is a part of the payment network 110 or integrated within the payment server 112. In some embodiments, the server system 200 is embodied as a cloud-based and/or software as a service (SaaS)-based architecture.
[00131] The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, a user interface 212, and a storage interface 214. The one or more components of the computer system 202 communicate with each other via a bus 216. The components of the server system 200 provided herein may not be exhaustive and the server system 200 may include more or fewer components than those depicted in FIG. 2. Further, two or more components depicted in FIG. 2 may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities.
[00132] In some embodiments, the database 204 is integrated into the computer system 202. In one non-limiting example, the database 204 is configured to store transaction-related information 218, stored payment card-related data 220, a payment card ID 222 associated with the payment card used by the cardholder 104 for making the payment transaction, and a device ID 224 associated with the electronic device 106 used by the cardholder 104 for making the payment transaction.
[00133] Further, the computer system 202 may include one or more hard disk drives as the database 204. The user interface 212 is an interface such as a Human Machine Interface (HMI) or a software application that allows users such as an administrator to interact with and control the server system 200 or one or more parameters associated with the server system 200. It may be noted that the user interface 212 may be composed of several components that vary based on the complexity and purpose of the application. Examples of components of the user interface 212 may include visual elements, controls, navigation, feedback and alerts, user input and interaction, responsive design, user assistance and help, accessibility features, and the like. More specifically these components may correspond to icons, layout, color schemes, buttons, sliders, dropdown menus, tabs, links, error/success messages, mouse and touch interactions, keyboard shortcuts, tooltips, screen readers, and the like.
[00134] The storage interface 214 is any component capable of providing the processor 206 access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204.
[00135] The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for performing authentication of the cardholder 104 in a frictionless manner with an additional factor of authentication on top of consent. Examples of the processor 206 include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a graphical processing unit (GPU), a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), and the like.
[00136] The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
[00137] The processor 206 is operatively coupled to the communication interface 210, such that the processor 206 is capable of communicating with a remote device 226 such as the issuer server 116, the acquirer server 120, the payment server 112, or communicating with any entity connected to the network 124 (as shown in FIG. 1).
[00138] It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2. It should be noted that the server system 200 is identical to the server system 102 described in reference to FIG. 1. Moreover, it may be noted that the registration module 228, the GUI generation module 232, and the authentication module 230 may be communicably coupled with each other to exchange information with each other for performing the one or more operations facilitated by the server system 200.
[00139] In one implementation, the processor 206 includes a registration module 228, an authentication module 230, and a Graphical User Interface (GUI) generation module 232. It should be noted that components, described herein, such as the registration module 228, the authentication module 230, and the GUI generation module 232 can be configured in a variety of ways, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
[00140] In an embodiment, the registration module 228 includes suitable logic and/or interfaces for receiving a payment initiation request from an electronic device (e.g., the electronic device 106) for a payment transaction being performed between a cardholder (e.g., the cardholder 104) and a merchant (e.g., the merchant 108). The payment initiation request may include a selected payment card and the transaction-related information 218. The transaction-related information 218 may include at least a Personal Account Number (PAN) of the selected payment card.
[00141] Further, for receiving the payment initiation request, the registration module 228 may be configured to display a first Graphical User Interface (GUI) on the electronic device 106. The first GUI is configured to prompt the cardholder 104 to select the payment card from one or more payment cards for performing the payment transaction. The payment card may or may not be enabled with a frictionless payment option.
[00142] As may be understood that the GUI generation module 232 includes suitable logic and/or interfaces for generating one or more GUIs to be displayed on the electronic device 106 for facilitating the cardholder 104 to perform one or more operations such as to select a payment card, to provide a card-specific Personal Identification Number (PIN), to provide a consent response, set a new card-specific PIN, provide a new consent response, to select the frictionless payment option, to select a forgot PIN option, to select a consent revocation option, and the like. In an embodiment, the one or more GUIs may include the first GUI, a second GUI, a third GUI, a fourth GUI, a fifth GUI, a sixth GUI, and the like depending upon the one or more operations to be performed by the cardholder 104. It may be noted that as the cardholder 104 may perform the one or more operations, the server system 200 may be receiving one or more inputs via the one or more GUIs.
[00143] The registration module 228 may further be configured to access the stored payment card-related data 220 associated with the selected payment card from the database 204 of the server system 200 based, at least in part, on the PAN of the selected payment card. The registration module 228 may be configured to determine whether the selected payment card is registered for the frictionless payment option based, at least in part, on the stored payment card-related data 220.
[00144] Upon determining that the selected payment card is registered for the frictionless payment option, it may be noted that the stored payment card-related data 220 may include a card-specific PIN and consent information. Herein, in an embodiment, while accessing the stored payment card-related data 220, the authentication module 230 may also search for a payment card ID 222 associated with the selected payment card, and a device ID 224 associated with the electronic device 106 that the cardholder 104 may be using performing the payment transaction in a frictionless mode. It may be noted that the payment card ID 222, the device ID 224 along with the card-specific PIN, and the consent information may be stored in the database 204 upon hashing using a hashing technique. Herein, it may be noted that hashing is a one-way encryption technique that uses a hash function to scramble data for encryption without using special logical keys and cannot be reverse-engineered to get the original data. In a non-limiting example, the hash function may be built using an HMAC256 algorithm. As used herein, the term “HMAC256 algorithm” refers to a type of keyed hash algorithm that is constructed from a SHA-256 hash function and used as a Hash-based Message Authentication Code (HMAC). Moreover, it may be noted that the authentication module 230 may store the payment card ID 222, the device ID 224, the card-specific PIN, and the consent information in the database 204 by generating a combination string based, at least in part, on the payment card ID 222, the device ID 224, the card-specific PIN, and the consent information.
[00145] Further, the authentication module 230 includes suitable logic and/or interfaces for generating and transmitting a cardholder authentication request to the electronic device 106. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card.
[00146] Upon receiving a cardholder authentication response message including a PIN from the electronic device 106, the authentication module 230 performs an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN. Upon successful authentication, the authentication module 230 determines a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information 218. However, upon unsuccessful authentication of the cardholder identity, the authentication module 230 may generate and transmit a payment failure message to the electronic device 106.
[00147] Further, upon determining that the payment transaction is valid, the authentication module 230 generates and transmits a payment authentication message to an issuer server (e.g., the issuer server 116) associated with the cardholder 104. Furthermore, in an embodiment, the authentication module 230 may transmit a transaction successful notification to at least one of the merchant 108 and the cardholder 104 when the payment transaction is completed between the issuer server 116 and an acquirer server (e.g., the acquirer server 120) associated with the merchant 108. However, upon determining that the payment transaction is invalid, authentication module 230 may generate and transmit a payment failure message to the electronic device 106.
[00148] In some scenarios, the registration module 228 may receive a forgot PIN message from the cardholder 104 via the electronic device 106 in response to the cardholder authentication request. The registration module 228 may facilitate a display of the second GUI on the electronic device 106. The second GUI may be configured to prompt the cardholder 104 to set a new card-specific PIN for the authentication of the cardholder identity.
[00149] Further, the authentication module 230 may be configured to receive the new card-specific PIN via the second GUI. Upon receiving the new card-specific PIN, the authentication module 230 may transmit a cardholder authentication request to the issuer server 116 to authenticate the cardholder 104 to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information 218. Herein, it may be noted that the authentication of the cardholder identity performed by the issuer server 116 may be OTP-based and since it is a well-known authentication process, it is not elaborated here for the sake of brevity.
[00150] Upon successful authentication by the issuer server 116, the authentication module 230 may be configured to store the new card-specific PIN based, at least in part, on linking the payment card ID 222 of the selected payment card having the PAN with the consent information. In an embodiment, it may be noted that while storing the new card-specific PIN, the new card-specific PIN, the consent information, and other data such as the payment card ID 222 and the device ID 224 may be hashed, and linked with each other for forming a combination string and then the combination string is stored in the database 204 in a hashed form. Herein, the new card-specific PIN can be used for subsequent transactions.
[00151] In some scenarios, the registration module 228 may be configured to facilitate a display of the third GUI on the electronic device 106. The third GUI may be configured to prompt the cardholder 104 to select a consent revocation option. Further, the registration module 228 may be configured to receive a selection of the consent revocation option associated with the payment card from the electronic device 106 via a merchant plug-in interface (MPI) 122 associated with the electronic device 106. Upon receiving the corresponding selection, the registration module 228 may update the stored consent-related information with a revocation of the consent by the cardholder 104 for the consent description.
[00152] Further, in some scenarios, the registration module 228 may be configured to register a new payment card on the electronic device 106 for the frictionless payment option to be used for subsequent payment transactions on the merchant application 126.
[00153] In an embodiment, it may be noted that if the new payment card is already registered for the frictionless payment option on a different merchant application and/or a different electronic device, then the registration module 228 may be configured to register the new payment card for the frictionless payment option based, at least in part, on new payment card-related data and received consent response. In such an embodiment, for registering the new payment card, the registration module 228 may facilitate a display of the fourth GUI on the electronic device 106. The fourth GUI may be configured to prompt the cardholder 104 to select the frictionless payment option from one or more payment options to perform a new payment transaction when using the new payment card on the electronic device 106 that is not registered for the frictionless payment option.
[00154] Further, the registration module 228 may be configured to receive a selection of the new payment card and new transaction-related information associated with the new payment card from the electronic device 106 via the MPI 122 associated with the electronic device 106. The new transaction-related information may include at least a PAN of the new payment card. The registration module 228 may further access the new payment card-related data associated with the new payment card from the database 204. Further, the registration module 228 may perform a verification of the PAN of the new payment card to be linked with a card-specific PIN associated with the consent information based, at least in part, on the new payment card-related data.
[00155] Upon successful verification, the authentication module 230 may facilitate a display of the fifth GUI on the electronic device 106 The fifth GUI may be configured to prompt the cardholder 104 to provide a consent response for a consent description being displayed to the cardholder 104 via the fifth GUI based, at least in part, on the consent information.
[00156] Upon receiving a valid consent response, the registration module 228 may store the received consent response for the corresponding consent description in the database 204 as updated consent information based, at least in part, on linking a payment card ID of the new payment card having the corresponding PAN with the card-specific PIN. In an embodiment, it may be noted that while storing the updated consent information, the card-specific PIN, the updated consent information, and other data such as the payment card ID and the device ID 224 may be hashed, and linked with each other for forming a combination string and then the combination string is stored in the database 204 in a hashed form.
[00157] Upon successful storage of the received consent response, the registration module 228 may register the new payment card on the electronic device 106 for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data and the received consent response.
[00158] In another embodiment, if the new payment card is not registered on any of the merchant applications in the past, then the registration module 228 may register the new payment card for the frictionless payment option based, at least in part, on new payment card-related data, received consent response, and new card-specific PIN. In such an embodiment, upon unsuccessful verification, the authentication module 230 may facilitate a display of the fifth GUI on the electronic device 106. The fifth GUI may be configured to prompt the cardholder 104 to provide a consent response for a consent description being displayed to the cardholder 104 via the fifth GUI.
[00159] Upon receiving a valid consent response, the authentication module 230 may facilitate a display of the sixth GUI on the electronic device 106. The sixth GUI may be configured to prompt the cardholder 104 to provide a new card-specific PIN for the authentication of the cardholder identity. Upon receiving the new card-specific PIN, the authentication module 230 may transmit a cardholder authentication request to the issuer server 116 to authenticate the cardholder 104 to use the new card-specific PIN for subsequent payment transactions. The cardholder authentication request may include the selected payment card and the transaction-related information.
[00160] Upon successful authentication, the registration module may store the received consent response for the corresponding consent description as new consent information and the new card-specific PIN based, at least in part, on linking the new consent information and the new card-specific PIN with the PAN of the new payment card. In an embodiment, it may be noted that while storing the new consent information and the new card-specific PIN, the card new consent information the new card-specific PIN, and other data such as a payment card ID associated with a new payment card and the device ID 224 may be hashed and linked with each other for forming a combination string and then the combination string is stored in the database 204 in a hashed form.
[00161] Further, upon successful storage of the received consent response and the new card-specific PIN, the registration module 228 may register the new payment card on the electronic device 106 for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data, the received consent response, and the new card-specific PIN.
[00162] FIG. 3A illustrates a block diagram representation 300 depicting a high-level flow of authenticating a cardholder (e.g., the cardholder 104) during a first-time checkout (see, 302), in accordance with an embodiment of the present disclosure. In an embodiment, suppose the cardholder 104 checks out on a merchant application (e.g., the merchant application 126) associated with a merchant (e.g., the merchant 108) for the first time using a payment card. In cases where the cardholder 104 utilizes the merchant application 126 for the initial time to make a purchase, it’s important to note that the payment card used by the cardholder 104 might not yet be registered within the confines of the merchant application 126. Consequently, it becomes imperative to undertake the registration process for the payment card within the merchant application 126. A critical step in this process is to ascertain whether the payment card possesses the feature of a frictionless payment option, an essential consideration for upcoming transactions.
[00163] In one embodiment, during the cardholder’s initial checkout (see, 302), the server system 200 enables the merchant 108 to retrieve consent language and prompts the cardholder 104 to optionally accept consent. This is achieved by displaying one or more graphical user interfaces (GUIs) on the electronic device 106 through the merchant application 126. As the consent and related information have been previously explained, they are not reiterated here for the sake of brevity.
[00164] In addition, once the consent is accepted by the cardholder 104, the server system 200 facilitates the merchant 108 to request the cardholder 104 to set an Additional Factor of Authentication (AFA) i.e., request the cardholder 104 to set a card-specific Personal Identification Number (PIN) (or a PIN) that can be used for the authentication purpose during subsequent payment transactions. In response to the request from the merchant, the cardholder 104 may provide a PIN to be set as the card-specific PIN. Subsequently, the cardholder 104 may have to be authenticated to use the PIN for subsequent transactions. Therefore, the PIN is transmitted to a Directory Server (DS) (e.g., the DS 304) that is deployed with the server system 200 in the form of an authentication request. Here, the term “Directory Server” refers to a server that is generally managed by a payment network and is associated with a payment gateway. The directory server performs essential functions, including authenticating 3DS Server requests, verifying 3DS requestors as trusted and registered entities, maintaining account and ACS routing data, and facilitating the routing of 3DS messages between the 3DS Server and the ACS. It may be noted that an example of a Directory Server is Mastercard®.
[00165] Therefore, it may be understood that the authentication request that is transmitted from the merchant application 126 to the DS 304 may be transmitted for performing authentication with consent and the card-specific PIN (see, 306). Subsequently, the DS 304, facilitated by the server system 200, conducts cardholder authentication via an Access Control Server (ACS) 308 linked with the issuer server 116. During the first-time checkout, the authentication with a challenge (see, 312) is implemented by the ACS at the issuer server 116, which may involve transmitting a One-time Password (OTP) to the cardholder 104 through a communication channel, followed by a request for the cardholder 104 to enter the OTP on the merchant application 126 for authentication. Consequently, the issuer server 116 transmits the OTP to authenticate the cardholder 104 (see, 310) and then the DS 304 is notified about the outcome. Upon successful authentication, the DS 304 stores both the consent and the card-specific PIN for the payment card of the cardholder 104 in the database 204. This is achieved by linking them, as well as with a device ID, the cardholder card ID, and a consent type.
[00166] FIGS. 3B and 3C, collectively, illustrate a process flow diagram 320 of a detailed flow of authenticating the cardholder (e.g., the cardholder 104) during the first-time checkout (see, 322), in accordance with an embodiment of the present disclosure. As may be understood that the cardholder 104 is checking out for the first time on the merchant application 126 installed in the electronic device 106, the merchant application 126 may request the cardholder 104 to register their payment card on the merchant application 126. In an embodiment, the merchant application 126 may also request the cardholder 104 to register the payment card for a frictionless payment option.
[00167] The merchant application 126 has a crucial role in facilitating various tasks. It needs to enable the registration of the payment card, a step essential for the automatic retrieval of card details in subsequent transactions within the merchant application 126. This registration process also ensures that the payment card is set up for the frictionless payment option. To achieve these functions, the merchant application 126 establishes communication with both the payment gateway associated with a DS (e.g., the DS 304) and the server system 200 associated with this DS 304. In one specific embodiment, the merchant application 126 is equipped with a Merchant Plug-in Interface (MPI) such as the MPI 122. This inclusion allows the merchant application 126 to establish communication with the DS 304 and/or the server system 200. In another distinct embodiment, the merchant application 126 achieves this communication through API (Application Programming Interface) calls, utilizing APIs provided by the DS 304 and/or the server system 200.
[00168] Therefore, in one embodiment, it’s worth noting that when the cardholder 104 checks out for the first time on the merchant application 126, the following operations may take place.
[00169] At operation 324, the server system 200 facilitates the merchant 108 to make API calls through the merchant application 126. These API calls are directed at one or more supported version APIs, with the goal of retrieving information about the versions of various components within the payment network 110 that are compatible with the cardholder 104 accessing the merchant application 126 for their payment transactions. Herein, the components may include ACS, MPI, issuer server, acquirer server, etc. In an embodiment, PAN is obtained upon making such API calls.
[00170] At operation 326, the server system 200 facilitates the merchant 108 to call at least one preparation API associated with the DS 304 via the merchant application 126 for determining if a card-specific PIN (hereinafter, interchangeably referred to as a PIN) is already present in the database 204 and is linked with the PAN. In an embodiment, if the card-specific PIN is already present in the database 204 and is linked with the PAN, then the merchant 108 may use the token PAN to call the at least one preparation API.
[00171] At operation 328, the server system 200 facilitates the DS 304 to determine whether the PAN / linked with the PIN is checked (indicated in FIG. 3B as ‘PAN-PIN present’) in the database 204. If the PIN is present and is already linked with the PAN, the process moves to operation 330, otherwise to operation 332.
[00172] At operation 330, the server system 200 facilitates the merchant 108 to display a GUI showing a consent description to the cardholder 104 via the merchant application 126.
[00173] Upon displaying the consent description on the electronic device 106, the cardholder 104 may respond by either accepting or denying the consent. Therefore, it may be noted that at operation 334, the cardholder 104 accepts the consent. Once the cardholder 104 accepts the consent, the process flow moves to operation 336.
[00174] At operation 336, the server system 200 facilitates the merchant 108 to transmit the consent response to the DS 304 in the form of an authentication request (AREQ) via the merchant application 126. When the DS 304 receives the authentication request, the process flow moves to operation 338.
[00175] At operation 338, the server system 200 facilitates the DS 304 to extract data and wait for a successful authentication response (RREQ) from the issuer (e.g., the issuer 116). The process flow then moves to operation 340.
[00176] At operation 340, the server system 200 determines whether the authentication response corresponds to successful authentication or unsuccessful authentication. If the authentication response corresponds to successful authentication, then the process flow moves to operation 342.
[00177] At operation 342, the server system 200 stores the consent response of the cardholder 104 for the consent description and the process flow moves to operation 344. In an embodiment, upon storing the consent response, the process flow may alternatively move to operation 360. However, if the authentication response corresponds to unsuccessful authentication, the process flow moves to operation 346.
[00178] At operation 344, the server system 200 initiates Authentication Enablement Service (AES). Herein, it may be noted that the AES is another service that may be facilitating the DS 304 for performing the authentication process. In a non-limiting example, the AES may be initiated by the server system 200 via an AES module.
[00179] At operation 346, the server system 200 associated with DS does not initiate the AES and fails the authentication process of authenticating the cardholder 104 or the payment transaction.
[00180] At operation 332, the server system 200 facilitates the merchant 108 to display GUIs corresponding to the consent description and a PIN requesting screen to the cardholder 104 via the merchant application 126 on the electronic device 106. Herein, it may be noted that the server system 200 facilitates the merchant 108 to use a PIN software development kit (SDK) to hash the PIN from the merchant 108. The process flow then moves to operation 348.
[00181] At operation 348, the cardholder 104 accepts the consent and enters a PIN or a card-specific PIN on the PIN screen as input for creating a new PIN as it is the first time using the frictionless option. The process flow then moves to operation 350.
[00182] At operation 350, the merchant 108 transmits the consent response and PIN (hashed PIN) upon hashing the PIN to the DS 304 in the form of an authentication request (AREQ). When the DS 304 receives the authentication request, the process flow moves to operation 352.
[00183] At operation 352, the DS 304 extracts data and waits for a successful authentication response (RREQ) from the issuer (e.g., the issuer 116). The process flow then moves to operation 354.
[00184] At operation 354, the server system 200 determines whether the authentication response (RREQ) corresponds to successful authentication or unsuccessful authentication. If the authentication response corresponds to successful authentication, then the process flow moves to operation 344. In an embodiment, the process flow also performs operation 342. However, if the authentication response corresponds to unsuccessful authentication, the process flow moves to operation 356.
[00185] At operation 356, the server system 200 associated with DS 304 does not initiate the AES and fails the authentication process of authenticating the cardholder 104 or the payment transaction.
[00186] Upon the start of the AES, the process flow moves to operation 358. At operation 358, the server system 200 hashes the PAN. In an embodiment, the server system 200 may hash the PAN using the hashing technique. The process flow moves to 360.
[00187] At operation 360, the server system 200 checks if the PIN is present in the authentication request. If the PIN is present the process flow moves to operation 362, otherwise it moves to operation 364.
[00188] At operation 362, the server system 200 hashes the PIN and a device ID associated with the electronic device 106 that is used by the cardholder 104 for performing the payment transaction. The process flow then moves to operation 370.
[00189] At operation 364, the server system 200 is directed to check if the hashed PIN is already linked with the hashed PAN in the database 204. The process flow moves to operation 366.
[00190] At operation 366, the server system determines whether the PIN is present or not. If the PIN is present in the database 204, then the process flow moves to operation 362, otherwise, the process flow moves to operation 368.
[00191] At operation 368, the server system 200 transmits an error message to the DS 304 which is further notified to the merchant 108 and the cardholder 104. Herein, it may be noted that the server system 200 may process the transaction as usual and request the ACS to authenticate the cardholder 104. Alongside this, the information regarding the PIN being absent for the corresponding PAN may be included in the RREQ to make sure that the merchant 108 and the cardholder 104 are aware of frictionless failure and the reason for OTP.
[00192] At operation 370, the server system 200 is directed to search for consent language ID in the database 204. The process flow moves to operation 372.
[00193] At operation 372, the server system 200 determines whether the consent language ID is present in the database 204 or not. If the consent language ID is found in the database 204, the process flow moves to 374, otherwise, the process flow moves to 376.
[00194] At operation 376, the server system 200 fetches the consent language from the AES module and the process flow moves to operation 374, where the consent language is stored in the database 204 (see, 378).
[00195] At operation 374, the server system 200 is directed to fetch card ID from the database 204 for PAN. The process flow moves to operation 380. In an embodiment, the server system 200 may also search for the card ID in an alternative database. An example of the alternative database may include Redis®.
[00196] At operation 380, the server system 200 searches for the card ID. If the card ID is found then the process flow moves to operation 382, otherwise the process flow moves to operation 384. In an embodiment, if the card ID is found, as the process flow moves to operation 382, at operation 386, the server system 200 stores the card ID in the database 204.
[00197] At operation 382, the server system 200 fetches the device ID from the AES module. The process flow then moves to operation 388.
[00198] At operation 384, the server system 200 creates the card ID for the hashed PAN in the AES module. Then the process flow moves to operation 382.
[00199] At operation 388, the server system 200 is configured to search for the device ID in the database 204. Herein the device ID may refer to a unique ID representing an application installation on the electronic device 106 to make sure that the installation is unique amongst others. If the device ID is found, then the process flow moves to operation 390, otherwise to operation 392. In an embodiment, the device ID may also be searched in the alternative database.
[00200] At operation 390, the server system 200 is configured to create a combination string of the card ID, the threeDSRequestor ID, the consent type, and the device ID. The process flow then moves to operation 396. In an embodiment, it may be noted that the consent is unique for the payment card or the PAN, the merchant, the consent type, and the device ID, and hence the combination string generated can be referred to as a logical key. The consent may be stored against the logical key. Therefore, for subsequent transactions, all the data may be fetched and the logical key may be formed and the server system 200 may check if consent is present in the database 204 for this consent.
[00201] At operation 392, the server system 200 is configured to create the device ID and move the process flow to operation 394 for storing the device ID in the database 204. Upon storing the device ID, the process flow moves to operation 390.
[00202] At operation 396, the server system 200 is configured to search consent in the database 204 for the combination string. Therefore, the process flow moves to operation 398.
[00203] At operation 398, the server system 200 searches in the database 204 for the consent. If the consent is found then the process flow moves to operation 400, otherwise, the process flow moves to operation 402.
[00204] At operation 400, the server system 200 is configured to update the consent in the AES module. The process flow moves to operation 404.
[00205] At operation 402, the server system 200 is configured to create new consent in the AES module. The process flow moves to operation 404.
[00206] At operation 404, the server system 200 is configured to identify whether the consent in the AES module is created or updated or not. If yes, the process flow moves to operation 406, otherwise, the process flow moves to operation 408.
[00207] At operation 406, the server system 200 is configured to save or update the consent in the database 204 for the combination string. The process flow then moves to operation 410.
[00208] At operation 408, the server system 200 is configured to send an error message to the DS 304.
[00209] At operation 410, the server system 200 is configured to store the PIN and the hashed PIN for the corresponding card ID in the database 204. Further, the process flow moves to operation 412.
[00210] At operation 412, the server system 200 is configured to prepare a success response.
[00211] At operation 414, the server system 200 is configured to transmit the success response to the merchant 108 and the cardholder 104 via the merchant application 126.
[00212] FIG. 4A illustrates a block diagram representation 420 depicting a high-level flow of authenticating a cardholder (e.g., the cardholder 104) during a subsequent checkout (see, 422), in accordance with an embodiment of the present disclosure. In an embodiment, suppose during a previous transaction the cardholder 104 on a merchant application (e.g., the merchant application 126) associated with a merchant (e.g., the merchant 108), the cardholder 104 got a payment card of the cardholder 104 registered for a frictionless payment option. As the cardholder 104 is using the merchant application 126 for the subsequent time for making a purchase, the payment card that the cardholder 104 is using will already be registered on the merchant application 126 and hence it may be noted that the DS 304 itself will authenticate consent, and the card-specific PIN (see, 424) as there is no need to transfer the authentication request received from the merchant 108 via the merchant application 126 to ACS. This reduces the friction that might have otherwise caused and made the cardholder 104 experience the same during the payment transaction.
[00213] In one embodiment, when the cardholder 104 checks out for the subsequent time it may be noted that the server system 200 facilitates the merchant 108 to request the cardholder 104 to provide the card-specific PIN that is used for the authentication purpose when the consent is already present. The cardholder 104 may respond with a PIN. Now the cardholder 104 may have to be authenticated based on the PIN received. Therefore, the PIN is transmitted to the DS 304 that is deployed with the server system 200 in the form of an authentication request.
[00214] Therefore, it may be understood that the authentication request that is transmitted from the merchant application 126 to the DS 304 may be transmitted for performing authentication with consent and the card-specific PIN (see, 424). Thus, the DS 304 via the server system 200 authenticates the cardholder 104 with a stored challenge that was obtained from the ACS during the first-time checkout. This is followed by authenticating the cardholder identity based on stored consent and stored PIN.
[00215] Further, the DS 304 authenticates the cardholder identity if the consent is present, the received PIN matches with the stored PIN, and other criteria are met. Otherwise, the DS requests the ACS to perform the authentication step in a way as described in the description with reference to FIG. 3A.
[00216] FIG. 4B illustrates a process flow diagram 430 of a detailed flow of authenticating a cardholder (e.g., the cardholder 104) during the subsequent checkout (see, 432), in accordance with an embodiment of the present disclosure. As may be understood that the cardholder 104 has already registered their payment card on the merchant application 126 installed in the electronic device 106, as the current process is for the subsequent checkout. To that note, the merchant application 126 may have a consent ID for the PAN of the payment card that is registered on the merchant application 126.
[00217] Thus, in an embodiment, it may be noted that upon checking out on the merchant application 126 for a subsequent payment transaction, the following operations may be performed.
[00218] At operation 434, as the merchant application 126 already has the consent ID, the server system 200 accesses the consent ID from the database 204.
[00219] At operation 436, the server system 200 facilitates the merchant 108 to use the SDK to display a GUI of a PIN screen for receiving PIN (card-specific PIN) for verification of the cardholder identity via the merchant application 126.
[00220] At operation 438, the cardholder 104 enters the PIN for verification.
[00221] At operation 440, the server system 200 facilitates the merchant 108 to transmit a hashed PIN to the DS 304 in the form of an authentication request (AREQ). When the DS 304 receives the authentication request, the process flow moves to operation 442.
[00222] At operation 442, the server system 200 facilitates the DS 304 to extract data and apply frictionless rules on the extracted data. The process flow then moves to operation 444.
[00223] At operation 444, the server system 200 determines whether a PIN is present in the database 204 and whether the payment card linked with the PIN is enabled with the frictionless option. If yes, then the process flow moves to operation 446, otherwise, it moves to operation 448.
[00224] At operation 448, the server system 200 or the DS 304 requests the ACS to authenticate the cardholder identity.
[00225] At operation 446, the server system 200 initiates the AES.
[00226] At operation 450, the server system 200 hashes the PIN and the device ID. The process flow moves to 360.
[00227] At operation 452, the server system 200 is configured to search a card ID from the database 204 that is associated with the PAN. If the card ID is found, then the process flow moves to operation 454. In an embodiment, the card ID may also be searched in the alternative database such as Redis®.
[00228] At operation 454, the server system 200 is configured to search for a device ID in the database 204 that may be associated with the card ID. In an embodiment, the device ID may also be stored in the alternative database. Further, the process flow moves to operation 464. However, if the card ID is not found in the database 204, then the process flow moves to operation 456.
[00229] At operation 456, the server system 200 verifies whether the card ID is found in the database 204 or not. If found, then the process flow moves to 454, else the process flow moves to 458.
[00230] At operation 458, the server system 200 is configured to get the card ID for the PAN from the AES module. The process flow moves to operation 460.
[00231] At operation 460, the server system 200 verifies whether the card ID is present in the AES module or not. If the card ID is found then the flow moves to operation 454, otherwise the process flow moves to operation 462.
[00232] At operation 462, the server system 200 is configured to transmit an empty response to the DS 304.
[00233] At operation 464, the server system 200 verifies whether the device ID is found in the database 204 or not. If the device ID is found then the process flow moves to operation 466, otherwise, it moves to operation 468 and then to operation 470.
[00234] At operation 466, the server system 200 is configured to create a combination string of the card ID, the threeDSRequestor ID, the consent type, and the device ID. The process flow then moves to operation 472.
[00235] At operation 468, the server system 200 is configured to get the device ID from the database 204.
[00236] At operation 470, the server system 200 verifies whether the device ID is present in the database 204 or not. If the device ID is found in the database 204, the process flow moves to operation 466, else the process flow moves to operation 462.
[00237] Upon creating the combination string, at operation 472, the server system 200 is configured to search consent in the database 204 for the combination string. Therefore, the process flow moves to operation 474.
[00238] At operation 474, the server system 200 searches in the database 204 for the consent and verifies whether the consent is present or not. If the consent is found then the process flow moves to operation 476, otherwise the process flow moves to operation 478.
[00239] At operation 476, the server system 200 is configured to save or update the consent in the database 204 for the combination string. In an embodiment, the consent may also be saved or updated in the alternative database such as Redis®.
[00240] At operation 478, the server system 200 is configured to search consent in the AES module for the card ID and a 3DSREQ ID (a request ID for a 3DS authentication service).
[00241] At operation 480, the server system 200 is configured to filter consent from combination fields.
[00242] At operation 482, the server system 200 is configured to identify whether the consent is present in the AES module or not. If yes, the process flow moves to operation 476, otherwise, the process flow moves to operation 462.
[00243] Upon performing the operation 476, the process flow moves to operation 484. At operation 484, the server system 200 is configured to hash the PIN. The process flow moves to operation 486.
[00244] At operation 486, the server system 200 is configured to get the card ID from the database 204.
[00245] At operation 488, the server system 200 compares the card IDs and checks if they match. If the card IDs match, then the process flow moves to operation 490, otherwise to operation 462.
[00246] At operation 490, the server system 200 is configured to prepare a success response.
[00247] At operation 492, the server system 200 is configured to transmit the success response to the merchant 108 and the cardholder 104 via the merchant application 126.
[00248] FIGS. 5A-5F, collectively, illustrate Graphical User Interfaces (GUIs) 500, 520, 540, 560, 580, and 590 that are implemented on an electronic device (e.g., the electronic device 106) for authenticating the cardholder (e.g., the cardholder 104) during the first-time checkout, in accordance with an embodiment of the present disclosure. Referring to FIGS. 5A-5F, it may be understood that GUI 500 includes an interface that is shown to the cardholder 104 on the electronic device 106 when the cardholder 104 initiates a checkout process while making a purchase on a merchant application 126 for the first time. For example, suppose the cardholder 104 has selected a few veggies and other items from a list of items displayed to the cardholder 104 on the merchant application 126 such as a grocery platform. Therefore, the GUI 500 shows a shopping cart interface displaying the items selected by the cardholder 104 such as the veggies, price, weight, shipping address, a payment method list expansion option, a discount coupon such as a promo code, a subtotal amount before and after applying the promo code, delivery charges, a complete order amount that the cardholder 104 is supposed to pay, and the like. In an embodiment, GUI 500 also shows a button ‘place order’ that can be clicked by the cardholder 104 to place the order.
[00249] Upon clicking on the payment method list expansion option, an expanded list of payment methods appears on an interface displayed on the electronic device via the merchant application 126 as shown in GUI 520. In an embodiment, one of the various payment methods that may be displayed in GUI 520 may include a frictionless payment option (in other words, payment without OTP). Herein, it may be noted that the frictionless payment option may be associated with a factor of receiving a PIN and a consent from the cardholder 104. The consent may include a transaction approval condition, for example, the condition may include to skip the OTP on orders of up to Rupees 2000. In some embodiments, other examples of the payment methods may include Unified Payments Interface (UPI), wallets, credit/debit/ATM card, net banking, or the like.
[00250] In an embodiment, upon selecting the frictionless payment option from the list of payment methods, GUI 540 may appear on the screen of the electronic device 106. GUI 540 displays a consent description to the cardholder 104. Herein, the server system 200 facilitates the merchant application 126 to display GUI 540 to the cardholder 104 to take a consent or an agreement of the cardholder 104 on a predefined condition prior to facilitating the cardholder 104 to proceed to make the payment using the payment card operating in the frictionless payment option. It may be noted that the consent description describes the predefined condition upon agreeing with which the cardholder 104 can proceed with the payment transaction and complete the payment without having to enter an OTP, thereby facilitating the cardholder 104 to experience the frictionless payment transaction.
[00251] In an embodiment, upon receiving a consent response indicating that the cardholder 104 has provided their consent for the consent description by accepting the predefined condition, the server system 200 facilitates the merchant application 126 to display GUI 560 as shown in FIG. 5D. GUI 560 displays a window requesting the cardholder 104 to create a PIN (a card-specific PIN). Upon clicking on a ‘submit’ button, GUI 580 may appear on the electronic device 106 of the cardholder 104. It may be noted that GUI 580 is requesting the cardholder 104 to enter an OTP for authentication of the cardholder 104 as this was a first-time checkout by the cardholder 104 on the merchant application 126.
[00252] Upon submitting the OTP by the cardholder 104, and if the received OTP matches with a prestored OTP, a transaction successful message may appear on the electronic device 106 of the cardholder 104 as shown in FIG. 5F in GUI 590.
[00253] FIGS. 6A-6D, collectively, illustrate GUIs 600, 620, 640, and 660 that are implemented on an electronic device (e.g., the electronic device 106) for authenticating the cardholder (e.g., the cardholder 104) during the subsequent checkout, in accordance with an embodiment of the present disclosure. Referring to FIG. 6A, it may be understood that GUI 600 includes an interface that is shown to the cardholder 104 on the electronic device 106 when the cardholder 104 initiates a checkout process while making a purchase on the merchant application 126 for a subsequent time. For example, after registering the payment card during a last purchase for the frictionless payment option, during a subsequent purchase the cardholder 104 can use the last-time created PIN to authenticate the identity of the cardholder 104. Therefore, GUI 600 shows details of items in the shopping cart and GUI 620 shows a condensed list of items added to the cart by the cardholder 104 along with a display of a payment method pre-selected as the frictionless payment option.
[00254] Upon clicking on the button ‘place order’, GUI 640 appears on the screen of the electronic device 106 of the cardholder 104 requesting the cardholder 104 to provide the PIN. The cardholder 104 may enter the PIN and submit, triggering GUI 660 as shown in FIG. 6D when the PIN matches with the PIN that is actually linked with the payment card that is registered for the frictionless payment option by the cardholder 104 of the payment card. It may be noted that GUI 660 displays a transaction successful message that may appear on the electronic device 106 of the cardholder 104 as shown in FIG. 6D in GUI 660.
[00255] FIGS. 7A-7C, collectively, illustrates GUIs 700, 720, and 740 that are implemented on an electronic device (e.g., the electronic device 106) for authenticating the cardholder (e.g., the cardholder 104) for a forgot PIN event, in accordance with an embodiment of the present disclosure. In an embodiment, GUI 640 also displayed a button of ‘forgot PIN’. Therefore, upon clicking on that button, GUI 700 may appear on the electronic device 106 of the cardholder 104 as shown in FIG. 7A. GUI 700 includes an interface requesting the cardholder to enter a new PIN as the cardholder 104 has forgotten the old PIN. Upon entering a new PIN, and clicking on the submit button on GUI 700, GUI 720 appears on the electronic device 106. GUI 720 shows the bank account details of the cardholder 104 and requests the cardholder 104 to enter an OTP for authentication of the identity of the cardholder 104 with the issuer. Upon receiving the OTP, GUI 740 may appear on the electronic device 106 showing a transaction successful message when the OTP matches with a prestored OTP.
[00256] FIGS. 8A and 8B, collectively, illustrate GUIs 800 and 820 that are implemented on an electronic device (e.g., the electronic device 106) for facilitating the cardholder (e.g., the cardholder 104) to revoke their consents associated with a process of authentication of the cardholder 104, in accordance with an embodiment of the present disclosure. In an embodiment, suppose during a subsequent transaction, suppose the cardholder 104 is willing to revoke the consent they provided earlier for one or more payment cards associated with the cardholder 104. One of the GUIs that may be available for facilitating the cardholder 104 to perform the revocation of the consent may include GUI 800. Thus, in an embodiment, GUI 800 includes an interface for managing cards displaying one or more payment cards with a ‘revoke consent’ option for each payment card. Further, GUI 820 appears on the electronic device 106, when the cardholder 104 selects the ‘revoke consent’ option of one of the one or more payment cards. GUI 820 displays an interface on the electronic device 106 showing a message of a consent being revoked successfully.
[00257] FIG. 9 illustrates a flow diagram depicting a method 900 for authentication of payment transactions, in accordance with an embodiment of the present disclosure. The method 900 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 900 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 900, and combinations of operations 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. The plurality of operations is depicted in the process flow of the method 900. The process flow starts at operation 902.
[00258] At 902, the method 900 includes receiving, by a server system (e.g., the server system 200), a payment initiation request from an electronic device (e.g., the electronic device 106) for a payment transaction being performed between a cardholder (e.g., the cardholder 104) and a merchant (e.g., the merchant 108). The payment initiation request may include a selected payment card and transaction-related information. Herein, the transaction-related information may include at least a Personal Account Number (PAN) of the selected payment card.
[00259] At 904, the method 900 includes accessing, by the server system 200, stored payment card-related data associated with the selected payment card from a database (e.g., the database 204) of the server system 200 based, at least in part, on the PAN of the selected payment card. The stored payment card-related data may include a card-specific Personal Identification Number (PIN) and consent information.
[00260] At 906, the method 900 includes generating and transmitting, by the server system 200, a cardholder authentication request to the electronic device 106. The cardholder authentication request indicates a request for the card-specific PIN associated with the selected payment card.
[00261] At 908, upon receiving a cardholder authentication response message including a PIN from the electronic device 106, the method 900 includes performing, by the server system 200, an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN.
[00262] At 910, upon successful authentication, the method 900 includes determining, by the server system 200, a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information.
[00263] At 912, upon determining that the payment transaction is valid, the method 900 includes generating and transmitting, by the server system 200, a payment authentication message to an issuer server (e.g., the issuer server 116) associated with the cardholder 104.
[00264] FIG. 10 illustrates a simplified block diagram of an acquirer server 1000, in accordance with an embodiment of the present disclosure. The acquirer server 1000 is an example of the acquirer server 120 of FIG. 1. The acquirer server 1000 is associated with an acquirer bank/acquirer, in which a merchant may have an account, that provides a payment card. The acquirer server 1000 includes a processing module 1002 operatively coupled to a storage module 1004 and a communication module 1006. The components of the acquirer server 1000 provided herein may not be exhaustive and the acquirer server 1000 may include more or fewer components than those depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 1000 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00265] The storage module 1004 is configured to store machine-executable instructions to be accessed by the processing module 1002. Additionally, the storage module 1004 stores information related to, the contact information of the merchant, bank account number, availability of funds in the account, payment card details, transaction details, and/or the like. Further, the storage module 1004 is configured to store payment transactions associated with the merchant.
[00266] In one embodiment, the acquirer server 1000 is configured to store profile data (e.g., an account balance, a credit line, details of the merchant (e.g., the merchant 108), account identification information, and a payment card number) in a transaction database 1008. The details of the merchant 108 may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, etc.
[00267] The processing module 1002 is configured to communicate with one or more remote devices such as a remote device 1010 using the communication module 1006 over a network such as the network 124 of FIG. 1. The examples of the remote device 1010 include the server system 102, the payment server 112, the issuer server 116, or other computing systems of the acquirer server 1000, and the like. The communication module 1006 is capable of facilitating such operative communication with the remote devices and cloud servers using Application Program Interface (API) calls. The communication module 1006 is configured to receive a payment transaction request performed by the cardholder 104 via the network 124. The processing module 1002 receives payment card information, a payment transaction amount, customer information, and merchant information from the remote device 1010 (i.e., the payment server 112). The acquirer server 1000 includes a user profile database 1012 and the transaction database 1008 for storing transaction data. The user profile database 1012 may include information about the cardholder 104. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources, pre-auth transactions, and other internal data to evaluate each transaction.
[00268] FIG. 11 illustrates a simplified block diagram of an issuer server 1100, in accordance with an embodiment of the present disclosure. The issuer server 1100 is an example of the issuer server 116 of FIG. 1. The issuer server 1100 is associated with an issuer bank/issuer, in which an account holder (e.g., the cardholder 104) may have an account, which provides a payment card. The issuer server 1100 includes a processing module 1102 operatively coupled to a storage module 1104 and a communication module 1106. The components of the issuer server 1100 provided herein may not be exhaustive and the issuer server 1100 may include more or fewer components than those depicted in FIG. 11. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 1100 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00269] The storage module 1104 is configured to store machine-executable instructions to be accessed by the processing module 1102. Additionally, the storage module 1104 stores information related to, the contact information of the cardholder (e.g., the cardholder 104), a bank account number, availability of funds in the account, payment card details, transaction details, payment account details, and/or the like. Further, the storage module 1104 is configured to store payment transactions associated with the cardholder 104.
[00270] In one embodiment, the issuer server 1100 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder 104, account identification information, payment card number, etc.) in a database. The details of the cardholder 104 may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder 104.
[00271] The processing module 1102 is configured to communicate with one or more remote devices such as a remote device 1108 using the communication module 1106 over a network such as the network 124 of FIG. 1. Examples of the remote device 1108 include the server system 200, the payment server 112, the acquirer server 120 or other computing systems of the issuer server 1100. The communication module 1106 is capable of facilitating such operative communication with the remote devices and cloud servers using Application Program Interface (API) calls. The communication module 1106 is configured to receive a payment transaction request performed by an account holder (e.g., the cardholder 104) via the network 124. The processing module 1102 receives payment card information, a payment transaction amount, customer information, and merchant information from the remote device 1108 (e.g., the payment server 112). The issuer server 1100 includes a transaction database 1110 for storing transaction data. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past x days to a particular account holder, transaction location information, external data sources, and other internal data to evaluate each transaction. The issuer server 1100 includes a user profile database 1112 storing user profiles associated with a plurality of account holders.
[00272] The user profile data may include an account balance, a credit line, details of the account holders, account identification information, payment card number, or the like. The details of the account holder (e.g., the cardholder 104) may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder 104.
[00273] FIG. 12 illustrates a simplified block diagram of the payment server 1200, in accordance with an embodiment of the present disclosure. The payment server 1200 is an example of the payment server 112 of FIG. 1. The payment server 1200 and the server system 200 may use the payment network 112 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
[00274] The payment server 1200 includes a processing module 1202 configured to extract programming instructions from a memory 1204 to provide various features of the present disclosure. The components of the payment server 1200 provided herein may not be exhaustive and the payment server 1200 may include more or fewer components than that depicted in FIG. 12. 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 1200 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00275] Via a communication module 1206, the processing module 1202 receives a request from a remote device 1208, such as the issuer server 116, the acquirer server 120, or the server system 102. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 1200 includes a database 1210. The database 1210 includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.
[00276] When the payment server 1200 receives a payment transaction request from the acquirer server 120 or a payment terminal (e.g., IoT device), the payment server 1200 may route the payment transaction request to the issuer server 116. The database 1210 stores transaction identifiers for identifying transaction details such as transaction amount, IoT device details, acquirer account information, transaction records, merchant account information, and the like.
[00277] In one example embodiment, the acquirer server 120 is configured to send an authorization request message to the payment server 1200. The authorization request message includes, but is not limited to, the payment transaction request.
[00278] The processing module 1202 further sends the payment transaction request to the issuer server 116 for facilitating the payment transactions from the remote device 1208. The processing module 1202 is further configured to notify the remote device 1208 of the transaction status in the form of an authorization response message via the communication module 1206. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 116. Alternatively, in one embodiment, the processing module 1202 is configured to send an authorization response message for declining the payment transaction request, via the communication module 1206, to the acquirer server 120. In one embodiment, the processing module 1202 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.
[00279] The disclosed method with reference to FIG. 9, or one or more operations of the server system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media), such as one or more optical media discs, volatile memory components (e.g., 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, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such a suitable communication means include, for example, the Internet, the World Wide Web, 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.
[00280] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00281] Particularly, the server system 200 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media. Non-transitory computer-readable media includes any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), Compact Disc Read-Only Memory (CD-ROM), compact disc recordabla (CD-R), compact disc rewritable (CD-R/W), Digital Versatile Disc (DVD), BLU-RAY® Disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash memory, random access memory (RAM), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00282] 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 from those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.
[00283] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A method, comprising:
receiving, by a server system, a payment initiation request from an electronic device for a payment transaction being performed between a cardholder and a merchant, the payment initiation request comprising a selected payment card and transaction-related information, the transaction-related information comprising at least a Personal Account Number (PAN) of the selected payment card;
accessing, by the server system, stored payment card-related data associated with the selected payment card from a database of the server system based, at least in part, on the PAN of the selected payment card, the stored payment card-related data comprising a card-specific Personal Identification Number (PIN) and consent information;
generating and transmitting, by the server system, a cardholder authentication request to the electronic device, the cardholder authentication request indicating a request for the card-specific PIN associated with the selected payment card;
upon receiving a cardholder authentication response message comprising a PIN from the electronic device, performing, by the server system, an authentication of a cardholder identity based, at least in part, on comparing the PIN and the card-specific PIN;
upon successful authentication, determining, by the server system, a validity of the payment transaction based, at least in part, on the consent information and the transaction-related information; and
upon determining that the payment transaction is valid, generating and transmitting, by the server system, a payment authentication message to an issuer server associated with the cardholder.

2. The method as claimed in claim 1, further comprising:
transmitting, by the server system, a transaction successful notification to at least one of the merchant and the cardholder when the payment transaction is completed between the issuer server and an acquirer server associated with the merchant.

3. The method as claimed in claim 1, wherein receiving the payment initiation request comprising:
facilitating, by the server system, a display of a first Graphical User Interface (GUI) on the electronic device, the first GUI configured to prompt the cardholder to select the payment card from one or more payment cards for performing the payment transaction, the payment card enabled with a frictionless payment option; and
receiving, by the server system, a selection of the payment card and the transaction-related information associated with the selected payment card from the electronic device via a merchant plug-in interface (MPI) associated with the electronic device.

4. The method as claimed in claim 1, further comprising:
upon unsuccessful authentication of the cardholder identity, generating and transmitting, by the server system, a payment failure message to the electronic device.

5. The method as claimed in claim 1, further comprising:
upon determining that the payment transaction is invalid, generating and transmitting, by the server system, a payment failure message to the electronic device.

6. The method as claimed in claim 1, further comprising:
receiving, by the server system, a forgot PIN message from the cardholder via the electronic device in response to the cardholder authentication request;
facilitating, by the server system, a display of a second GUI on the electronic device, the second GUI configured to prompt the cardholder to set a new card-specific PIN for the authentication of the cardholder identity;
upon receiving the new card-specific PIN, transmitting, by the server system, the cardholder authentication request to the issuer server for authenticating the cardholder to use the new card-specific PIN for subsequent payment transactions, the cardholder authentication request comprising the selected payment card and the transaction-related information; and
upon successful authentication by the issuer server, storing, by the server system, the new card-specific PIN based, at least in part, on linking a payment card ID of the payment card having the PAN with the consent information.

7. The method as claimed in claim 1, further comprising:
facilitating, by the server system, a display of a third GUI on the electronic device, the third GUI configured to prompt the cardholder to select a consent revocation option;
receiving, by the server system, a selection of the consent revocation option associated with the payment card from the electronic device via a merchant plugin interface (MPI) associated with the electronic device; and
upon receiving the corresponding selection, updating, by the server system, the stored consent-related information with a revocation of the consent by the cardholder for the consent description.

8. The method as claimed in claim 1, further comprising:
facilitating, by the server system, a display of a fourth GUI on the electronic device, the fourth GUI configured to prompt the cardholder to select a frictionless payment option from one or more payment options to perform a new payment transaction when using a new payment card on the electronic device that is not registered for the frictionless payment option;
receiving, by the server system, a selection of the new payment card and new transaction-related information associated with the new payment card from the electronic device via a merchant plug-in interface (MPI) associated with the electronic device, the new transaction-related information comprising at least a PAN of the new payment card;
accessing, by the server system, new payment card-related data associated with the new payment card from the database;
performing, by the server system, a verification of the PAN of the new payment card to be linked with a card-specific PIN associated with the consent information based, at least in part, on the new payment card-related data;
upon successful verification, facilitating, by the server system, a display of a fifth GUI on the electronic device, the fifth GUI configured to prompt the cardholder to provide a consent response for a consent description being displayed to the cardholder via the fifth GUI based, at least in part, on the consent information;
upon receiving a valid consent response, storing, by the server system, the received consent response for the corresponding consent description in the database as an updated consent information based, at least in part, on linking a payment card ID of the new payment card having the PAN with the received consent response; and
upon successful storage of the received consent response, registering, by the server system, the new payment card on the electronic device for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data and the received consent response.

9. The method as claimed in claim 8, further comprising:
upon unsuccessful verification, facilitating, by the server system, a display of the fifth GUI on the electronic device, the fifth GUI configured to prompt the cardholder to provide a consent response for a consent description being displayed to the cardholder via the fifth GUI;
upon receiving a valid consent response, facilitating, by the server system, a display of a sixth GUI on the electronic device, the sixth GUI configured to prompt the cardholder to provide a new card-specific PIN for the authentication of the cardholder identity;
upon receiving the new card-specific PIN, transmitting, by the server system, a cardholder authentication request to the issuer server for authenticating the cardholder to use the new card-specific PIN for subsequent payment transactions, the cardholder authentication request comprising the selected payment card and the transaction-related information;
upon successful authentication, storing, by the server system, the received consent response for the corresponding consent description as new consent information and the new card-specific PIN based, at least in part, on linking the new consent information and the new card-specific PIN with the PAN of the new payment card; and
upon successful storage of the received consent response and the new card-specific PIN, registering, by the server system, the new payment card on the electronic device for the frictionless payment option to be used for subsequent payment transactions based, at least in part, on the new payment card-related data, the received consent response, and the new card-specific PIN.

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