Claims:CLAIMS
We claim:

1. A computer-implemented method for performing additional factor of authentication process for standing instructions, the computer-implemented method comprising:
storing, by a server system, a dataset associated with a standing instruction (SI) corresponding to a payment account of a user in a database, the dataset comprising information of a recurring payment time for scheduling recurring payment transactions from the payment account of the user to a merchant;
transmitting, by the server system, an alert notification to a user device of the user based, at least in part, on the information of the recurring payment time, the alert notification transmitted to the user device prior to a threshold time period from the recurring payment time;
detecting, by the server system, activity status of the user on the user device for determining whether the user is available for performing additional factor of authentication (AFA) process for an upcoming recurring payment transaction or not;
in response to determining that the user is available for performing the AFA process for the upcoming recurring payment transaction, initiating, by the server system, the AFA process to determine user consent of the user for executing the upcoming recurring payment transaction for the merchant; and
facilitating, by the server system, the upcoming recurring payment transaction for the merchant based, at least in part, on the user consent.

2. The computer-implemented method as claimed in claim 1, wherein performing the AFA process comprises:
sending, by the server system, an authentication request message to the user device; and
receiving, by the server system, an authentication response message from the user device, the authentication response message comprising user input in response to the authentication request message.

3. The computer-implemented method as claimed in claim 2, further comprising:
determining, by the server system, whether the user consent indicates an approval for executing the upcoming recurring payment transaction or not based, at least in part, on the authentication response message.

4. The computer-implemented method as claimed in claim 3, further comprising:
in response to determination that the user consent does not indicate the approval, sending, by the server system, an instruction to hold the upcoming recurring payment transaction to an issuer server of the user; and
storing, by the server system, transaction data of the upcoming recurring payment transaction into an outstanding transaction database.

5. The computer-implemented method as claimed in claim 1, wherein the dataset associated with the SI comprises merchant information, recurring transaction amount, SI transaction frequency, next SI transaction time, contact number of the user, and electronic mail address of the user.

6. The computer-implemented method as claimed in claim 1, wherein the activity status of the user on the user device is detected based upon receiving a read receipt from the user device in response to the alert notification.

7. The computer-implemented method as claimed in claim 1, wherein, in response to detecting the activity status of the user on the user device, the computer-implemented method further comprises:
requesting, by the server system, the user to perform advanced AFA process for the upcoming recurring payment transaction;
storing, by the server system, advanced AFA approval information corresponding to the user and the merchant in a database upon completing the advanced AFA process; and
transmitting, by the server system, a notification to the issuer server to authorize the upcoming recurring payment transaction without user intervention at the recurring payment time.

8. The computer-implemented method as claimed in claim 1, further comprising:
interacting, by the server system, with an operating system of the user device to fetch an activity history of the user, the activity history being fetched to determine the activity status of the user on the user device within a particular time window.

9. A server system for performing additional factor of authentication process for standing instructions (SI), the server system comprising:
a communication interface;
a memory comprising executable instructions; and
a processor communicatively coupled to the communication interface and configured to execute the instructions to cause the server system to at least:
store a dataset associated with the standing instructions (SI) corresponding to a payment account of a user in a database, the dataset comprising information of a recurring payment time to schedule recurring payment transactions from the payment account of the user to a merchant;
transmit an alert notification to a user device of the user based, at least in part, on the information of the recurring payment time, the alert notification transmitted to the user device prior to a threshold time period from the recurring payment time;
detect activity status of the user on the user device to determine whether the user is available to perform additional factor of authentication (AFA) process for an upcoming recurring payment transaction or not;
in response to a determination that the user is available to perform the AFA process for the upcoming recurring payment transaction, initiate the AFA process to determine user consent of the user to execute the upcoming recurring payment transaction for the merchant; and
facilitate the recurring payment transaction for the merchant based, at least in part, on the user consent.

10. The server system as claimed in claim 9, wherein the dataset associated with the SI comprises merchant information, recurring transaction amount, SI transaction frequency, next SI transaction time, contact number of the user, and electronic mail address of the user.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PROVIDING ADDITIONAL FACTOR OF AUTHENTICATION FOR STANDING INSTRUCTIONS

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

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

3. PREAMBLE TO THE DESCRIPTION

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

4. DESCRIPTION
(See next page)

 
METHODS AND SYSTEMS FOR PROVIDING ADDITIONAL FACTOR OF AUTHENTICATION FOR STANDING INSTRUCTIONS

TECHNICAL FIELD
[0001] The present disclosure generally relates to an authentication system and, more particularly to, electronic methods and systems for providing additional factor authentication (AFA) process for recurring payment transactions.

BACKGROUND
[0002] Customers use payment accounts to purchase goods or access services offered by a merchant. The goods or services offered by the merchant may be purchased at once as a single purchase or alternatively, by various recurring purchases over a time period (e.g., annually, monthly, quarterly, and so on). For example, recurring purchases may include loan payments, cable payments, subscriptions, utilities, systematic investment plan (SIP) purchases, and so on. For recurring payments, customers authorize a merchant to automate payment deduction from the payment account of the customer. One method of automation of payment deduction from the payment account of the customer based on pre-agreed terms (e.g., such as frequency of payment, amount of payment (fixed or variable), and so on) is with facilitation of a standing instruction (SI). In general, SI is an order/consent that a customer provides to a bank (in which the payment account of the customer is issued, managed, or hosted) to deduct the recurring payments based on the pre-agreed terms. Automated recurring payments benefit both customers as well as merchants as there is no possibility of missing out of any payment by the customer for services/goods offered by the merchant.
[0003] However, there is a possibility that the recurring payments may lead to financial losses for the customer. For example, the customer may not pay attention to the recurring payments (specifically payment amount) being deducted from the payment account of the customer. Suppose a merchant may increase amount of a recurring payment without consent from the customer and only notifies the customer through a monthly statement. Additionally, recurring payments (with increased payment amount) may be made to the merchant account with the customer being completely unaware of such an increase as the recurring payments (with initial payment amount) have been set by the customer himself/herself. This further leads to a financial loss to the customer and the customer may be completely unaware about such financial loss.
[0004] In some markets, regulators may require additional factor of authentication (AFA) on recurring transactions. For example, the Reserve Bank of India (RBI), India’s central bank requires that all the SI transactions should be prior-authenticated before scheduled transaction dates of the SI transactions. Hence, banks will be required to inform customers in advance about recurring payment due and the recurring payment transaction would be carried following the nod from the customer.
[0005] Thus, there exists a technological need to overcome the above-stated limitations.

SUMMARY
[0006] Various embodiments of the present disclosure provide systems and methods for additional factor of authentication for standing instructions.
[0007] In an embodiment, a computer-implemented method for performing additional factor of authentication (AFA) process for standing instructions (SI) is disclosed. The method includes storing, by a server system, a dataset associated with the SI corresponding to a payment account of a user in a database. The dataset includes information of a recurring payment time for scheduling recurring payment transactions from the payment account of the user to a merchant. The method includes transmitting, by the server system, an alert notification to a user device of the user based, at least in part, on the information of the recurring payment time. The alert notification is transmitted to the user device prior to a threshold time period from the recurring payment time. The method includes detecting, by the server system, activity status of the user on the user device for determining whether the user is available for performing the AFA process for an upcoming recurring payment transaction or not. The method includes initiating, by the server system, the AFA process to determine user consent of the user for executing the upcoming recurring payment transaction for the merchant in response to determining that the user is available for performing the AFA process for the upcoming recurring payment transaction. The method further includes facilitating, by the server system, the recurring payment transaction for the merchant based, at least in part, on the user consent.
[0008] In another embodiment, a server system is disclosed. The server system includes a communication interface, a memory comprising executable instructions and a processor communicably coupled to the communication interface. The processor is configured to execute the executable instructions to cause the server system to at least store a dataset associated with the SI corresponding to a payment account of a user in a database. The dataset includes information of a recurring payment time to schedule recurring payment transactions from the payment account of the user to a merchant. The server system is caused to transmit an alert notification to a user device of the user based, at least in part, on the information of the recurring payment time. The alert notification is transmitted to the user device prior to a threshold time period from the recurring payment time. The server system is caused to detect activity status of the user on the user device to determine whether the user is available to perform the AFA process for an upcoming recurring payment transaction or not. The server system is caused to initiate the AFA process to determine user consent of the user to execute the upcoming recurring payment transaction for the merchant in response to determining that the user is available to perform the AFA process for the upcoming recurring payment transaction. The server system is caused to facilitate the recurring payment transaction for the merchant based, at least in part, on the user consent.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0011] FIG. 1 illustrates an example representation of an environment related to at least some embodiments of the present disclosure;
[0012] FIG. 2 represents a sequence flow diagram of a process flow for performing registration process for standing instruction (SI) transactions, in accordance with an embodiment of the present disclosure;
[0013] FIG. 3 represents a sequence flow diagram of a process flow for performing AFA process based on activity status of the user, in accordance with an embodiment of the present disclosure;
[0014] FIG. 4 represents a sequence flow diagram of a process flow for performing additional factor of authentication (AFA) process for recurring payment transaction based on activity status of the user on the user device, in accordance with an embodiment of the present disclosure;
[0015] FIGS. 5A and 5B, collectively, represent a sequence flow diagram of a process flow for performing additional factor of authentication (AFA) process for recurring payment transaction based on activity status of the user on the user device, in accordance with another embodiment of the present disclosure;
[0016] FIGS. 6A and 6B, collectively, represent a sequence flow diagram of a process flow for performing advanced or prior additional factor of authentication process for recurring payment transactions, in accordance with an embodiment of the present disclosure;
[0017] FIG. 7 represents a flow chart for processing recurring payment transactions with advanced AFA process, in accordance with an embodiment of the present disclosure;
[0018] FIG. 8 illustrates a flow diagram depicting a computer-implemented method for performing AFA process for standing instructions, in accordance with an embodiment of the present disclosure;
[0019] FIG. 9 is a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure;
[0020] FIG. 10 is a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0021] FIG. 11 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure;
[0022] FIG. 12 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure; and
[0023] FIG. 13 shows a simplified block diagram of a device capable of implementing the various embodiments of the present disclosure.
[0024] 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
[0025] 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.
[0026] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0027] 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.
[0028] The term "issuer", used throughout the description, refers to a financial institution normally called as an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server system called as "issuer server" throughout the description.
[0029] Further, the term "acquirer" represents an entity that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in question. Typically, the acquirer has an agreement with merchants, wherein the acquirer receives authorization requests for purchase transactions from the merchants and routes the authorization requests to the issuers of the payment cards being used for the purchase transactions. The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer bank” will be used interchangeably herein. Further, one or more server systems associated with the acquirer are referred to as "acquirer server" to carry out its functions.
[0030] The term “payment card”, used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0031] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by Mastercard®, etc.
[0032] The term "standing instruction", used herein refers to a banking instruction capable of facilitating an automatic repetitive payment of a fixed/variable amount to a loan, bill, credit card charge, subscription, or any other payment on a certain frequency (monthly, weekly, etc.).
[0033] The term "additional factor of authentication (AFA)", used throughout the description, herein refers to an authentication process followed before due date of occurrence of recurring payment transactions from customer’s account according to regulatory related mandates, where initial user consent for SI transactions is already registered by the customer.
OVERVIEW
[0034] Various example embodiments of the present disclosure provide systems and methods for additional factor of authentication (AFA) of recurring payment transactions based on standing instructions (SI). More specifically, techniques disclosed herein enable users to authenticate each instance of recurring payments which are already registered as SI transactions at an issuer server.
[0035] As noted above, in existing authentication systems, a cardholder needs to store the payment card details at a merchant to generate a standing instruction (SI) for recurring payments with the merchant and the cardholder may also need to provide his/her consent for registering the SI. Hence, one-time authentication process is followed in which the cardholder may be asked to pay a notional amount, for instance, 10 cents to the merchant account. The one-time authentication process can be completed in accordance with a typical payment transaction flow involving entities such as the merchant interface, acquirer, issuer, and the payment network. After the one-time authentication process is complete and the SI mandate request is successfully registered, a payment amount (i.e., recurring payment) gets debited from the payment account of the user and gets credited in the merchant account automatically after a period of time (e.g., monthly, quarterly, half-yearly, annually) agreed upon during the registration of the SI mandate request. This deduction of the payment amount from the account of the user is also termed as SI debit or mandate debit. However, after the registration of the SI request, the payment amount automatically gets debited from the payment account of the user after the period of time. In an example scenario, the user may forget about an annual subscription of an over-the-top (OTT) media platform that was earlier registered by him but is not required anymore. As per the SI transaction already registered at the issuer server, the payment account of the user may get debited on a periodic basis without even the user utilizing the services. In another example scenario, a cable provider may increase monthly cable rental of a user without informing or notifying the user before increasing the charges. As per the SI transaction already registered at the issuer server, the user account may get debited every month without this being in knowledge of the user.
[0036] Further, in some markets, regulators may mandate additional consumer authentication on certain types of transactions, such as recurring transactions. Such regulation is directed at reducing online fraud, but often at the expense of customer and merchant satisfaction. For example, forcing customers to provide password or PIN information or respond to a text message for completing the recurring transactions within that market increases friction in online purchasing environments, leading to increased rates of abandonment due to the customers’ frustrations.
[0037] To overcome such problems or limitations, the present disclosure describes a SI authenticator (i.e., server system) that is configured to perform real-time approval of SI transaction associated with a user to facilitate recurring payment transactions.
[0038] At least one of the technical problems addressed by the present disclosure includes: (i) high network load on issuers for completing AFA process for recurring payment transactions which results in network delays and reduced bandwidth, and (ii) high decline rates for recurring payment transactions due to real-time user authentication during transactions.
[0039] In one embodiment, the server system is configured to store a dataset associated with the standing instruction (SI) corresponding to a payment account of the user in a database. The dataset includes information of a recurring payment time for scheduling recurring payment transactions from the payment account of the user to the merchant. The server system stores the dataset associated with the recurring payment transaction upon approval of the SI from the issuer server. In general, the database is an organized collection of data (structured information) stored electronically in a computer system.
[0040] The server system is configured to transmit an alert notification to a user device of the user based, at least in part, on the information of the recurring payment time for informing the user about upcoming recurring payment transaction prior to a threshold time period (e.g., 2 hours, 5 hours, 1 day, 5 days, and so on) from the recurring payment time. In one example, the user device includes at least one of smart phone, mobile device, laptop, desktop, smartwatch, personal digital assistant (PDA), and the like. The alert notification is transmitted to the user device in form of at least one of text message, web-based notification, or application-based notification. In an embodiment, the alert notification may be received as a notification, text message, web-based notification, application-based notification, and the like.
[0041] In one embodiment, for transmitting the alert notification on the user device, the server system is configured to interact with an operating system of the user device to fetch an activity history of the user. The server system fetches the activity history to determine a time period during which the user is highly active on the user device. The dataset associated with the SI includes merchant information, recurring transaction amount, service provider name, SI transaction frequency, next SI transaction date, contact number of the user, and electronic mail address of the user.
[0042] The server system is configured to detect activity status of the user on the user device for determining whether the user is available for performing additional factor of authentication (AFA) process for the upcoming recurring payment transaction or not. The server system receives a read receipt from the user device if the user reads the alert notification. In general, read receipt is a notification delivered to sender when a recipient opens or reads message of sender. More specifically, the server system detects activeness of the user (i.e., activity status) to determine that the user is available to perform the AFA process for the upcoming recurring payment transaction.
[0043] In response to determining that the user is available for performing the AFA process for the upcoming recurring payment transaction, the server system is configured to initiate the AFA process to determine user consent of the user for executing the upcoming recurring payment transaction for the merchant. In one example, the AFA process may be performed with facilitation of a one-time password (OTP), facial identifier of the user, or fingerprint of the user. The server system is configured to send an authentication request message to the user device to initiate the AFA process. In an embodiment, the authentication request message may be a one-time password (OTP). In another embodiment, the authentication request message may be a request to capture real-time image or video of the user. In yet another embodiment, the authentication request message may be a request to capture fingerprint of the user.
[0044] In response to the authentication request message, the server system is configured to receive an authentication response message from the user device. In one embodiment, the authentication response message is received from the user through the user device over a network. The authentication response message includes user input in response to the authentication request message. In one example scenario, the authentication response message includes a challenge response (e.g., one-time password) entered by the user on the user device. The OTP is same as the OTP received at the user device as the authentication request message.
[0045] The server system is configured to determine whether the user consent indicates approval for executing the upcoming recurring payment transaction or not based, at least in part, on the authentication response message. In response to determining that the user consent indicates approval, the server system is configured to facilitate the recurring payment transaction for the merchant based, at least in part, on the user consent. In response to determining that the user consent does not indicate the approval, the server system is configured to send an instruction to hold the recurring payment transaction to the issuer server of the user. The server system is further configured to store transaction data of the recurring payment transaction into an outstanding transaction database.
[0046] In one embodiment, the server system is configured to transmit a notification to the user device for enabling the user to perform an advance AFA process. In addition, upon approval of the advance AFA process from the user, the server system is configured to debit payment amount based, at least in part, on the SI from payment account of the user. The server system is further configured to enable the issuer server to hold the payment amount in a bucket associated with the issuer server.
[0047] In one embodiment, the server system is configured to recommend one or more time slots available for performing the AFA process to the user on a user interface rendered in the user device of the user. The one or more time slots are time slots in which the user may perform the AFA process. The user may select the preferred time slot out of the one or more time slots in which the user wants to perform the AFA process. The server system receives a response including preferred time slot out of the one or more time slots from the user. The preferred time slot is time slot in which the user wants to perform the AFA process. The server system is further configured to register the preferred time slot of the one or more time slots with the issuer server for performing the AFA process.
[0048] In one embodiment, the server system is configured to enable the user through the user interface installed in the user device of the user for setting up a ringtone or vibration pattern for the alert notification. The user may set up a separate ringtone or vibration pattern for the alert notification so that the user may not miss the alert notification. In one embodiment, the server system is configured to enable the user through the user interface installed in the user device for setting up a time period validity (e.g., 1 hour, 2 hours, 5 hours) for responding to the authentication request message received from the server system.
[0049] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure notifies the user about the recurring payment due based on the upcoming SI transaction in advance. In addition, the present disclosure allows debit of the payment amount from the payment account of the user after additional factor of authentication or approval from the user. Thus, the server system performs additional factor of authentication for taking approval or consent from the user before performing recurring payments based on SI. Based on the description herein the technical improvement in the authentication system as described herein is a computer based solution to a technical deficiency or problem that is itself rooted in computer technology (e.g., the problem itself derives from the use of computer technology). More specifically, fraud is significant problem for transactions conducted over an electronic payment network, especially for card-not-present transactions. Therefore, there is a need of strong consumer authentication system for reducing frauds in recurring payments such that network traffic at the payment network is reduced and approval rates for recurring payment transactions is increased.
[0050] Additionally, a further technical effect is achieved by performing at least one of the following steps: (i) perform advanced AFA process prior to the recurring payment time so that the recurring payment transaction request is not declined during transaction, (ii) determine activity status of the user to perform AFA process so that number of iterations for performing the AFA process can be reduced, and (iii) decline the recurring payment transaction if the AFA process is not completed for the user and the merchant before the recurring payment time, thereby reducing fraudulent transactions.
[0051] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 13.
[0052] FIG. 1 illustrates an example representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, additional authentication of recurring payments based on SI transactions. The environment 100 generally includes a user device 104 associated with a user 102, a merchant 106, an acquirer server 108, an issuer server 110, a payment network 112 including a payment server 114, a database 116, each coupled to, and in communication with a network 118. The network 118 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.
[0053] Various entities in the environment 100 may connect to the network 118 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 118 may include multiple different networks, such as a private network made accessible by the server system 122 and a public network (e.g., the Internet etc.) through which the server system 122, may communicate.
[0054] The environment 100 is depicted to include a payment server 114, a payment aggregator 120, a server system 122, and an outstanding transaction database 124. The basic information, such as details of the user 102, details of the merchant 106, details of the SI transaction, and the like may be stored in a database, such as the database 116. In one example, the database 116 is associated with the payment server 114. In addition, the outstanding transaction database 124 is associated with the server system 122 or the issuer server 110. In one embodiment, the outstanding transaction database 124 includes information of SI transactions for which the user 102 has not performed an authentication process.
[0055] In the illustrative embodiment, the user 102 may be any individual, representative of a corporate entity, non-profit organization, or any other person. More specifically, the user 102 may be any individual buyer and/or customer, or any other person that is presenting a payment card during a payment transaction to a merchant representative or other seller or via an online interface associated with the merchant 106. The user 102 may have a payment instrument (e.g., a payment card) issued by an issuing bank (associated with the issuer server 110) and may be provided with the payment card with financial or other account information encoded onto the payment card.
[0056] The user 102 may operate a user device 104 to conduct a payment transaction through a mobile application installed on the user device 104. The user device 104 may be a smartphone, a tablet, a laptop, a computer system or any computing device. In an embodiment, the user device 104 may include a portable device such as laptop, smartwatch, PDA (personal digital assistant), smartphone, and the like. In another example embodiment, the user device 104 may include a fixed device such as desktop, workstation, and the like.
[0057] In one embodiment, the user 102 is established card-on-file relationship with a merchant 106. The user 102 provides payment card information to the merchant 106, thereby allowing the merchant 106 to periodically charge the user 102 for a product or a service. For example, the user 102 enters the payment card information into a web browser and submits the payment card information to the merchant. Thereafter, the merchant stores the payment card information in a database and/or server. The payment card information used by the merchant may include the cardholder's name as it appears on the payment card, a billing address, an account number or card number of the payment card, and/or an expiration date of the payment card. In other words, the user 102 authorizes the merchant 106 to store the card details of the user 102 and to bill the user 102 for recurring transactions using the stored card details.
[0058] The user 102 may have a payment account issued by an issuing bank (associated with the issuer server 110) and may be provided the payment card with financial or other account information encoded onto the payment card such that the user 102 may use the payment card to initiate and complete a transaction using a bank account at the issuer server 110.
[0059] The issuer server 110 is a computing server that is associated with the issuer bank. The issuer bank is a financial institution that manages accounts of multiple cardholders. Account details of the accounts established with the issuer bank are stored in cardholder profiles of the cardholders in a memory of the issuer server 110 or on a cloud server associated with the issuer server 110. The issuer server 110 approves or denies an authorization request, and then routes, via the payment network 112, an authorization response back to the acquirer server 108. The acquirer server 108 sends the approval to the merchant 106.
[0060] In one embodiment, the acquirer server 108 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein in the description.In a non-limiting example, the process of payment transactions using the payment card is facilitated by a combination of the payment server 114, the issuer server 110 and the acquirer server 108. In one embodiment, a payment transaction request is sent to the payment server 114 associated with the payment network 112 by the merchant 106 (e.g., payment terminal associated with the merchant 106) using the network 118.
[0061] The payment network 112 may be used by the payment cards issuing authorities as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transaction data between financial institutions that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0062] The payment aggregator 120 is a collection of one or more payment gateways. In general, payment gateway is a merchant service or technology provided by a service provider to authorize or accept card purchases (e.g., credit card or debit card) or direct payments for e-businesses, online retailers, and the like. In one embodiment, the payment aggregator 120 facilitates collection of payment from card purchases or direct payments for e-businesses, online retailers, and the like. In one example, the merchant 106 who does not have a direct merchant account with bank may use the payment aggregator 120 to process payments.
[0063] In one example, the user 102 purchases goods or services from the merchant 106 using the payment card by opting recurring payment transaction type to pay the merchant 106. Examples of the merchant 106 may include any retail shop, restaurant, supermarket or establishment, government and/or private agencies, or any such place equipped with payment terminals, such as point-of-sale (POS) devices where customers visit for performing financial transaction in exchange for any goods and/or services or any transaction that requires financial transaction between the user 102 and the merchant 106.
[0064] In this example scenario, the user 102 associated with the user device 104 (e.g., a mobile phone) may access the merchant site and/or application, or a payment facilitator page associated with the merchant 106 on the user device 104 for registering standing instructions (SI) to perform the recurring payment with the merchant 106. The user 102 may enter corresponding details related to the recurring payment such as, but not limited to, payment card details presented on the payment card, information related to the recurring payments (such as number of debits which determine time period of recurring payments, and recurring payment frequency) for registering the SI mandate to perform the recurring payment to the merchant 106 etc. More particularly, the user 102 may have to go through this one-time registration process with the merchant 106 for performing the recurring payment.
[0065] Further, the user 102 is requested to provide a consent and/or permission to the merchant 106 for performing the recurring payments through a standing instruction (SI) transaction. Upon successful registration of the SI request, the recurring payment transaction request may be generated by the acquirer server 108. In general, the SI may be an approval provided by the user 102 to the merchant 106 to perform recurring payment on a periodic basis as mentioned while registering for the recurring payment by the user 102. In an embodiment, a consent registration request (i.e., SI request) is generated and first recurring payment (i.e., SI transaction) is also performed simultaneously. However, the recurring payment transaction can also be performed at a later point of time. In one embodiment, the consent registration request may be generated by the issuer server 110.
[0066] In one embodiment, the server system 122 is configured to perform one or more of the operations described herein. In one embodiment, the server system 122 is an SI transaction authenticator. After successful registration of the SI, the server system 122 is configured to perform additional factor of authentication (AFA) for SI before debiting recurring payment amount from the payment account of the user 102. In one embodiment, the issuer server 110 provides an approval of the recurring payment transaction. The server system 122 stores a dataset associated with the SI corresponding to the payment account of the user 102 in the database 116. The dataset includes information of a recurring payment time for scheduling recurring payment transactions from the payment account of the user 102 to the merchant 106. The recurring payment time information includes information such as date, time, etc. on which the recurring payment transactions must be performed based on the scheduled standing instructions registered with the issuer server 110. In one embodiment, the dataset associated with the SI includes merchant information, service provider name, recurring transaction amount, SI transaction frequency, next SI transaction date, contact number of the user 102, and electronic mail address of the user 102.
[0067] Based on the recurring payment time information (i.e., days left to perform recurring payment transaction), the server system 122 transmits an alert notification to the user device 104 of the user 102. The alert notification is transmitted to the user device 104 prior to a threshold time period from the recurring payment time to inform the user 102 about upcoming SI transaction (i.e., the recurring payment transaction) after the threshold time period. In one example, the threshold time period is time period left for performing recurring payment transaction based on the recurring payment time information. The alert notification is transmitted by the server system 122 for detecting activity status (i.e., user activeness) of the user 102 on the user device 104 in real-time.
[0068] In one embodiment, the server system 122 transmits the alert notification to the user device 104 in the form of web-based notification, application-based notification, text message notification, and the like. In an example, the server system 122 transmits the alert notification on a merchant-specific application installed in the user device 104 of the user 102. In another example, the server system 122 transmits the alert notification on a messaging application installed in the user device 104 of the user 102. In yet another example, the server system 122 transmits the alert notification on a banking application associated with issuing bank (e.g., the issuer server 110) installed in the user device 104 of the user 102.
[0069] When the user 102 reads the alert notification, a read receipt is received by the server system 122 from the user device 104 to notify the server system 122 that the alert notification has been read by the user 102. The server system 122 detects the activity status of the user 102 on the user device 104 to determine whether the user 102 is available to perform the additional factor of authentication (AFA) process for the upcoming recurring payment transaction or not. In one embodiment, if the read receipt is received by the server system 122, the server system 122 is configured to transmit a notification to inform the merchant 106 to initiate the upcoming recurring payment transaction.
[0070] In one embodiment, the server system 122 is configured to perform the AFA process before debiting the payment amount from the payment account of the user 102 based on the SI. In response to determining that the user 102 is available for performing the AFA process for the upcoming recurring payment transaction (i.e., SI transaction), the server system 122 is configured to initiate the AFA process to determine user consent of the user 102 for executing the upcoming recurring payment transaction for the merchant 106. The server system 122 sends an authentication request message to the user device 104 for initiating the AFA process. In one example, the AFA process is performed with facilitation of one-time password (OTP), facial identifier of the user 102, or fingerprint of the user 102. In one example, the authentication request message may include one-time password (OTP), request for capturing facial image or video of the user 102 in real-time, request for capturing fingerprint of the user 102 in real-time, and the like. In one embodiment, the authentication request message may be received on the merchant-specific application, banking application, messaging application, text message link, or any other application of the like.
[0071] In response to the authentication request message, the user 102 provides an authentication response message through the user device 104. The authentication response message is response corresponding to the authentication request message. In one example, the authentication response message includes the OTP, real-time facial image or video of the user 102 captured through a camera installed in the user device 104, fingerprint of the user 102 captured in real-time through a fingerprint sensor embedded inside the user device 104, and the like. The server system 122 receives the authentication response message from the user 102 through the user device 104 over the network 118 or the payment network 112. The authentication response message includes user input in response to the authentication request message.
[0072] In one embodiment, the server system 122 is configured to interact with an operating system of the user device 104. The server system 122 interacts with the operating system to fetch activity history of the user 102 to determine a time period during which the user 102 is highly active on the user device 104. The server system 122 determines the time period and further transmits the alert notification in the time period in which the user 102 is highly active so that the user 102 may not miss the alert notification. In one embodiment, in response to determining that the user 102 is available for performing the AFA process based on the activity status, the server system 122 may transmit a request to the merchant 106 to initiate the recurring payment transaction.
[0073] In one embodiment, the server system 122 is configured to perform an advance additional factor of authentication (i.e., advanced AFA) process to authenticate the issuer server 110 to deduct the payment amount from the payment account of the user 102 and transfer the payment amount to the merchant account based on the recurring payment transaction. In one embodiment, upon detecting activity status of the user 102 on the user device 104 in real-time, the server system 122 transmits a notification to the user device 104 for allowing the user 102 to perform the advanced AFA process. The user 102 may approve the server system 122 to perform the advanced AFA process. The server system 122 performs the advance AFA process to debit the payment amount based, at least in part, on the upcoming recurring payment transaction from the payment account of the user 102 and credit/store the payment amount in a bucket associated with the issuer server 110. On the day of recurring payment transaction, the payment amount is debited from the bucket of the issuer server 110 and gets credited in the merchant account without any additional authentication as advanced AFA is already performed by the server system 122.
[0074] In one embodiment, the server system 122 is configured to recommend one or more time slots to the user 102 for performing the AFA process or the advanced AFA process on a user interface installed in the user device 104 of the user 102. In one embodiment, the server system 122 may recommend the one or more time slots in merchant-specific application, banking application, messaging application, text message containing a link to a web page displaying option to book the one or more slots on the user device 104, and the like. The user 102 may tap/click/press on the user interface to book preferred time slot out of the one or more available time slots for performing the AFA process or the advance AFA process. The preferred time slot is time slot out of the one or more slots in which the user 102 wants to perform the AFA process or the advance AFA process. In one embodiment, upon receiving the preferred time slot from the user 102, the server system 122 is configured to register the preferred time slot with the issuer server 110.
[0075] The server system 122 is configured to determine whether the user consent indicates approval for executing the upcoming recurring payment transaction or not based, at least in part, on the authentication response message. Upon successful verification of the AFA process, the server system 122 facilitates the issuer server 110 to process the recurring payment transaction for the merchant 106 based, at least in part, on the user content. Upon unsuccessful verification of the AFA process or determining that the user consent does not indicate the approval, the server system 122 sends an instruction to the issuer server 110 of the user 102 to hold the recurring payment transaction. The server system 122 is further configured to store transaction data of the recurring payment transaction (i.e., failed transaction) in the outstanding transaction database 124. In addition, the server system 122 is configured to transmit the failed transaction message or notification on the user device 104 for informing the user 102 about the failed recurring payment transaction.
[0076] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks, and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0077] FIG. 2 represents a sequence flow diagram 200 of a process flow for performing registration process for standing instruction (SI) transactions, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 200, references may be made to elements described in FIG. 1.
[0078] To avail services/goods offered by the merchant 106, the user 102 needs to perform financial transaction or give payment to the merchant 106. The user 102 has an option to provide the payment to the merchant 106 as a single purchase or alternatively, as recurring purchases after a periodic interval of time (e.g., daily, weekly, monthly, quarterly, annually, and the like). Thus, the user 102 has an option to opt-in for standing instruction (SI) facility to facilitate scheduled periodic payments for third-party payments, funds transfer, systematic investment plans (SIPs) installments, and the like. To enroll the user 102 with SI authenticator (i.e., the server system 122), the user 102 initiates a consent registration process for SI transactions.
[0079] At 202, the user 102 sends a consent registration request for setting SI for recurring payments to the merchant 106. The user 102 may send the consent registration request to the merchant 106 through the user device 104 of the user 102. In one embodiment, the user 102 may visit merchant-specific application or website to register for the SI to debit recurring payments from the payment account of the user 102. During initiation of the consent registration process for the SI transactions, the user 102 provides cardholder data that will ultimately be used to authenticate the user 102 such as device details and browser details. The user 102 may upload information such as bank account details or the payment card (e.g., credit card, debit card etc.) details, shipping address, contact number, and recurring payment amount and time for scheduling the recurring payment transaction, on merchant-specific application or website. In addition, the consent registration process may capture a plurality of data elements associated the user 102.
[0080] At 204, the merchant 106 transmits the consent registration request and merchant information to the acquirer server 108. The merchant 106 captures cardholder data and device data of the user device 104. The cardholder data may include account number or payment card details, shipping address, and the like. The payment card details may include payment card number, card verification value (CVV), expiry date, etc. In one embodiment, the merchant 106 may collect information such as number of recurring payments to be performed which further determines the time period of recurring payments (i.e., start date and end date of recurring payment), recurring payment frequency (i.e., occurrence of each subsequent recurring payment after the first recurring payment), and the like.
[0081] At 206, the acquirer server 108 transmits the consent registration request to the issuer server 110. More specifically, the acquirer server 108 may be configured to send the consent registration request to the payment network 112 for identifying the issuer server 110 associated with the payment account of the user 102 based on the payment card details. Upon identifying the issuer server 110, the payment server 114 transmits the consent registration request to the issuer server 110 for performing an authentication process with the user 102 to register the recurring payment transaction request.
[0082] At 208, the issuer server 110 transmits an authentication request message (e.g., one-time password (OTP)) to the user device 104 of the user 102. Upon receiving the consent registration request, the issuer server 110 utilizes a database for retrieving information associated with the user 102 and identifies the payment account associated with the user 102. Thereafter, the issuer server 110 transmits the authentication request message to the user device 104 of the user 102 over a messaging medium, such as Short Message Service (SMS) medium or a chat medium to the user 102.
[0083] At 210, the user 102 enters a challenge response provided in the authentication request message on a user interface rendered on the user device 104. The user device 104 sends the authentication response message (i.e., entered challenge response) to the issuer server 110 for authentication. The challenge response may be entered using a touch screen, voice command, or through any another means that can be interpreted and sent to the issuer server 110.
[0084] At 212, the issuer server 110 verifies the authentication response message entered by the user 102 to authenticate the user 102 and the payment account of the user 102. Upon successful verification of the authentication response message, the issuer server 110 performs approval of the user 102 for performing the recurring payments based on SI from the payment account of the user 102 to the merchant account. In other words, the user 102 is registered with the merchant 106 to utilize the recurring payment based on SI upon successful verification of the OTP entered by the user 102. In one embodiment, if the challenge response entered by the user 102 is incorrect or the user 102 may fail to enter the challenge response in time, the issuer server 110 may send a new authentication request message to the user device 104 and request the user 102 to enter new challenge response for the new authentication request message.
[0085] At 214, the issuer server 110 transmits a response flag to the acquirer server 108 and the server system 122 upon successful verification of the user 102. In one embodiment, upon successful verification of the user 102, the issuer server 110 may notify the acquirer server 108 about successful registration of SI for transferring the recurring payment from the payment account of the user 102 to the merchant 106.
[0086] At 216, the server system 122 stores the dataset corresponding to the SI associated with the recurring payment transactions. The dataset includes service provider details (e.g., details of the merchant 106), recurring payment transaction amount, recurring payment transaction frequency, next recurring payment transaction date, contact information of the user 102, and the like.
[0087] At 218, the server system 122 provides a notification to the merchant 106 about the approval and/or consent of the user 102 for performing the recurring payment on the periodic basis. As such, the notification provided to the merchant 106 confirms the completion of registration process of the user 102 with the merchant 106 for performing the recurring payment. In this scenario, the merchant 106 is associated with the payment card details, information related to the recurring payment and the approval of the user 102 for performing the recurring payment by the merchant 106 with the user 102 on the periodic basis.
[0088] At 220, the merchant 106 provides a notification to the user device 104 about successful registration of the SI for the recurring payment on the periodic basis. As such, the notification provided to the user device 104 confirms that the SI process has been completed and recurring payments have been enabled from the payment account of the user 102 to the merchant 106 on the periodic basis.
[0089] FIG. 3 represents a sequence flow diagram 300 of a process flow for performing AFA process based on activity status of the user 102, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 300, references may be made to elements described in FIG. 1.
[0090] After successful registration of the SI for recurring payments, SI transaction is to be performed for deducting recurring payments from the payment account of the user 102. The SI transaction must be performed on the periodic basis (e.g., daily, weekly, monthly, quarterly, annually etc.). Before every SI transaction, the server system 122 is configured to detect activity status of the user 102 on the user device 104. The activity status of the user 102 is detected to determine if the user 102 is actively using the user device 104. In one example, the activity status may represent that the user 102 is actively using the user device 104, the user 102 is offline or away, the user device 104 is on silent, and the like. To detect activity status of the user 102, the server system 122 transmits the alert notification on the user device 104. In one embodiment, the server system 122 may detect a time period in the entire day when the user 102 must be actively using the user device 104 and further transmits the alert message on the user device 104 during this time period. To detect the time period, the server system 122 may interact with the operating system installed in the user device 104 to analyze activity history pattern data of the user 102 on the user device 104. In one example, the server system 122 may use system or API calls to interact with the operating system of the user device 104.
[0091] At 302, the server system 122 transmits the alert notification to the user device 104 for informing upcoming recurring payment transaction (i.e., SI transaction) to the user 102. The alert notification is transmitted a threshold time period prior to recurring payment time (i.e., recurring payment information of the SI transaction) scheduled for recurring payment transaction between the merchant 106 and the user 102. The recurring payment information includes date and time information of upcoming recurring payment transaction. In an example, the server system 122 may transmit the alert notification on the user device 104 two days prior to date of SI transaction. In a similar manner, the server system 122 may transmit the alert message on the user device 104 any number of days prior to date of SI transaction.
[0092] In one embodiment, the alert notification may contain a read receipt request flag in a message header that has been set by the server system 122 to request a read receipt. At some time either concurrent to or subsequent to the generation of an acknowledgment, the user device 104 may generate a read receipt message and transmit to the server system 122. In this manner, the server system 122 may receive confirmation that the sent alert notification was read (or at least displayed) by the intended user 102.
[0093] At 304, the server system 122 receives the read receipt from the user device 104 if the user 102 confirms receipt and reading of the alert notification. In general, read receipt is a confirmation that is sent to sender of a message that recipient has read the message. The user device 104 may optionally display a message to the user 102 on the display of the user device 104 requesting the user 102 to explicitly confirm the receipt and reading of the alert notification. In one embodiment, when the server system 122 does not receive the read receipt
[0094] At 306, the server system 122 may transmit a request to the merchant 106 to initiate a recurring payment transaction request for the SI after receiving the read receipt from the user device 104.
[0095] At 308, the merchant 106 may transmit a request to the acquirer server 108 to initiate the recurring payment transaction for the user 102 for the period of time (e.g., for particular month, week, year etc.). In one embodiment, the merchant 106 may run a scheduler or trigger an application programming interface (API) to initiate the recurring payment for debiting payment account from the payment account of the user 102.
[0096] More specifically, the merchant 106 may transmit the recurring payment transaction request to the payment aggregator 120 of FIG. 1 (not shown in FIG. 3) which further transmits the request including recurring payment transaction details to the acquirer server 108. In one example, recurring payment transaction details may include recurring payment transaction amount, recurring payment transaction frequency, contact details of the user 102, and the like.
[0097] Upon receiving the recurring payment transaction request (i.e., SI transaction request) from the merchant 106, at 310, the acquirer server 108 transmits the request to the server system 122. The server system 122 is further configured to perform the steps of additional factor of authentication (AFA) process which is explained in detail hereinafter with reference to FIG. 4.
[0098] FIG. 4 represents a sequence flow diagram 400 of a process flow for performing additional factor of authentication (AFA) process for recurring payment transaction based on activity status of the user 102 on the user device 104, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 400 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 400, references may be made to elements described in FIG. 1. The sequence flow diagram 400 explains the process flow when the server system 122 successfully detects user activity of the user 102 on the user device 104 according to the FIG. 3.
[0099] At 402, the merchant 106 may send a recurring payment transaction request to the acquirer server 108 to initiate the SI transaction for the user 102 upon receiving the notification regarding successful user activity detection (based on activity status that the user 102 is actively using the user device 104) on the user device 104. In one embodiment, the merchant 106 may run a scheduler or trigger an application programming interface (API) to initiate the recurring payment transaction request for debiting recurring payment transaction amount from the payment account of the user 102.
[00100] More specifically, the merchant 106 may send the recurring payment transaction request to the payment aggregator 120 of FIG. 1 (not shown in FIG. 4) which further transmits the request including SI transaction details to the acquirer server 108. In one example, SI transaction details may include SI transaction amount, SI transaction frequency, contact details of the user 102, and the like.
[00101] At 404, the acquirer server 108 receives the recurring payment transaction request from the acquirer server 108. The acquirer server 108 transmits the recurring payment transaction request to the server system 122 to initiate the AFA process before debiting the recurring payment amount from the payment account of the user 102.
[00102] In one embodiment, the server system 122 also receives an instruction set from the acquirer server 108 to perform the AFA process. In one embodiment, the server system 122 may also receive the recurring payment transaction request in the instruction set. In one embodiment, the AFA process may be performed by the issuer server 110.
[00103] At 406, the server system 122 sends an authentication request message to the user device 104. In other words, the server system 122 initiates the AFA process to determine user consent of the user for executing upcoming recurring payment transaction for the merchant 106. In one embodiment, the authentication request message may include OTP, request to receive fingerprint of the user 102, request to capture face of the user 102, request to receive voice command of the user 102, or any other similar request to verify deduction of the recurring payment amount from the payment account of the user 102. In one embodiment, the user 102 is notified about the authentication request message on the user device 104 through a unique ringtone or a vibration pattern. In some embodiments, the user 102 may have an option to set up the unique ringtone or vibration pattern through a user interface installed in the user device 104.
[00104] At 408, the user device 104 transmits the authentication response message to the server system 122. In response to the authentication request message, the user 102 enters a challenge response provided in the authentication request message as the authentication response message on the user interface rendered on the user device 104. For example, the authentication response message may include the image of the user 102 captured through a camera installed in the user device 104, OTP received at the user device 104, fingerprint of the user 102 captured through a fingerprint sensor embedded in the user device 104, and the like. In one example, the OTP may be entered using a touch screen, voice command, or any other medium of the like. The authentication response message is sent as a response to the authentication request message by the user 102 for authorizing the server system 122 to proceed with the recurring payment transaction from the payment account of the user 102. The server system 122 determines whether the user consent indicates an approval executing the upcoming recurring payment transaction or not based, at least in part, on the authentication response message.
[00105] Upon determining the user consent indicating the approval, at 410, the server system 122 may send the user consent of the user 102 to facilitate the upcoming recurring payment transaction from the payment account of the user to the merchant 106.
[00106] In one embodiment, upon unsuccessful verification of the authentication response message, the server system 122 may re-send the authentication request message to the user device 104 and request the user 102 to again respond with the authentication response message.
[00107] At 412, the issuer server 110 authorizes approval of recurring payment transaction after successful AFA process for deducting the recurring payment amount based on SI from the payment account of the user 102 to the merchant account. In other words, the payment amount is debited from the payment account of the user 102 and credited to the merchant account upon successful completion of the AFA process. In one embodiment, the issuer server 110 receives a flag indicating successful validation of user consent for approving the upcoming recurring payment transaction.
[00108] At 414, the issuer server 110 transmits recurring payment transaction status (e.g., transaction successful, transaction failed etc.) to the acquirer server 108.
[00109] At 416, the acquirer server 108 receives the recurring payment transaction status from the issuer server 110. In addition, the acquirer server 108 transmits the recurring payment transaction status to the merchant 106. In addition, the merchant 106 may transmit a notification to the user device 104 to notify the user 102 about the recurring payment transaction status (i.e., whether the recurring payment transaction has been successfully completed or failed).
[00110] FIGS. 5A and 5B, collectively, represent a sequence flow diagram 500 of a process flow for performing additional factor of authentication (AFA) for recurring payment transaction based on activity status of the user 102 on the user device 104, in accordance with another embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 500, references may be made to elements described in FIG. 1.
[00111] The sequence flow diagram 500 explains the process flow when the server system 122 successfully detects user activity of the user 102 on the user device 104 according to the FIG. 3.
[00112] At 502, the merchant 106 may send a request to the payment aggregator 120 to initiate the recurring payment transaction for the user 102 for the period of time (e.g., for particular month, week, year etc.). In one embodiment, the merchant 106 may run a scheduler or trigger an application programming interface (API) to initiate the recurring payment transaction for debiting recurring payment amount from the payment account of the user 102.
[00113] At 504, the payment aggregator 120 receives the recurring payment transaction request from the merchant 106. In addition, the payment aggregator 120 transmits the recurring payment transaction request including recurring payment transaction details to the acquirer server 108. In one example, recurring payment transaction details may include recurring payment transaction amount, recurring payment transaction frequency, contact details of the user 102, and the like.
[00114] At 506, the acquirer server 108 receives the recurring payment transaction request from the payment aggregator 120. The acquirer server 108 transmits the recurring payment transaction request to the server system 122 to initiate the AFA process before debiting the payment amount from the payment account of the user 102.
[00115] In one embodiment, the server system 122 may also receive an instruction set from the acquirer server 108 to perform the AFA process. In one embodiment, the server system 122 may also receive the recurring payment transaction request in the instruction set. In one embodiment, the AFA process may be performed by the issuer server 110.
[00116] At 508, the server system 122 sends an authentication request message to the user device 104. In one embodiment, the authentication request message may include OTP, request to receive fingerprint of the user 102, request to capture face of the user 102, request to receive voice command of the user 102, or any other similar request to receive consent from the user 102 before deduction of the recurring transaction payment amount from the payment account of the user 102. In one embodiment, the user 102 is notified about the authentication request message on the user device 104 through a unique ringtone or a vibration pattern. In some embodiments, the user 102 may have an option to set up the unique ringtone or vibration pattern through a user interface installed in the user device 104.
[00117] At 510, the user 102 either fails to provide the authentication response message or provides incorrect authentication response message. In an example, any other person might be using the user device 104 of the user 102 and hence, the facial identification or the fingerprint scanning authentication of the user 102 fails. In another example, the user 102 may mistakenly enter incorrect challenge response as the authentication response message for the authentication request message in the user device 104. In one embodiment, the challenge response may be entered using a touch screen, voice command, or any other medium of the like. In yet another embodiment, the time period validity to respond to the authentication request message may end till the time the user 102 enters the challenge response in the user device 104. The authentication process may fail due to any of the above stated reasons. Thereafter, the server system 122 receives the authorization response message including the user consent indicating denial of AFA process.
[00118] At 512, the issuer server 110 is notified through the server system 122 that the AFA process has failed. In one embodiment, the server system 122 is notified through the user device 104 about the failure of the AFA process. In an example, the server system 122 is notified about the failed AFA process after time period validity of the challenge response expires and the challenge response is not entered in the user device 104 by the user 102. In another example, the server system 122 is notified about the failed AFA process if the fingerprint of the user 102 or the image of the user 102 (for facial identification) is not received by the server system 122 in the time period validity (e.g., 15 minutes, 30 minutes etc.).
[00119] At 514, the server system 122 or the issuer server 110 stores transaction data of the failed recurring payment transaction in the outstanding transaction database 124. In one embodiment, information about the failed transaction may be stored in the outstanding transaction database 124 in the form of tables.
[00120] At 516, the server system 122 transmits a notification to the user device 104 to inform the user 102 about the failed recurring payment transaction. In addition, the server system 122 may propose a time duration (e.g., 2 days, 3 days, 5 days, and the like) to the user 102 to again request for the AFA process. In one embodiment, the server system 122 may transmit a hyperlink along with the notification to the user device 104. The user 102 may tap/click/press on the hyperlink to access a webpage on which details about the failed recurring payment transaction and an option to again request for the AFA process is proposed to the user 102. The user 102 may follow the instructions provided in the hyperlink to again request for the AFA process.
[00121] At 518, after following the instructions provided in the hyperlink and again requesting for the AFA process, the AFA process is re-initiated for the user 102. In one embodiment, the AFA process may be re-initiated by the server system 122 or the issuer server 110. The server system 122 again sends an authentication request message to the user device 104. In one example, the authentication request message may include OTP, request to receive fingerprint of the user 102, request to capture face of the user 102, request to receive voice command of the user 102, or any other similar request to receive consent from the user 102 before deduction of the recurring transaction payment amount from the payment account of the user 102.
[00122] At 520, the user device 104 receives the authentication request message from the server system 122.
[00123] In response to the authentication request message, at 522, the user 102 provides the correct authentication response message to the server system 122 to complete the authentication process. In one example, the user 102 may provide correct challenge response as the authentication response message for the authentication request message on the user interface rendered in the user device 104 of the user 102.
[00124] Upon successful completion of the AFA process, at 524, the issuer server 110 retrieves the transaction data of earlier failed recurring payment transaction from the outstanding transaction database 124 and performs the authorization process based on the transaction data.
[00125] In one embodiment, upon unsuccessful completion of the AFA process again, information about the failed recurring payment transaction may again be stored in the outstanding transaction database 124.
[00126] At 526, the issuer server 110 transmits recurring payment transaction status (e.g., transaction successful) to the acquirer server 108.
[00127] At 528, the acquirer server 108 receives the recurring payment transaction status from the issuer server 110. In addition, the acquirer server 108 transmits recurring payment transaction status to the payment aggregator 120.
[00128] At 530, the payment aggregator 120 receives the recurring payment transaction status from the acquirer server 108. In addition, the payment aggregator 120 transmits recurring payment transaction status to the merchant 106. In addition, the merchant 106 may transmit a notification to the user device 104 to notify the user 102 about the recurring payment transaction status.
[00129] FIGS. 6A and 6B, collectively, represent a sequence flow diagram 600 of a process flow for performing advanced or prior additional factor of authentication process for recurring payment transactions, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 600, references may be made to elements described in FIG. 1.
[00130] At 602, the user 102 may launch an application on the user device 104. In an embodiment, the application may be a merchant-specific application associated with the merchant 106. In another embodiment, the user 102 may launch website of the merchant 106 on a web browser installed in the user device 104 of the user 102. In one embodiment, the merchant-specific application is associated with the server system 122.
[00131] In an embodiment, the server system 122 may transmit a notification (e.g., the alert notification) on the merchant-specific application installed in the user device 104 to perform advance AFA process of the user 102 for providing consent to the issuer bank to debit the payment amount from the payment account of the user 102 on the day of recurring payment transaction. It should be noted that in some embodiments, the server system 122 may transmit one or more notifications on one or more merchant-specific applications installed in the user device 104 without deviating the scope of the disclosure.
[00132] The alert notification may include recurring payment time information of recurring payment transaction that might be upcoming in a few days. In an example, recurring payment transaction for merchant-specific application A1 may be upcoming today. Thus, the notification (e.g., “Please complete the payment to continue with the subscription”) notifies the user 102 that the subscription for service/goods offered by the particular merchant is going to expire today. In another example, recurring payment transaction for merchant-specific application A2 may be upcoming in next 2 days. Thus, the notification (e.g., “Please complete the payment within two days to continue with the subscription”) notifies the user 102 that the subscription for service/goods offered by the particular merchant is going to expire in the next 2 days.
[00133] At 604, the user 102 may click/press/tap on the alert notification to access webpage on a web browser or the merchant-specific application installed in the user device 104 for initiating or performing advances AFA process. The advanced AFA process may allow the user 102 to perform the AFA process in advance so that the recurring payment transaction may occur on the day of SI even if the user 102 is not available on SI day to perform the AFA process.
[00134] At 606, the server system 122 transmits the alert notification on the merchant-specific web page or application installed in the user device 104 for detecting user activeness (or activity status of the user 102) before initiating the advance AFA process. In one embodiment, the server system 122 may transmit the alert notification on the merchant-specific application based, at least in part, on the recurring payment time information of the recurring payment transaction. The recurring payment time information includes date and time information of upcoming recurring payment transaction for the merchant 106. In an example, the server system 122 may transmit the alert notification on the user device 104 2 days prior to date of recurring payment transaction for the merchant-specific application A2. In a similar manner, the server system 122 may transmit the alert notification on the merchant-specific application any number of days prior to date of recurring payment transaction based on the recurring payment time information.
[00135] In one embodiment, the alert notification may contain a read receipt request flag in a message header that has been set by the server system 122 to request a read receipt. At some time either concurrent to or subsequent to the generation of an acknowledgment, the user device 104 may generate a read receipt message and transmit to the server system 122. In this manner, the server system 122 may receive confirmation that the sent alert notification was read (or at least displayed) by the intended user 102.
[00136] At 608, the server system 122 receives the read receipt from the merchant-specific application if the user 102 confirms receipt and reading of the alert notification. In general, read receipt is a confirmation that is sent to sender of a message that recipient has read the message. If the read receipt is not received from the merchant-specific application, the server system 122 may not proceed with the advance AFA process.
[00137] At 610, the server system 122 may transmit a notification on the merchant-specific application installed in the user device 104 to ask whether the user 102 wants to perform the advanced AFA process or not.
[00138] At 612, the user 102 may provide a response in the form of yes or no to the notification. In one example, if the user 102 wants to perform the advanced AFA process, the user 102 may tap/click/press on the yes button displayed on a user interface of the merchant-specific application installed in the user device 104. If the user 102 does not want to perform the advanced AFA process, the user 102 may tap/click/press on the no button displayed on the user interface of the merchant-specific application installed in the user device 104. If the user 102 responds to the notification with a yes, the merchant-specific application may transmit a request to the server system 122 to initiate the advance AFA process.
[00139] When the user 102 wants to perform the advanced AFA process, at 614, the server system 122 sends the authentication request message to the merchant-specific application installed in the user device 104. In one example, the authentication request message may include OTP, request to receive fingerprint of the user 102, request to capture face of the user 102, request to record voice command of the user 102, or any other similar request to receive consent from the user 102 before deduction of the recurring payment transaction amount from the payment account of the user 102. In one embodiment, the user 102 is notified about the authentication request message on the merchant-specific application through a unique ringtone or a vibration pattern. In some embodiments, the user 102 may have an option to set up the unique ringtone or vibration pattern through the user interface of the merchant-specific application installed in the user device 104.
[00140] At 616, the merchant-specific application receives the authentication request message from the server system 122. In response to the authentication request message, the user 102 provides the authentication response message to the server system 122 through the merchant-specific application to complete the advanced AFA process. In one example, the user 102 may enter challenge response as the authentication response message to the authentication request message through the merchant-specific application. The authentication response message is submitted as a response to the authentication request message by the user 102 for authorizing the server system 122 to facilitate the issuer server 110 to debit recurring payment transaction amount from the payment account of the user 102.
[00141] Upon successful verification of the authentication response message, at 618, the server system 122 may be configured to request the issuer server 110 associated with the payment account of the user 102 to deduct the payment amount from the payment account of the user 102 based on the SI associated with the merchant 106. In other words, the server system 122 requests or facilitates the issuer server 110 to perform the recurring payment transaction.
[00142] In one embodiment, upon unsuccessful verification of the authentication response message, the server system 122 may re-send the authentication request message to the user device 104 and request the user 102 to again respond with the authentication response message.
[00143] At 620, the issuer server 110 performs authorization of the recurring payment transaction after successful advanced AFA from the user 102 for deducting the recurring payment amount based on SI from the payment account of the user 102. In addition, the payment amount is debited from the payment account of the user 102 and stored in a bucket by the issuer server 110 upon successful completion of the advance AFA process. In other words, the server system 122 transmits a notification to the issuer server 110 to authorize the upcoming recurring payment transaction at the recurring payment time such that real-time user intervention for AFA is not required.
[00144] At 622, on the day of recurring payment transaction, the server system 122 facilitates the issuer server 110 to debit the payment amount from the bucket associated with the issuer server 110 and credits the payment amount in the merchant account. Hence, there is no need to perform AFA on the day of recurring payment transaction as the advanced AFA is already done by the server system 122.
[00145] At 624, the issuer server 110 sends a payment authorization response message upon authorizing the recurring payment transaction.
[00146] FIG. 7 represents a flow chart 700 for processing recurring payment transactions with advanced AFA process, in accordance with an embodiment of the present disclosure. The sequence of operations of the flow chart 700 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the flow chart 700, references may be made to elements described in FIG. 1.
[00147] At 702, the server system 122 receives a recurring payment transaction request from the merchant 106 according to the stored SI. In one embodiment, the merchant 106 may run a scheduler or trigger an application programming interface (API) to initiate the SI debit transaction for debiting payment amount from the payment account of the user 102.
[00148] At 704, the server system 122 checks whether the merchant-specific application or the user device 104 is mapped with the advanced AFA approval by querying the user device identifier in data entries storing advanced AFA approval information data in the database.
[00149] When the merchant-specific application or the user device 104 is mapped with the advanced AFA approval, it means that the recurring payment amount is already stored or blocked in a separate payment bucket associated with the issuer server 110. At 706, the server system 122 requests the issuer server 110 to release the recurring payment amount stored in the bucket of the issuer server 110.
[00150] When the merchant-specific application or the user device 104 is not mapped with the advanced AFA approval, at 708, the server system 122 performs AFA process in real-time. As described earlier, the server system 122 transmits an authentication request message to the user device 104 to perform the AFA process in real-time. In one embodiment, the authentication request message may include OTP, request to receive fingerprint of the user 102, request to capture face of the user 102, request to receive voice command of the user 102, or any other similar request to verify deduction of the SI transaction payment amount from the payment account of the user 102.
[00151] At 710, the server system 122 determines whether the user consent received in the authentication response message indicates an approval for executing the recurring payment transaction of the upcoming SI or not.
[00152] At 712, when the user consent indicates the approval for executing the recurring payment transaction, the server system 122 sends a request to the issuer server 110 to facilitate the recurring payment transaction to transfer the recurring payment amount from the payment account of the user 104 to the merchant 106.
[00153] At 714, when the user consent does not indicate the approval for executing the recurring payment transaction, the server system 122 stores transaction data of the recurring payment transaction in the outstanding transaction database 124 and delays authorization of the recurring payment transaction. In addition, the server system 122 sends a notification to the user device 104 to inform the user 102 about the failed SI debit transaction. In one embodiment, along with the notification, the server system 122 may send a link to the user device 104 to allow the user 102 to again perform the authentication process to release the recurring payment based on the recurring payment transaction request. The user 102 may click/press/tap on the link which further redirects the user 102 on a web page that provides instructions to the user 102 on the user device 104 to again initiate the authentication process. If the recurring payment transaction is released in a specified time, successful transaction status will be relayed back to merchant 106.
[00154] FIG. 8 illustrates a flow diagram depicting a computer-implemented method 800 for performing additional factor of authentication process for standing instructions, in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, the server system 122. Operations of the method 800, and combinations of operation in the method 800, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 800 are described herein may be performed by an application interface that is hosted and managed with help of the server system 122. The method 800 starts at operation 802.
[00155] At operation 802, the method 800 includes storing a dataset associated with a standing instruction (SI) corresponding to a payment account of a user 102 in a database. The dataset includes at least information of a recurring payment time for scheduling recurring payment transactions from the payment account of the user 102 to a merchant 106.
[00156] At operation 804, the method 800 includes transmitting an alert notification to a user device 104 of the user 102 based, at least in part, on the information of the recurring payment time. The alert notification is transmitted to the user device 104 prior to a threshold time period from the recurring payment time. The alert notification is transmitted for determining activity status of the user 102 on the user device 104. The activity status of the user 102 on the user device 104 is detected based upon receiving a read receipt from the user device in response to the alert notification.
[00157] At operation 806, the method 800 includes detecting activity status of the user on the user device for determining whether the user 102 is available for performing additional factor of authentication (AFA) process for an upcoming recurring payment transaction or not.
[00158] At operation 808, the method 800 includes initiating the AFA process to determine user consent of the user 102 for executing the upcoming recurring payment transaction for the merchant 106 in response to determining that the user 102 is available for performing the AFA process for the upcoming recurring payment transaction.
[00159] At operation 810, the method 800 includes facilitating the recurring payment transaction for the merchant based, at least in part, on the user consent.
[00160] The sequence of operations of the method 800 need not to be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[00161] FIG. 9 is a simplified block diagram of an issuer server 900, in accordance with an embodiment of the present disclosure. The issuer server 900 is an example of the issuer server 110 of FIG. 1. The issuer server 900 is associated with an issuer bank/issuer, in which a cardholder may have an account, which provides a payment card. The issuer server 900 includes a processing module 905 operatively coupled to a storage module 910 and a communication module 915. The components of the issuer server 900 provided herein may not be exhaustive and the issuer server 900 may include more or fewer components than those depicted in FIG. 9. 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 900 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00162] The storage module 910 is configured to store machine executable instructions to be accessed by the processing module 905. Additionally, the storage module 910 stores information related to, contact information of the cardholder, bank account number, availability of funds in the account, payment card details, transaction details and/or the like. Further, the storage module 910 is configured to store payment transactions.
[00163] In one embodiment, the issuer server 900 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder, account identification information, payment card number) in a database (e.g., the database 116). The details of the cardholder may include, but 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 etc.
[00164] The processing module 905 is configured to communicate with one or more remote devices such as a remote device 920 using the communication module 915 over a network such as the network 118 of FIG. 1. The examples of the remote device 920 include the server system 122, the payment server 114, the database 116 or other computing systems of the issuer server 900 and the network 118 and the like. The communication module 915 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 915 is configured to receive a payment transaction request performed by the cardholder via the network 118. The processing module 905 receives a payment card information, a payment transaction amount, a customer information and merchant information from the remote device 920 (i.e., the payment server 114). The issuer server 900 includes a transaction database 930 for storing transaction data. The transaction data may include, but 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 machine, 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 and other internal data to evaluate each transaction. The issuer server 900 includes a user profile database 925 storing user profile associated with the plurality of cardholders.
[00165] The user profile data may include an account balance, a credit line, and details of the cardholder, account identification information, payment card number, or the like. The details of the cardholder may include, but 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.
[00166] FIG. 10 is 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 108 of FIG. 1. The acquirer server 1000 is associated with an acquirer bank/acquirer, in which a cardholder may have an account, which provides a payment card. The acquirer server 1000 includes a processing module 1005 operatively coupled to a storage module 1010 and a communication module 1015. 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.
[00167] The storage module 1010 is configured to store machine executable instructions to be accessed by the processing module 1005. Additionally, the storage module 1010 stores information related to, contact information of the cardholder, bank account number, availability of funds in the account, payment card details, transaction details and/or the like. Further, the storage module 1010 is configured to store payment transactions.
[00168] In one embodiment, the acquirer server 1000 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder, account identification information, payment card number) in the database 116. The details of the cardholder may include, but 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 etc.
[00169] The processing module 1005 is configured to communicate with one or more remote devices such as a remote device 1020 using the communication module 1015 over a network such as the network 118 of FIG. 1. The examples of the remote device 1020 include the server system 122, the payment server 114, the database 116 or other computing systems of the acquirer server 1000 and the network 118 and the like. The communication module 1015 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 1015 is configured to receive a payment transaction request performed by the cardholder via the network 118. The processing module 1005 receives a payment card information, a payment transaction amount, a customer information and merchant information from the remote device 1020 (i.e., the payment server 114). The acquirer server 1000 includes a transaction database 1030 for storing transaction data. The transaction data may include, but 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 machine, 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 and other internal data to evaluate each transaction.
[00170] The user profile data may include an account balance, a credit line, and details of the cardholder, account identification information, payment card number, or the like. The details of the cardholder may include, but 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.
[00171] FIG. 11 is a simplified block diagram of a payment server 1100, in accordance with an embodiment of the present disclosure. The payment server 1100 is an example of the payment server 114 of FIG. 1. The payment server 1100, and the server system 122 of FIG. 1 may use the payment network 112 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network.
[00172] The payment server 1100 includes a processing system 1105 configured to extract programming instructions from a memory 1110 to provide various features of the present disclosure. The components of the payment server 1100 provided herein may not be exhaustive and that the payment server 1100 may include more or fewer components than that of 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 payment server 1100 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00173] Via a communication interface 1115, the processing system 1105 receives request from a remote device 1120, such as the acquirer server 108, a merchant device associated with the merchant 106, or a customer device (e.g., the user device 104) hosting a payment gateway application. 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 1100 includes a database 1125. The database 1125 also includes transaction processing data such as, Issuer ID, POS ID, country code, acquirer ID, merchant identification number (MID), among others.
[00174] When the payment server 1100 receives a payment transaction request from the acquirer server 108 or a payment terminal (e.g., POS machine, ATM terminal, etc.), the payment server 1100 may route the payment transaction request to an issuer server (e.g., the issuer server 110 of FIG. 1). The database 1125 stores transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00175] In one example embodiment, the acquirer server 108 is configured to send an authorization request message to the payment server 1100. The authorization request message includes, but is not limited to, the payment transaction request.
[00176] The processing system 1105 further sends the payment transaction request to the issuer server 110 for facilitating payment transaction from the remote device 1120. The processing system 1105 is further configured to notify the remote device 1120 of the transaction status in form of an authorization response message via the communication interface 1115. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 110. Alternatively, in one embodiment, the processing system 1105 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 1115, to the acquirer server 108.
[00177] FIG. 12 is a simplified block diagram of a server system 1200, in accordance with an embodiment of the present disclosure. The server system 1200 includes a computer system 1202 and a database 1204. In an embodiment, the server system 1200 is integrated, but not limited to, in the server system 122. The server system 1200 is communicably linked to the payment network 112, the issuer server 110 and the acquirer server 108.
[00178] The computer system 1202 includes at least one processor 1206 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 1208. The components of the computer system 1202 provided herein may not be exhaustive and that the computer system 1202 may include more or fewer components than that of 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 computer system 1202 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00179] The processor 1206 is operatively coupled to a communication interface 1210 such that the computer system 1202 is capable of communicating with a remote device 1214 such as the acquirer server 108, associated with the payment network 112 (shown in FIG. 1), respectively or communicated with any entity connected to the network 118 (shown in FIG. 1) or any constituents of the acquirer server 108. In an embodiment, the communication interface 1210 is configured to receive a request for transmitting the alert message on the user device 104 of the user 102. The communication interface 1210 is configured to receive a request for initiating the authentication process or the advance authentication process. In addition, the communication interface 1210 is configured to receive a request for generation of the authentication request message. The communication interface 1210 may also be configured to receive the authentication response message as a response to the authentication request message from the user device 104.
[00180] The processor 1206 may also be operatively coupled to the database 1204. The database 1204 is an example of the database 116 or the outstanding transaction database 124. The database 1204 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of merchant, transaction data generated as part of sales activities conducted over the payment network 112 including data relating to merchants, payees, or customers, and purchases. The database 1204 may also store transaction status, information of failed transactions, information set including timestamp information of the SI transactions, bank details of the merchant, credentials of the merchant, security certificates, and the like. The database 1204 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 1204 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00181] In some embodiments, the database 1204 is integrated within the computer system 1202. For example, the computer system 1202 may include one or more hard disk drives as the database 1204. The storage interface 1212 is any component capable of providing the processor 1206 with access to the database 1204. The storage interface 1212 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 1206 with access to the database 1204.
[00182] The processor 1206 is configured to store the information set including timestamp information of the SI transaction associated with the user (e.g., 102 of FIG. 1) in the database (e.g., 116 of FIG. 1) upon approval of the SI transaction from the issuer server (e.g., 110 of FIG. 1). In addition, the processor 1206 is configured to transmit the alert message on the user device (e.g., 104 of FIG. 1) associated with the user (e.g., 102 of FIG. 1) based, at least in part, on the timestamp information of the SI transaction for informing the user (e.g., 102 of FIG. 1) about upcoming SI transaction after a period of time. Further, the processor 1206 is configured to detect activeness of the user (e.g., 102 of FIG. 1) on the user device (e.g., 104 of FIG. 1) in real-time based, at least in part, on a read receipt received from the user device (e.g., 104 of FIG. 1) for the alert message. Furthermore, the processor 1206 is configured to send an authentication request message to the user device (e.g., 104 of FIG. 1) for initiating the authentication process. Moreover, the processor 1206 is configured to an authentication response message as a response to the authentication request message from the user device (e.g., 104 of FIG. 1).
[00183] FIG. 13 shows a simplified block diagram of a device 1300 for example, the user device 104 of FIG. 1 capable of implementing the various embodiments of the present disclosure. The device 1300 is depicted to include one or more applications 1306. The device 1300 is an example of the user device 104. It should be understood that the device 1300 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the device 1300 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 13. As such, among other examples, the device 1300 could be any of an electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00184] The illustrated device 1300 includes a controller or a processor 1302 (e.g., a signal processor, microprocessor, graphics processing unit (GPU), ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1304 controls the allocation and usage of the components of the device 1300 and support for one or more applications programs (see, applications 1306), such as an application interface in a user device (e.g., the user device 104) of a user (e.g., the user 102) or an application interface in a merchant device (not shown). The application interface in the user device 104 is used for receiving the alert message, receiving the authentication request message from the server system 122 of FIG. 1, sending the authentication response message to the server system 122 of FIG. 1 and the like.
[00185] In addition to the application interface, the applications 1306 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications such as USSD messaging or SMS messaging or SIM Tool Kit (STK) application) or any other computing application.
[00186] The illustrated device 1300 includes one or more memory components, for example, a non-removable memory 1308 and/or removable memory 1310. The non-removable memory 1308 and/or removable memory 1310 may be collectively known as database in an embodiment. The non-removable memory 1308 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1310 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1304 and the applications 1306. The device 1300 may further include a user identity module (UIM) 1312. The UIM 1312 may be a memory device having a processor built in. The UIM 1312 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1312 typically stores information elements related to a mobile subscriber. The UIM 1312 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA7000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00187] The device 1300 can support one or more input devices 1320 and one or more output devices 1330. Examples of the input devices 1320 may include, but are not limited to, a touch screen / a screen 1322 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1324 (e.g., capable of capturing voice input), a camera module 1326 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1328. Examples of the output devices 1330 may include but are not limited to a speaker 1332 and a display 1334. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1322 and the display 1334 can be combined into a single input/output device.
[00188] A wireless modem 1340 can be coupled to one or more antennas (not shown in the FIG. 13) and can support two-way communications between the processor 1302 and external devices, as is well understood in the art. The wireless modem 1340 is shown generically and can include, for example, a cellular modem 1342 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1344 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1346. The wireless modem 1340 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the device 1300 and a public switched telephone network (PSTN).
[00189] The device 1300 can further include one or more input/output ports 1350 for establishing connection with peripheral devices including a power supply 1352, one or more sensors 1354 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the device 1300 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1356 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1360, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00190] With the application (see, applications 1306) and/or other software or hardware components, the device 1300 can implement the technologies described herein. In one example embodiment, the processor 1302 can cause registration of the SI mandate, approval for the SI debit transaction, receiving the alert message from the server system 122, receiving the authentication request message from the server system 122, sending the authentication response message to the server system 122, and the like.
[00191] In one embodiment, a computer program is provided, and the program is embodied on a computer readable medium. In an example embodiment, the device 1300 is executed on a single computer system, without requiring a connection to a sever computer. In a further embodiment, the system is being run in a Windows® environment (Windows is a registered trademark of Microsoft Corporation, Redmond, Washington). In yet another embodiment, the system is run on a mainframe environment and a UNIX® server environment (UNIX is a registered trademark of X/Open Company Limited located in Reading, Berkshire, United Kingdom). In a further embodiment, the system is run on an iOS® environment (iOS is a registered trademark of Cisco Systems, Inc. located in San Jose, CA). In yet a further embodiment, the device 1300 is run on a Mac OS® environment (Mac OS is a registered trademark of Apple Inc. located in Cupertino, CA). In still yet a further embodiment, the system is run on Android® OS (Android is a registered trademark of Google, Inc. of Mountain View, CA). In another embodiment, the system is run on Linux® OS (Linux is a registered trademark of Linus Torvalds of Boston, MA). The application is flexible and designed to run in various different environments without compromising any major functionality. In some embodiments, the device 1300 includes multiple components distributed among a plurality of computing devices. One or more components may be in the form of computer-executable instructions embodied in a computer-readable medium.
[00192] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for performing additional authentication for receiving consent/approval from the user to debit payment amount from payment account of the user for recurring payments based on the standing instructions already registered with the issuer server. In addition, the user is notified in advance with the alert message about the payment due in next few days and the payment transaction is carried out only after receiving consent/approval from the user.
[00193] The disclosed methods with reference to FIGS. 1 to 13, or one or more operations of the method 800 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means 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.
[00194] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. 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).
[00195] Particularly, the server system 1200 (e.g., the server system 122) and its various components such as the computer system 1202 and the database 1204 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 disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g., magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00196] Various embodiments of the disclosure, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the disclosure has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the disclosure.
[00197] Although various exemplary embodiments of the disclosure 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.