Claims:1. A method for facilitating a transaction between a payer and a payee, the method comprising:
receiving, by an application server, from a payer device of the payer, a transaction request including a payer account identifier and a payee account identifier;
retrieving, by the application server, from a database, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier based on the transaction request;
identifying, by the application server, a plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts, wherein the plurality of network routes include a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers;
determining, by the application server, a set of operational parameters and uptime/downtime for each of the one or more issuer servers and the one or more acquirer servers;
selecting, by the application server, from the plurality of network routes, an alternate network route that is different from the default network route for processing the transaction, wherein the alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime; and
processing, by the application server, the transaction based on the selected alternate network route.

2. The method of claim 1, wherein the set of operational parameters include at least one of a processing speed and a response time.

3. The method of claim 1 or claim 2, wherein determining the set of operational parameters and the uptime/downtime for the one or more issuer servers and the one or more acquirer servers comprises:
communicating, by the application server, a test request to each of the one or more issuer servers and the one or more acquirer servers; and
receiving, by the application server, an acknowledgement from each of the one or more issuer servers and each of the one or more acquirer servers in response to the test request, wherein the set of operational parameters and the uptime/downtime for each of the one or more issuer servers and the one or more acquirer servers are determined based on the received acknowledgements.

4. The method of claim 3, further comprising ranking, by the application server, the plurality of network routes in an order based on the determination of the set of operational parameters and the uptime/downtime of the one or more issuer servers and the one or more acquirer servers, wherein the selection of the alternate network route for processing the transaction is further based on the ranking of the plurality of network routes.

5. The method of claim 4, wherein the first issuer server and the first acquirer server are determined to exhibit the downtime when the first issuer server and the first acquirer server are unresponsive to the corresponding test requests.

6. A system to facilitate a transaction between a payer and a payee, the system comprising:
an application server configured to:
receive, from a payer device of the payer, a transaction request including a payer account identifier and a payee account identifier;
retrieve, from a database, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier based on the transaction request;
identify a plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts, wherein the plurality of network routes includes a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers;
determine a set of operational parameters and uptime/downtime for each of the one or more issuer servers and the one or more acquirer servers;
select, from the plurality of network routes, an alternate network route that is different from the default network route for processing the transaction, wherein the alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime; and
process the transaction based on the selected alternate network route.

7. The system of claim 6, wherein the set of operational parameters include at least one of a processing speed and a response time.

8. The system of claim 6 or claim 7, wherein to determine the set of operational parameters and the uptime/downtime for the one or more issuer servers and the one or more acquirer servers, the application server is configured to:
communicate a test request to each of the one or more issuer servers and the one or more acquirer servers; and
receive an acknowledgement from each of the one or more issuer servers and each of the one or more acquirer servers in response to the test request, wherein the set of operational parameters and the uptime/downtime for each of the one or more issuer servers and the one or more acquirer servers are determined based on the received acknowledgements.

9. The system of claim 7, wherein the application server is further configured to rank the plurality of network routes in an order based on the determination of the set of operational parameters and the uptime/downtime of the one or more issuer servers and the one or more acquirer servers, and wherein the selection of the alternate network route for processing the transaction is further based on the ranking of the plurality of network routes.

10. A method for facilitating a unified payment interface (UPI) transaction between a payer and a payee, the method comprising:
receiving, by an application server, from a payer device of the payer, a request including a payer account identifier and a payee account identifier;
retrieving, by the application server, from a database, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier based on the received request;
identifying, by the application server, a plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts, wherein the plurality of network routes includes a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers, for the UPI transaction;
determining, by the application server, a set of operational parameters and uptime/downtime for the one or more issuer servers and the one or more acquirer servers;
selecting, by the application server, from the plurality of network routes, an alternate network route that is different from the default network route for processing the transaction, wherein the alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime; and
communicating, by the application server, a recommendation message to the payer device to recommend the selected alternate network route to the payer for the UPI transaction.
, Description:FIELD OF THE DISCLOSURE
Various embodiments of the present disclosure relate generally to electronic transaction systems. More particularly, various embodiments of the present disclosure relate to methods and systems for facilitating UPI transactions between payers and payees.

DESCRIPTION OF THE RELATED ART
Advancement in technology and proliferation of the Internet has revolutionized the way individuals (i.e., payers and payees) conduct payment transactions. For example, the individuals now-a-days are able to conduct payment transaction on-the-fly by using various online transaction platforms, such as UPI.
Although UPI enables instantaneous payment transactions, problem arises when a payer performs a UPI transaction and the UPI transaction fails with a transaction amount being deducted from a payer’s issuing account. Typically, it takes a significant amount of time, such as 2-7 business days, for a financial institution of the payer’s issuing account to scrutinize at which stage the transaction got failed and then credit back (or roll back) the deducted amount to the payer’s issuing account. For example, the transaction may fail due to a network connectivity issue between one or more transacting parties, such as an issuer, an acquirer, or a payment gateway. As a result, the payer may face shortage of funds for conducting another transaction, until the deducted transaction amount is credited back to the payer’s issuing account, thereby inconveniencing the payer as well as a payee involved in the transaction. Such transaction experience may further adversely impact a number of individuals opting for UPI transaction service, which is undesirable.
In light of the foregoing, there is a need for a technical solution that solves the above-mentioned problems and facilitates an uninterrupted UPI transaction between a payer and a payee.

SUMMARY

In an embodiment of the present disclosure, a method for facilitating a transaction between a payer and a payee is provided. The method includes receiving, by an application server, from a payer device of the payer, a transaction request including a payer account identifier and a payee account identifier. Based on the transaction request, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier are retrieved from a database by the application server. A first issuer server and a first acquirer server are selected by the application server. A plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts are identified by the application server. The plurality of network routes include a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers, for the transaction. A set of operational parameters and uptime/downtime for the one or more issuer servers and the one or more acquirer servers are determined by the application server. From the plurality of network routes, an alternate network route that is different from the default network route is selected by the application server for processing the transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime. The transaction is processed by the application server based on the selected alternate network route.
In another embodiment of the present disclosure, a system to facilitate a transaction between a payer and a payee is provided. The system includes an application server that is configured to receive, from a payer device of the payer, a transaction request including a payer account identifier and a payee account identifier. Based on the transaction request, the application server is configured to retrieve from a database, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier based on the transaction request. The application server is further configured to identify a plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts. The plurality of network routes include a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers, for the transaction. The application server is further configured to select, from the plurality of network routes, an alternate network route that is different from the default network route for processing the transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime. The application server is further configured to process the transaction based on the selected alternate network route.
In another embodiment of the present disclosure, a method for facilitating a Unified Payment Interface (UPI) transaction between a payer and a payee is provided. The method includes receiving, by an application server, from a payer device of the payer, a request including a payer account identifier and a payee account identifier. Based on the received request, one or more payer payment accounts associated with the payer account identifier and one or more payee payment accounts associated with the payee account identifier are retrieved by the application server from a database. A plurality of network routes between one or more issuer servers associated with the one or more payer payment accounts and one or more acquirer servers associated with the one or more payee payment accounts are identified by the application server. The plurality of network routes include a default network route, formed by a first issuer server of the one or more issuer servers and a first acquirer server of the one or more acquirer servers, for the UPI transaction. A set of operational parameters and uptime/downtime for the one or more issuer servers and the one or more acquirer servers are determined by the application server. From the plurality of network routes, an alternate network route that is different from the default network route is selected by the application server for processing the UPI transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server and the first acquirer server is exhibiting the downtime. A recommendation message is communicated to the payer device by the application server to recommend the selected alternate network route for the UPI transaction.

BRIEF DESCRIPTION OF DRAWINGS
[0001] The accompanying drawings illustrate the various embodiments of systems, methods, and other aspects of the disclosure. It will be apparent to a person skilled in the art that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of one element may be implemented as an external component in another, and vice versa.
Various embodiments of the present disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements:
FIG. 1 is a block diagram that illustrates an exemplary environment for facilitating Unified Payment Interface (UPI) transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 2A is a process flow diagram that illustrates an exemplary process for linking a payer payment account of a payer to a UPI service application, in accordance with an exemplary embodiment of the present disclosure;
FIG. 2B is a process flow diagram that illustrates an exemplary process for linking a payee payment account of a payee to the UPI service application, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 3A, 3B, and 3C, collectively represent a process flow diagram that illustrates facilitation of a UPI transaction between a payer and a payee by an application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 4A, 4B, and 4C, collectively represent a process flow diagram that illustrates facilitation of a UPI transaction between a payer and a payee by the application server of FIG. 1, in accordance with another exemplary embodiment of the present disclosure;
FIG. 5A is a process flow diagram that illustrates an exemplary process for determining operational parameters and uptime/downtime for first and second issuer servers and first and second acquirer servers of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIG. 5B is a process flow diagram that illustrates an exemplary process for determining operational parameters and uptime/downtime for the first and second issuer servers and the first and second acquirer servers of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIG. 6 is a block diagram that illustrates the application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIG. 7 is a block diagram that illustrates a system architecture of a computer system, in accordance with an embodiment of the present disclosure;
FIGS. 8A and 8B, collectively represent a flowchart that illustrates a method for facilitating a UPI transaction between a payer and a payee by the application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 9A and 9B, collectively represent a flowchart that illustrates a method for facilitating a UPI transaction between a payer and a payee by the application server of FIG. 1, in accordance with another exemplary embodiment of the present disclosure;
FIG. 10 is a flowchart that illustrates a method for determining operational parameters and uptime/downtime for the first and second issuer servers and the first and second acquirer servers of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIG. 11 is a high-level flowchart that illustrates a method for facilitating a transaction between a payer and a payee by the application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure; and
FIG. 12 is a high-level flowchart that illustrates a method for facilitating a UPI transaction between a payer and a payee by the application server of FIG. 1, in accordance with another exemplary embodiment of the present disclosure.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments is intended for illustration purposes only and is, therefore, not intended to necessarily limit the scope of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The present disclosure is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
References to “an embodiment”, “another embodiment”, “yet another embodiment”, “one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
Conventionally, a Unified Payment Interface (UPI) transaction executed between a payer and a payee may fail with a transaction amount being deducted from a payer’s issuing account. As a result, the payer may face shortage of funds for conducting another transaction, until the deducted transaction amount is credited back to the payer’s issuing account. Thus, both the payer and the payee are inconvenienced by the failed UPI transaction, which is undesirable.
Various embodiments of the present disclosure provide a method and a system that solve the above-mentioned problems by facilitating a ‘Preliminary Check Service ‘at an application server (e.g., a UPI server) before a UPI transaction is processed. The ‘Preliminary Check Service’ may be automated or activated by the payer at discretion. The application server receives, from a payer device of the payer, a transaction request including a payer account identifier and a payee account identifier. Based on the transaction request, the application server retrieves various payer payment accounts that are associated with the payer account identifier and various payee payment accounts that are associated with the payee account identifier. The application server then identifies various issuer servers that maintain the payer payment accounts and various acquirer servers that maintain the payee payment accounts. With the ‘Preliminary Check Service’ being implemented, the application server further identifies a plurality of network routes between the identified issuer servers and the identified acquirer servers. Each network route of the plurality of network routes includes a different issuer-acquirer server pair from the identified issuer and acquirer servers. Further, one of the plurality of network routes corresponds to a default network route for the transaction. The default network route is formed by a default issuer server of the identified issuer servers and a default acquirer server of the identified acquirer servers. The application server further determines a set of operational parameters and uptime/downtime for the identified issuer and acquirer servers. The set of operational parameters may include at least one of a processing speed and a response time.
For determining the set of operational parameters and uptime/downtime, the application server communicates test requests to the identified issuer and acquirer servers. In response to the communicated test requests, the application server receives acknowledgements from one or more identified issuer and acquirer servers. The application server then determines the set of operational parameters and the uptime/downtime for each of the identified issuer and acquirer servers based on the received acknowledgements. In one example, an issuer server or an acquirer server is determined to exhibit an uptime if an acknowledgement to the test request is received from the issuer server or the acquirer server within a specific time interval. Similarly, an issuer server or an acquirer server is determined to exhibit a downtime if no acknowledgement is received from the issuer server or the acquirer server within the specific time interval. The response time associated with an issuer server or an acquirer server refers to a time duration between the communication of a corresponding test request and the reception of the acknowledgement from the corresponding issuer or acquirer server. The application server further ranks the plurality of network routes in an order (e.g., ascending order or descending order) based on the determined set of operational parameters and the determined uptime/downtime of the identified issuer and acquirer servers. From the plurality of network routes, the application server selects an alternate network route that is different from the default network route for processing the UPI transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the default issuer server and the default acquirer server is exhibiting the downtime. The UPI transaction is then processed as per the selected alternate network route.
Thus, instead of processing the UPI transaction using the default network route, the application server identifies an optimal network route for the UPI transaction when the ‘Preliminary Check Service’ is activated or offered. Since the selection of the optimal network route is performed before the processing of the UPI transaction, a likelihood of the UPI transaction getting failed due to downtime or high response time of a transacting party is significantly reduced. As a result, the payer and payee are offered with a better and uninterrupted UPI transaction experience.
TERM DESCRIPTION (in addition to plain and dictionary meaning)
UPI transaction refers to an immediate real-time payment transaction in which funds are instantly transferred from a payer’s payment account to a payee’s payment account through a mobile platform, such as a mobile application executed on a mobile phone.
Payer device is an electronic communication device that enables a payer to perform an online payment transaction, such as a UPI transaction. The payer device further enables the payer to communicate payer and payee account identifiers for the UPI transaction to a UPI server. The payer device further enables the payer to provide authentication information, such as an instant personal identification number, IPIN, for authentication purposes. Examples of the payer device include a mobile phone, a laptop, a smartphone, a tablet, and/or the like.
Payer account identifier is a unique identifier that is linked to various payment accounts of a payer on which UPI transaction service is activated. In one example, the payer account identifier is a registered contact number of the payer.
Payee account identifier is a unique identifier that is linked to various payment accounts of a payee on which UPI transaction service is activated. In one example, the payee account identifier is a registered contact number of the payee.
Preliminary check request is a service request initiated at a payer device by a payer to check a likelihood of a UPI transaction getting failed due to downtime or performance issues (e.g., low processing speed or high response time) of one or more transacting parties. In response to the preliminary check request, the payer is notified whether it is safe to conduct a UPI transaction from a default payment account or use another active payment account to avoid UPI transaction failure.
Network route for a transaction corresponds to an issuer-acquirer pair used for processing the transaction. A default network route for a transaction between a payer and a payee includes an issuer server that maintains a default payer payment account and an acquirer server that maintains a default payee payment account.
Operational parameters refer to various metrics that quantify the performance of an issuer server or an acquirer server. Examples of the operational parameters include a processing speed and a response time. In an example, if an issuer server involved in a UPI transaction is exhibiting very high response time or very low processing speed, the UPI transaction, if performed, is highly likely to get failed due to session time out. In another example, if an acquirer server involved in a UPI transaction is exhibiting very high response time or very low processing speed, the UPI transaction, if performed, is highly likely to get failed due to session time out.
Uptime/downtime refers to a criterion based on which it is determined whether an issuer server or an acquirer server is available for processing a UPI transaction. For example, if an issuer server is experiencing the downtime, the issuer server is determined to be unavailable.
Test request is a dummy request or message communicated to an issuer server or an acquirer server to determine uptime/downtime and operational parameters of the corresponding issuer server or the corresponding acquirer server. In one example, the test request is a zero funds transfer request.
Acknowledgement is a message or notification communicated by an issuer server or an acquirer server in response to receiving a test request. In one example, the acknowledgement is a zero funds transfer response.
A server is a physical or cloud data processing system on which a server program runs. The server may be implemented as hardware or software, or a combination thereof. The server may correspond to an application server, an issuer server, or an acquirer server. The server executes various programs required for processing a payment transaction.
FIG. 1 is a block diagram that illustrates an exemplary environment 100 for performing Unified Payment Interface (UPI) transactions, in accordance with an exemplary embodiment of the present disclosure. The environment 100 includes a payer 102 having a payer device 104. The environment 100 further includes a payee 106 having a payee device 108. The environment 100 further includes a first issuer server 110, a second issuer server 112, a first acquirer server 114, a second acquirer server 116, and an application server 118. The payer and payee devices 104 and 108, the first and second issuer servers 110 and 112, the first and second acquirer servers 114 and 116, and the application server 118 may communicate with each other by way of a communication network 120 or through separate communication channels there between.
The payer 102 is an account holder of various payer payment accounts maintained at different financial institutions, such as issuers. For example, the payer 102 may be the account holder of two payer payment accounts A and B, maintained at two different issuers, e.g., first and second issuers, respectively. The payer 102 may utilize the payer device 104 for performing the UPI transactions from the payer payment accounts A and B. Examples of the payer payment accounts A and B may include savings accounts, current accounts, debit accounts, credit accounts, digital wallet accounts, or the like.
The payer device 104 is a computing device of the payer 102. The payer device 104 may be utilized by the payer 102 for performing the UPI transactions from any of the payer payment accounts A and B. The payer device 104 may be configured to execute (or run) a service application 122 which enables the payer 102 to avail a UPI transaction service on the payer payment accounts A and B. The payer device 104 may be utilized by the payer 102 to link the payer payment accounts A and B to the service application 122 for availing the UPI transaction service on the payer payment accounts A and B. The service application 122 may be hosted by the application server 118 or a third-party server (not shown) capable of open-banking service. Any request initiated at the payer device 104 by way of the service application 122 for availing the UPI transaction service may be communicated directly to the application server 118 or through the third-party server. Examples of the payer device 104 may include a mobile phone, a laptop, a smartphone, a tablet, a phablet, or the like.
The payee 106 is an account holder of various payee payment accounts maintained at different financial institutions, such as acquirers. For example, the payee 106 may be the account holder of two payee payment accounts C and D, maintained at two different acquirers, e.g., first and second acquirers, respectively. The payee 106 may utilize the payee device 108 for performing the UPI transactions from the payee payment accounts C and D. Examples of the payee payment accounts may include savings accounts, current accounts, debit accounts, credit accounts, digital wallet accounts, or the like.
The payee device 108 is the computing device of the payee 106. The payee device 108 may be utilized by the payee 106 for performing the UPI transactions from any of the payee payment accounts C and D. The payee device 108 may be configured to execute (or run) the service application 122 which enables the payee 106 to avail the UPI transaction service on the payee payment accounts C and D. The payee device 108 may be utilized by the payee 106 to link the payee payment accounts C and D to the service application 122 for availing the UPI transaction service on the payee payment accounts C and D. Any request initiated at the payee device 108 by way of the service application 122 for availing the UPI transaction service may be communicated directly to the application server 118 or through the third-party server. Examples of the payee device 108 may include a mobile phone, a laptop, a smartphone, a tablet, a phablet, or the like.
The first and second issuer servers 110 and 112 are server arrangements which include suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing transactions. The first and second issuer servers 110 and 112 are associated with the first and second issuers, respectively, that maintain payment accounts of various payers. For example, the first and second issuer servers 110 and 112 maintain the payer payment accounts A and B, respectively, of the payer 102. The first and second issuer servers 110 and 112 may be configured to communicate with the application server 118 and the first and second acquirer servers 114 and 116 via the communication network 120 for processing the transactions. The first and second issuer servers 110 and 112 may be further configured to authenticate the payer 102 for the transactions performed from the payer payment accounts A and B, respectively, and authorize the transactions upon successful authentication. The first and second issuer servers 110 and 112 may be configured to credit and debit the payment accounts based on transactions made by the payers from their corresponding payment accounts.
The first and second acquirer servers 114 and 116 are server arrangements which include suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing various transactions. The first and second acquirer servers 114 and 116 are associated with the first and second acquirers, respectively, that maintain payee payment accounts of various payees. For example, the first and second acquirer servers 114 and 116 maintain the payee payment accounts C and D, respectively, of the payee 106. The first and second acquirer servers 114 and 116 may be configured to communicate with the application server 118 and the first and second issuer servers 110 and 112 via the communication network 120. The first and second acquirer servers 114 and 116 may be configured to credit and debit the payment accounts based on transactions made by the payees from their corresponding payment accounts.
The application server 118 is a server arrangement (e.g., a UPI switch) that offers the UPI transaction service to users (e.g., the payer 102 and the payee 106) for performing instantaneous online payment transactions. The application server 118 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing various UPI transactions. The application server 118 may represent an entity between the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 for facilitating the UPI transactions. In an embodiment, the application server 118 may be configured to host the service application 122 that is executable on various user devices (e.g., the payer device 104 and the payee device 108) for offering the UPI transaction service. In another embodiment, the application server 118 may be configured to communicate with the third-party server that hosts the service application 122 for facilitating the UPI transactions. The application server 118 may be configured to offer a preliminary check service for the UPI transactions. When the preliminary check service is activated for the UPI transaction, the application server 118 may be configured to select a most optimal network route for executing the UPI transaction. For example, the most optimal network route selected for the UPI transaction between the payer 102 and the payee 106 may include an up and running issuer-acquirer pair that maintains active payer and payee payment accounts and exhibits best network performance. Various operations performed by the application server 118 for facilitating the UPI transactions are described in detail in conjunction with FIGS. 2A, 2B, 3A-3C, 4A-4C, 5A, and 5B.
Examples of the first and second issuer servers 110 and 112, the first and second acquirer servers 114 and 116, and the application server 118 may include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that may execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
The communication network 120 is a medium through which content and messages are transmitted between the payer device 104, the payee device 108, the first and second issuer servers 110 and 112, the first and second acquirer servers 114 and 116, and/or the application server 118. Examples of the communication network 120 may include, but are not limited to, a Wi-Fi network, 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, and combinations thereof. Various entities in the environment 100 may connect to the communication network 120 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof.
FIG. 2A is a process flow diagram 200A that illustrates an exemplary process for linking a payer payment account of the payer 102 to the service application 122, in accordance with an exemplary embodiment of the present disclosure. For the sake of brevity, the process flow diagram 200A illustrates the linking of the payer payment account A to the service application 122.
The payer device 104 may be utilized by the payer 102 to access the service application 122 for linking the payer payment account A to the service application 122 (as shown by arrow 202). When the service application 122 is accessed on the payer device 104, a graphical user interface (GUI) of the service application 122 may be rendered on a display of the payer device 104. By way of the rendered GUI, the payer 102 may be prompted to select an issuer that maintains a payment account to be linked to the service application 122. In an example, the first issuer that maintains the payer payment account A may be selected by the payer 102 through the GUI. Based on the selection by the payer 102, an access request may be generated by the service application 122. The access request may include a contact number (e.g., a mobile number) associated with the payer device 104 and an issuer identifier of the first issuer. In an embodiment, the contact number may be automatically obtained by the service application 122 by accessing a memory of the payer device 104. In another embodiment, the contact number may be manually provided by the payer 102 using the rendered GUI. The payer device 104 may communicate the access request to the application server 118 (as shown by arrow 204a).
Based on the issuer identifier in the received access request, the application server 118 may identify the first issuer and communicate the access request to the first issuer server 110 (as shown by arrow 204b). The first issuer server 110 may receive the access request and identify a payment account that is associated with the contact number included in the access request. For example, the first issuer server 110 may store a first record set that includes a list of various payment accounts maintained at the first issuer server 110 and corresponding registered contact numbers. The first issuer server 110 may search (or look up) in the first record set to identify a match for the contact number included in the access request. In the current exemplary scenario, the first issuer server 110 may identify that the contact number in the access request is stored in the first record set against the payer payment account A.
The first issuer server 110 may then generate a request to obtain an authentication code (e.g., instant personal identification number, IPIN) associated with the payer payment account A. The first issuer server 110 may communicate the request for authentication code to the application server 118 (as shown by arrow 206a). The application server 118 may communicate the request for authentication code to the payer device 104 (as shown by arrow 206b). The payer device 104 may receive the request for authentication code and prompt the payer 102 to provide the authentication code associated with the payer payment account A. Based on the prompting, the authentication code may be entered on the payer device 104 by the payer 102 (as shown by arrow 208). Upon receiving the authentication code, the payer device 104 may communicate the authentication code to the application server 118 (as shown by arrow 210a). The application server 118 may then communicate the received authentication code to the first issuer server 110 (as shown by the arrow 210b).
The first issuer server 110 may receive the authentication code and authenticate the payer 102 (as shown by arrow 212). The payer 102 is successfully authenticated when the first issuer server 110 determines that the authentication code provided by the payer 102 is correct. Based on the authentication of the payer 102, the first issuer server 110 may communicate an authentication response to the application server 118 (as shown by arrow 214a). The authentication response may be indicative of a result of authentication and may include the details of the payer payment account A. For example, the authentication response may include an account number of the payer payment account A, a name of accountholder, a payer account identifier (e.g., the registered contact number), or the like. The application server 118 may communicate the authentication response to the payer device 104 (as shown by arrow 214b) and update the details of the payer payment account A in a database (as shown by arrow 216). When the details of the payer payment account A are updated or added to the database, the UPI transaction service is activated for the payer payment account A and a first UPI identifier (e.g., a first UPI ID) is associated with (or linked to) the payer payment account A.
The payer device 104 may receive the authentication response. When the authentication response indicates successful authentication, the payer payment account A is linked to the service application 122 and a confirmation message “account linked” is displayed on the payer device 104 (as shown by arrow 218). In one example, the authentication response may be presented on the payer device 104 as a push notification on the service application 122. However, if the authentication response indicates failed authentication, the payer payment account A is not linked to the service application 122. The payer 102 may re-attempt to link the payer payment account A to the service application 122. After the activation of the UPI service of the payer payment account A, the UPI transactions may be performed from the payer payment account A.
It will be apparent to a person of ordinary skill in the art that other payer payment accounts (such as the payer payment account B) may be linked or added to the service application 122 in a similar manner as described above for the payer payment account A, without deviating from the scope of the disclosure. For example, the payer payment account B may be linked to the service application 122 and the details of the payer payment account B may be updated in the database. The payer payment accounts A and B are associated with (or linked to) the same first UPI ID and the payer account identifier (i.e., the registered contact number of the payer 102).
FIG. 2B is a process flow diagram 200B that illustrates an exemplary process for linking a payee payment account of the payee 106 to the service application 122, in accordance with an exemplary embodiment of the present disclosure. For the sake of brevity, the process flow diagram 200B illustrates the linking of the payee payment account C to the service application 122.
The payee device 108 may be utilized by the payee 106 to access the service application 122 for linking the payee payment account C to the service application 122 (as shown by arrow 220). When the service application 122 is accessed on the payee device 108, the GUI of the service application 122 may be rendered on the display of the payee device 108. By way of the rendered GUI, the payee 106 may be prompted to select an acquirer that maintains the payment account to be linked to the service application 122. In an example, the first acquirer that maintains the payee payment account C may be selected by the payee 106 through the GUI. Based on the selection by the payee 106, an access request may be generated by the service application 122. The access request may include a contact number (e.g., a mobile number) associated with the payee device 108 and an acquirer identifier of the first acquirer. The payee device 108 may communicate the access request to the application server 118 (as shown by arrow 222a).
Based on the acquirer identifier in the received access request, the application server 118 may identify the first acquirer and communicate the access request to the first acquirer server 114 (as shown by arrow 222b). The first acquirer server 114 may receive the access request and identify the payment account that is associated with the contact number included in the access request. For example, the first acquirer server 114 may store a second record set that includes a list of various payment accounts maintained at the first acquirer server 114 and corresponding registered contact numbers. The first acquirer server 114 may search (or look up) in the second record set to identify a match for the contact number included in the access request. In the current exemplary scenario, the first acquirer server 114 may identify that the contact number in the access request is stored in the second record set against the payee payment account C.
The first acquirer server 114 may then generate a request to obtain an authentication code (e.g., IPIN) associated with the payee payment account C. The first acquirer server 114 may communicate the request for authentication code to the application server 118 (as shown by arrow 224a). The application server 118 may communicate the request for authentication code to the payee device 108 (as shown by arrow 224b). The payee device 108 may receive the request for authentication code and prompt the payee 106 to provide the authentication code associated with the payee payment account C. Based on the prompting, the authentication code may be entered on the payee device 108 by the payee 106 (as shown by arrow 226). Upon receiving the authentication code, the payee device 108 may communicate the authentication code to the application server 118 (as shown by arrow 228a). The application server 118 may then communicate the authentication code to the first acquirer server 114 (as shown by the arrow 228b). The first acquirer server 114 may receive the authentication code and authenticate the payee 106 (as shown by arrow 230). The payee 106 is successfully authenticated when the first acquirer server 114 determines that the authentication code provided by the payee 106 is correct. Based on the authentication of the payee 106, the first acquirer server 114 may communicate an authentication response to the application server 118 (as shown by arrow 232a). The authentication response may be indicative of a result of authentication and may include the details of the payee payment account C. For example, the authentication response may include an account number of the payee payment account C, a name of accountholder, a payee account identifier (e.g., the registered contact number), or the like. The application server 118 may communicate the authentication response to the payee device 108 (as shown by arrow 232b) and update the details of the payee payment account C in the database (as shown by arrow 234). When the details of the payee payment account C are updated or added to the database, the UPI transaction service is activated for the payee payment account C and a second UPI ID is associated with (or linked to) the payee payment account C.
The payee device 108 may receive the authentication response. When the authentication response indicates successful authentication, the payee payment account C is linked to the service application 122 and a confirmation message “account linked” is displayed on the payee device 108 (as shown by arrow 236). In one example, the authentication response may be presented on the payee device 108 as a push notification on the service application 122. However, if the authentication response indicates failed authentication, the payee payment account C is not linked to the service application 122. The payee 106 may re-attempt to link the payee payment account C to the service application 122. After the activation of the UPI service of the payee payment account C, the UPI transactions may be performed from the payee payment account C.
It will be apparent to a person of ordinary skill in the art that other payee payment accounts (such as the payee payment account D) may be linked or added to the service application 122 in a similar manner as described above for the payee payment account C, without deviating from the scope of the disclosure. For example, the payee payment account D may be linked to the service application 122 and the details of the payee payment account D may be updated in the database. The payee payment accounts C and D are associated with (or linked to) the same second UPI ID and the payee account identifier (i.e., the registered contact number of the payee 106).
FIGS. 3A, 3B, and 3C, collectively represent a process flow diagram 300 that illustrates facilitation of a UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with another exemplary embodiment of the present disclosure. In a non-limiting example, it is assumed that the UPI transaction service is already activated on the payer payment accounts A and B and the payee payment accounts C and D. Activation of the UPI service is described in the foregoing description of FIGS. 2A and 2B. Further, in a non-limiting example, the payer payment account A and the payee payment account C may be designated as default payment accounts for the UPI transactions by the payer 102 and the payee 106, respectively.
With reference to FIG. 3A, the payer device 104 may be utilized by the payer 102 to access the service application 122 (as shown by arrow 302). For example, when the service application 122 is opened on the payer device 104, the payer device 104 may prompt the payer 102 to provide a login ID and a password for accessing the service application 122. When the login ID and the password provided by the payer 102 are correct, the payer device 104 may grant the payer 102 an access to the service application 122. In an embodiment, when the service application 122 is hosted by the application server 118, the application server 118 determines whether the login ID and the password provided by the payer 102 are correct. In another embodiment, when the service application 122 is hosted by the third-part server, the third-party server determines whether the login ID and the password provided by the payer 102 are correct.
Upon the grant of access, the GUI of the service application 122 may be rendered on the display of the payer device 104 for displaying various payment options to the payer 102 for selection (as shown by arrow 304). Examples of the displayed payment options may include UPI, credit card, debit card, or the like. The payer device 104 may prompt the payer 102 to select one of the payment options displayed on the GUI for initiating a transaction. The payer 102 may want to perform a UPI transaction with the payee 106, and hence, the UPI option is selected by the payer 102 (as shown by arrow 306). When the UPI option is selected, the payer device 104 may prompt the payer 102 to submit the payer account identifier and a payee account identifier. The payee account identifier may be the registered contact number of the payee 106. In an embodiment, only the payee account identifier is submitted by the payer 102 and the payer account identifier may be automatically obtained from the contact number that is active on the payer device 104. In another embodiment, the active contact number on the payer device 104 may not be registered contact number. In such a scenario, both the payer and payee account identifiers are inputted by the payer 102 on the payer device 104 (as shown by arrow 308). When the payer device 104 receives the payer and payee account identifiers, the payer device 104 may communicate a transaction request to the application server 118 (as shown by arrow 310). The transaction request may include the payer and payee account identifiers.
The application server 118 may receive the transaction request and execute the preliminary check service for the UPI transaction. For executing the preliminary check service, the application server 118 may extract (or obtain) the payer and payee account identifiers from the transaction request. The application server 118 may then access the database to determine whether the payer and payee account identifiers are stored in the database. In an exemplary scenario, the payee account identifier may not be stored in the database. In such a scenario, the application server 118 may decline the transaction request and communicate a message to the payer device 104 regarding the payee account identifier being unregistered. In another exemplary scenario, the application server 118 may determine that the payer and payee account identifiers are stored in the database. The application server 118 may then retrieve various payer payment accounts (e.g., the payer payment accounts A and B) that are linked to the payer account identifier and various payee payment accounts (e.g., the payee payment accounts C and D) that are linked to the payee account identifier (as shown by arrow 312). The application server 118 may then identify various issuers that maintain (or are linked to) the payer payment accounts A and B and various acquirers that maintain (or are linked to) the payee payment accounts C and D. In other words, based on the retrieved payer payment accounts A and B, the application server 118 identifies the first and second issuer servers 110 and 112 that maintain the payer payment accounts A and B, respectively. Further, based on the retrieved payee payment accounts C and D, the application server 118 identifies the first and second acquirer servers 114 and 116 that maintain the payee payment accounts C and D, respectively.
The application server 118 may then identify a plurality of network routes (hereinafter, interchangeably referred to as “the network routes”) between the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown by arrow 314). A network route may be formed by a combination of an issuer server and an acquirer server. Thus, each of the identified network routes include a different issuer-acquirer server pair from the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116. The identified plurality of network routes include a default network route formed by the first issuer server 110 that maintain the default payer payment account A and the first acquirer server 114 that maintain the default payee payment account C. The identified plurality of network routes further include other network routes formed by the first issuer server 110 and the second acquirer server 116 pair, the second issuer server 112 and the first acquirer server 114 pair, and the second issuer server 112 and the second acquirer server 116 pair.
With reference to FIG. 3B, the application server 118 may be further configured to determine a set of operational parameters (such as a processing speed, a response time, or the like) and uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown by arrow 316). The uptime/downtime is an availability criterion that indicates whether an issuer server or an acquirer server is up and running for processing transactions. The processing speed and the response time correspond to performance metrics that indicate performance efficiency of an issuer server or an acquirer server. By determining the set of operational parameters and the uptime/downtime, the application server 118 checks the availability and the performance of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 for processing the UPI transaction. For example, if the first issuer server 110 is determined to be exhibiting the downtime, the application server 118 may establish that the first issuer server 110 is unavailable and incapable of processing the UPI transaction. Similarly, if the first acquirer server 114 is determined to be exhibiting the downtime, the application server 118 may establish that the first acquirer server 114 is unavailable and incapable of processing the UPI transaction. In another example, if the processing speed of the first issuer server 110 is greater than the processing speed of the second issuer server 112, the first issuer server 110 is determined to exhibit better performance than the second issuer server 112. Similarly, if the processing speed of the first acquirer server 114 is greater than the processing speed of the second acquirer server 116, the first acquirer server 114 is determined to exhibit better performance than the second acquirer server 116. In another example, if the response time of the first issuer server 110 is less than the response time of the second issuer server 112, the first issuer server 110 is determined to exhibit better performance than the second issuer server 112. Similarly, if the response time of the first acquirer server 114 is less than the response time of the second acquirer server 116, the first acquirer server 114 is considered to exhibit better performance than the second acquirer server 116. The processes of determining the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 are described in detail in conjunction with FIGS. 5A and 5B.
The application server 118 may then select one of the plurality of network routes for processing the UPI transaction (as shown by arrow 318). The selection of one of the plurality of network routes is based on the determination of the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116.
In one example, based on the determined uptime/downtime of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116, the application server 118 may determine that the first issuer server 110 is exhibiting the downtime. The application server 118 may further determine that the second issuer server 112 and the first and second acquirer servers 114 and 116 are up and running at the current time instance. Thus, the application server 110 discards all those identified network routes (e.g., the default network route and the network route including the first issuer server 110 and the second acquirer server 116 pair) that include the first issuer server 110. Further, based on the determined set of operational parameters of the up and running first and second acquirer servers 114 and 116, the application server 118 may determine that the second acquirer server 116 has a lower response time and a higher processing speed than the first acquirer server 114. In such a scenario, the application server 118 may select the network route that includes the second acquirer server 116. Thus, the application server 118 may here select the network route formed by the second issuer server 112 that is currently available and the second acquirer server 116 that is currently available with better performance. In other words, the application server 118 selects, from the plurality of network routes, an alternate network route that is different from the default network route for processing the UPI transaction based on the determined set of operational parameters and the determination that at least one of the first issuer server 110 and the first acquirer server 114 is exhibiting the downtime.
In another example, based on the determined uptime/downtime of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116, the application server 118 may determine that the first issuer server 110 and the first acquirer server 114 are exhibiting the downtime. The application server 118 may further determine that the second issuer server 112 and the second acquirer server 114 and 116 are up and running at the current time instance. Thus, the application server 110 discards all those identified network routes that include the first issuer server 110 and the first acquirer server 114. Thus, the application server 118 may here select the only remaining network route formed by the second issuer server 112 and the second acquirer server 116 that are currently available. In other words, the application server 118 selects, from the plurality of network routes, an alternate network route that is different from the default network route for processing the UPI transaction the determination that at least one of the first issuer server 110 and the first acquirer server 114 is exhibiting the downtime.
In another example, based on the determined uptime/downtime of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116, the application server 118 may determine that the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 are exhibiting the uptime. Further, based on the determined set of operational parameters, the application server 118 may determine that the first acquirer server 114 has a lower response time and a higher processing speed than the second acquirer server 116 and the second issuer server 112 has a lower response time and a higher processing speed than the first issuer server 110. In such a scenario, the application server 118 may select the network route formed by the issuer-acquirer pair with best performance, i.e., the network route including the second issuer server 112 and the first acquirer server 114. In other words, the application server 118 selects, from the plurality of network routes, an alternate network route that is different from the default network route for processing the UPI transaction based on the determined set of operational parameters.
In a non-limiting example, it is assumed that the application server 118 selects an alternate network route including the second issuer server 112 and the second acquirer server 116 for processing the UPI transaction. Based on the selection of the alternate network route including the second issuer server 112 and the second acquirer server 116, the application server 118 may communicate a transaction amount request to the payer device 104 (as shown by arrow 320). The transaction amount request may be indicative of the selection of the second issuer server 112 for the UPI transaction. In other words, by way of the transaction amount request, the application server 118 may notify the payer 102 that the payer payment account B that is maintained at the second issuer server 112 is selected for the UPI transaction. In one embodiment, if the selected payer payment account B is not set as default, the application server 118 may require a consent of the payer 102 for executing the UPI transaction from the payer payment account B. However, if the payer payment account B is set as default, the application server 118 may not require the consent of the payer 102 for executing the UPI transaction from the payer payment account B.
The payer device 104 may receive the transaction amount request, and prompt the payer 102 to enter transaction amount for the UPI transaction. Based on the prompting, the transaction amount (for example, $500) may be entered by the payer 102 on the payer device 104 (as shown by arrow 322). The payer device 104 may communicate the information pertaining to the transaction amount to the application server 118 (as shown by arrow 324). The application server 118 may receive the transaction amount information and process the UPI transaction (as shown by arrow 326). For processing the UPI transaction, the application server 118 may communicate a funds transfer request to the second issuer server 112 that is a part of the selected network route (as shown by arrow 328). The funds transfer request may include the details of the payer payment account B and the payee payment account D, the transaction amount, and an acquirer identifier of the second acquirer server 116 which is a part of the selected network route.
With reference to FIG. 3C, the second issuer server 112 may receive the funds transfer request and generate a request to obtain an authentication code (e.g., IPIN) associated with the payer payment account B. The second issuer server 112 may communicate the request for authentication code to the application server 118 (as shown by arrow 330a). The application server 118 may communicate the request for authentication code to the payer device 104 (as shown by arrow 330b). The payer device 104 may receive the request for authentication code and prompt the payer 102 to provide the authentication code associated with the payer payment account B. Based on the prompting, the authentication code may be entered on the payer device 104 by the payer 102 (as shown by arrow 332). Upon receiving the authentication code, the payer device 104 may communicate the authentication code to the application server 118 (as shown by arrow 334a). The application server 118 may then communicate the authentication code to the second issuer server 112 (as shown by the arrow 334b). The second issuer server 112 may receive the authentication code and authenticate the payer 102 (as shown by arrow 336). The payer 102 is successfully authenticated when the second issuer server 112 determines that the authentication code provided by the payer 102 is correct. Based on the authentication of the payer 102, the second issuer server 112 may authorize the UPI transaction if the payer payment account B has sufficient funds to cover the transaction amount (e.g., $500). In a non-limiting example, it is assumed that the second issuer server 112 authorizes the UPI transaction (as shown by arrow 338).
The second issuer server 112 may then initiate real-time transaction settlement process with the second acquirer server 116 for the UPI transaction (as shown by arrow 340). During the transaction settlement, the second issuer server 112 debits the transaction amount from the payer payment account B and the second acquirer server 116 credits the transaction amount to the payee payment account D. When the UPI transaction is complete, the second issuer server 112 communicates a transaction response to the application server 118 to indicate success of the UPI transaction (as shown by arrow 342a) and the application server 118 communicates the transaction response to the payer device 104 (as shown by arrow 342b). Based on the received transaction response, the payer device 104 may display a message ‘Transaction Successful’ to notify the payer 102 that the UPI transaction is successful (as shown by arrow 344). In an embodiment, the application server 118 may further communicate a message to the payee device 108 to notify the payee 106 regarding the credit of the transaction amount in the payee payment account D.
It will be apparent to a person of ordinary skill in the art that the selection of the network route including the second issuer server 112 and the second acquirer server 116 is shown for exemplary purposes. In an actual implementation, the application server 118 may select any network route based on the determination of the set of operational parameters and the uptime/downtime.
In another embodiment, the application server 118 may determine that both the first and second acquirer servers 114 and 116 are down at the time when the payer 102 wants to perform the UPI transaction. In such a scenario, the application server 118 may not process the UPI transaction and communicate a notification to the payer device 104 to notify the payer 102 that the UPI transaction is not processed. By performing the preliminary check before processing the UPI transaction, the application server 118 prevents transaction failure with the transaction amount being deducted from the default payer payment account A, thereby saving the payer 102 from an immediate shortage of funds.
In another embodiment, the transaction amount may be specified by the payer 102 at the time of initiating the transaction request for the UPI transaction. In such a scenario, after the selection of the alternate network route, the application server 118 may request a consent from the payer 102 for the UPI transaction instead of requesting the transaction amount information.
In an embodiment, the application server 118 may offer the preliminary check service for all UPI transaction requests by default. In another embodiment, the preliminary check service may be activated only upon the consent of payers. In such a scenario, UPI transaction requests of those payers (e.g., the payer 102) who have activated the preliminary check service may include a preliminary check flag that is set. Based on the value (e.g., ‘1’ or ‘true’) of the preliminary check flag, the application server 118 performs the preliminary check service. Thus, for regular UPI transaction requests in which the preliminary check flag is not set (i.e. ‘0’ or ‘false’), the application server 118 may automatically process the UPI transaction through default payer and payee payment accounts.
In another embodiment, when the selected payee payment account D for the UPI transaction is not a default payment account of the payee 106, the application server 118 may be configured to seek an approval or consent from the payee 106 to use the payee payment account D for the UPI transaction. In an exemplary scenario, if the payee 106 does not approve the use of the payee payment account D for the UPI transaction, the application server 118 may not process the UPI transaction and may notify the payer 102 to perform the UPI transaction after some time when the first acquirer server 114 is up and running. Thus, instead of the UPI transaction getting failed with the transaction amount being deducted from the second payer payment account B, the application server 118 does not process the UPI transaction and notifies the payer 102.
FIGS. 4A, 4B, and 4C, collectively represent a process flow diagram 400 that illustrates facilitation of a UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with another exemplary embodiment of the present disclosure. In a non-limiting example, it is assumed that the UPI transaction service is already activated on the payer payment accounts A and B and the payee payment accounts C and D. Activation of the UPI service is described in the foregoing description of FIGS. 2A and 2B. Further, in a non-limiting example, the payer payment account A and the payee payment account C may be designated as default payment accounts for the UPI transactions.
With reference to FIG. 4A, the payer device 104 may be utilized by the payer 102 to access the service application 122 (as shown by arrow 402). For example, when the service application 122 is opened on the payer device 104, the payer device 104 may prompt the payer 102 to provide the login ID and the password for accessing the service application 122. When the login ID and the password provided by the payer 102 are correct, the payer device 104 may grant the payer 102 an access to the service application 122.
Upon the grant of access, the GUI of the service application 122 may be rendered on the display of the payer device 104 for displaying various payment options to the payer 102 for selection (as shown by arrow 404). Examples of the displayed payment options may include UPI, credit card, debit card, or the like. The payer device 104 may prompt the payer 102 to select one of the payment options displayed on the GUI for initiating a transaction. The payer 102 may want to perform the UPI transaction with the payee 106, and hence, the UPI option is selected by the payer 102 (as shown by arrow 406). In an embodiment, when the UPI option is selected, a preliminary check option may be activated on the GUI of the service application 122. The preliminary check option may enable the payer 102 to perform an explicit check on the operational parameters of various transacting servers that will be involved in the UPI transaction, before actual initiation of the UPI transaction.
In a non-limiting example, it is assumed that the preliminary check option is selected by the payer 102 (as shown by arrow 406). The payer device 104 may then prompt the payer 102 to submit the payer account identifier and the payee account identifier of the payee 106. The payer and payee account identifiers are inputted by the payer 102 on the payer device 104 (as shown by arrow 408). When the payer device 104 receives the payer and payee account identifiers, the payer device 104 may communicate a preliminary check request to the application server 118 (as shown by arrow 410). The preliminary check request may include the payer and payee account identifiers.
The application server 118 may receive the preliminary check request and extract (or obtain) the payer and payee account identifiers from the preliminary check request. The application server 118 may then access the database to determine whether the payer and payee account identifiers are stored in the database. In a non-limiting example, it is assumed that the application server 118 determines that the payer and payee account identifiers are stored in the database. The application server 118 may then retrieve various payer payment accounts (e.g., the payer payment accounts A and B) that are associated with the payer account identifier and various payee payment accounts (e.g., the payee payment accounts C and D) that are associated with the payee account identifier (as shown by arrow 412). The application server 118 may then identify various issuers that maintain the payer payment accounts A and B and identify various acquirers that maintain the payee payment accounts C and D. In other words, based on the payer payment accounts A and B, the application server 118 identifies the first and second issuer servers 110 and 112 that maintain the payer payment accounts A and B, respectively. Further, based on the retrieved payee payment accounts C and D, the application server 118 identifies the first and second acquirer servers 114 and 116 that maintain the payee payment accounts C and D, respectively.
The application server 118 may then identify a plurality of network routes (hereinafter, interchangeably referred to as “the network routes”) between the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown by arrow 414). Each of the identified network routes include a different issuer-acquirer server pair from the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116. The identified plurality of network routes include the default network route formed by the first issuer server 110 that maintain the default payer payment account A and the first acquirer server 114 that maintain the default payee payment account C. The identified plurality of network routes further include other network routes formed by the first issuer server 110 and the second acquirer server 116 pair, the second issuer server 112 and the first acquirer server 114 pair, and the second issuer server 112 and the second acquirer server 116 pair.
With reference to FIG. 4B, the application server 118 may be further configured to determine the set of operational parameters (such as the processing speed, the response time, or the like) and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown by arrow 416). By determining the set of operational parameters and the uptime/downtime, the application server 118 checks the availability and the performance of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 for processing the UPI transaction. The processes of determining the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 are described in detail in conjunction with FIGS. 5A and 5B.
The application server 118 may then select one of the plurality of network routes for the UPI transaction (as shown by arrow 418). The selection of one of the plurality of network routes is based on the determination of the set of operational parameters and/or the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as described in the foregoing description of FIG. 4B).
In a non-limiting example, it is assumed that the application server 118 selects an alternate network route including the second issuer server 112 and the second acquirer server 116 for the UPI transaction based on the determined set of operational parameters and/or the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116. Based on the selection of the alternate network route, the application server 118 may communicate a recommendation message to the payer device 104 to recommend the alternate network route to the payer 102 for the UPI transaction (as shown by arrow 420). The recommendation message may indicate a reason for the selection of the alternate network route including the second issuer server 112 instead of the default network route including the first issuer server 110 for the UPI transaction. In other words, by way of the recommendation message, the application server 118 may recommend the payer 102 to perform the UPI transaction from the payer payment account B instead of the default payer payment account A due to the downtime of the first issuer server 110 and/or higher processing speed and lower response time of the second issuer server 112. However, if the first issuer server 110 is up and running and exhibits higher processing speed and lower response time than the second issuer server 112, the recommendation message may recommend the payer 102 to perform the UPI transaction from the default payer payment account A. In a non-limiting example, it is assumed that the recommendation message recommends the payer 102 to perform the UPI transaction from the payer payment account B instead of the payer payment account A.
The payer device 104 may receive the recommendation message, and prompt the payer 102 to select the recommended network route to continue the UPI transaction. In an embodiment, the payer 102 may decline the recommended network route and may chose not to perform the UPI transaction at the current time instance due to the downtime of the first issuer server 110. In another embodiment, the payer 102 may accept the recommendation message and may select the recommended network route to perform the UPI transaction (as shown by arrow 422). Based on the selection, the payer device 104 may prompt the payer 102 to enter a transaction amount for the UPI transaction. Based on the prompting, the payer 102 may enter the transaction amount on the payer device 104 (as shown by arrow 424). The payer device 104 may communicate a transaction request indicating the selection of the recommended network route and the transaction amount to the application server 118 (as shown by arrow 426). The application server 118 may receive the transaction request and process the UPI transaction (as shown by arrow 428). For processing the UPI transaction, the application server 118 may communicate a funds transfer request to the second issuer server 112 that is a part of the recommended network route (as shown by arrow 430). The funds transfer request may include the details of the payer payment account B and the payee payment account D, the transaction amount, and the acquirer identifier of the second acquirer server 116 which is a part of the recommended network route.
With reference to FIG. 4C, the second issuer server 112 may receive the funds transfer request and generate a request to obtain an authentication code (e.g., IPIN) associated with the payer payment account B. The second issuer server 112 may communicate the request for authentication code to the application server 118 (as shown by arrow 432a). The application server 118 may communicate the request for authentication code to the payer device 104 (as shown by arrow 432b). The payer device 104 may receive the request for authentication code and prompt the payer 102 to provide the authentication code associated with the payer payment account B. Based on the prompting, the authentication code may be entered on the payer device 104 by the payer 102 (as shown by arrow 434). Upon receiving the authentication code, the payer device 104 may communicate the authentication code to the application server 118 (as shown by arrow 436a). The application server 118 may then communicate the authentication code to the second issuer server 112 (as shown by the arrow 436b). The second issuer server 112 may receive the authentication code and authenticate the payer 102 (as shown by arrow 438). The payer 102 is successfully authenticated when the second issuer server 112 determines that the authentication code provided by the payer 102 is correct. Based on the authentication of the payer 102, the second issuer server 112 may authorize the UPI transaction if the payer payment account B has sufficient funds to cover the transaction amount (e.g., $500). In a non-limiting example, it is assumed that the second issuer server 112 authorizes the UPI transactions (shown by arrow 440).
The second issuer server 112 may then initiate real-time transaction settlement process with the second acquirer server 116 for the UPI transaction (as shown by arrow 442). During the transaction settlement, the second issuer server 112 may debit or deduct the transaction amount from the payer payment account B and the second acquirer server 116 may credit the transaction amount to the payee payment account D. When the UPI transaction is complete, the second issuer server 112 communicates a transaction response to the application server 118 to indicate a success of the UPI transaction (as shown by arrow 444a) and the application server 118 communicates the transaction response to the payer device 104 (as shown by arrow 444b). Based on the received transaction response, the payer device 104 may display a message ‘Transaction Successful’ to notify the payer 102 that the UPI transaction is successful (as shown by arrow 446). In an embodiment, the application server 118 may further communicate a message to the payee device 108 to notify the payee 106 regarding the credit of the transaction amount in the payee payment account D.
It will be apparent to a person of ordinary skill in the art that the selection of the network route including the second issuer server 112 and the second acquirer server 116 is shown for exemplary purposes. In an actual implementation, the application server 118 may select any network route based on the determination of the set of operational parameters and the uptime/downtime.
FIG. 5A is a process flow diagram 500A that illustrates an exemplary process for determining the set of operational parameters and the uptime/downtime for the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, in accordance with an exemplary embodiment of the present disclosure. FIG. 5A is described in conjunction with FIGS. 3A-3C and 4A-4C. After the identification of the plurality of network routes, the application server 118 determines the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown in arrow 316 in FIG. 3B and arrow 416 in FIG. 4B).
For determining the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116, the application server 118 may generate and communicate test requests to each of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 (as shown by arrows 502, 404, 506, and 508). A test request is a dummy request (e.g., a zero funds transfer request) communicated by the application server 118 to an issuer server or an acquirer server to determine the corresponding set of operational parameters and the corresponding uptime/downtime. Each communicated test request may include a unique transaction identifier and a first timestamp to indicate a time instance at which the test request is communicated to the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116. The application server 118 may be configured to maintain a record that indicates the unique identifiers and the first timestamps of all communicated test requests.
When an issuer server or an acquirer server is up and running, the corresponding issuer server or the acquirer server receives the communicated test request. However, if an issuer server or an acquirer server is exhibiting the downtime, the corresponding issuer server or the acquirer server may not receive the communicated test request. Further, although the test request may be communicated to each of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 at the same time, the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 may receive corresponding test requests at different time instances based on the network traffic or congestion on the communication network 120.
Upon receiving the test request, issuer and acquirer servers may communicate acknowledgements to the application server 118. In a non-limiting example, it is assumed that the first issuer server 110 and the first acquirer server 114 are exhibiting downtime (as shown in FIG. 5A). Thus, from the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, only the second issuer server 112 and the second acquirer server 116 receive the test requests and communicate the acknowledgements to the application server 118 (as shown by arrows 510 and 512). Thus, the application server 118 may not receive any acknowledgement from the first issuer server 110 and the first acquirer server 114 (i.e., the first issuer server 110 and the first acquirer server 114 are unresponsive to the test requests) due to the downtime. Each acknowledgement may include the unique identifier of the corresponding test request. Upon receiving the acknowledgements from the second issuer server 112 and the second acquirer server 116, the application server 118 may be configured to associate a second timestamp with each received acknowledgement. The second timestamp may indicate a time instance at which the acknowledgement is received by the application server 118. The application server 118 may determine the set of operational parameters and uptime/downtime for the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 (as shown by arrow 514). The set of operational parameters and the uptime/downtime may be determined based on the received acknowledgements.
Since the application server 118 received the acknowledgements from only the second issuer server 112 and the second acquirer server 116, the application server 118 may determine that the second issuer server 112 and the second acquirer server 116 are having the uptime whereas the first issuer server 110 and the first acquirer server 114 are exhibiting the downtime. The application server 118 may then determine the response time associated with each received acknowledgement. Response time associated with an acknowledgement may refer to a time duration between the communication of a corresponding test request and the reception of the acknowledgement. The application server 118 may determine the response time associated with each received acknowledgement based on the first and second timestamps. For example, based on the unique identifier associated with the acknowledgement of the second issuer server 112, the application server 118 may look-up the maintained record to retrieve the corresponding first timestamp. The response time of the second issuer server 112 may be a difference between the second timestamp associated with the acknowledgment from the second issuer server 112 and the first timestamp associated with the test request communicated to the second issuer server 112. The response time associated with each received acknowledgement may indicate a transaction processing time of the corresponding second issuer server 112 and the corresponding second acquirer server 116. In one embodiment, the application server 118 may determine the processing speeds of the second issuer server 112 and the second acquirer server 116 as a function of the response time. For example, a high response time indicates a low processing speed and a low response time indicates a high processing speed. In an embodiment, since no acknowledgements are received from the first issuer server 110 and the first acquirer server 114, the application server 118 may determine the response time for the first issuer server 110 and the first acquirer server 114 to be greater than a session time-out period.
The application server 118 may be further configured to rank the plurality of network routes in an order (e.g., an ascending order or descending order) based on the determined set of operational parameters and the determined uptime/downtime (as shown by arrow 516). For example, the application server 118 may rank the network route including the second issuer server 112 and the second acquirer server 116 higher than any other network route due to the downtime of the first issuer server 110 and the first acquirer server 114. In other words, the other network routes that include any of the first issuer server 110 or the first acquirer server 114 are determined to be out-of- operation due to the downtime of the first issuer server 110 and the first acquirer server 114, and hence are ranked lowest by the application server 118.
The application server 118 may then select the highest ranked network route among the plurality of network routes. For example, the application server 118 selects the network route including the second issuer server 112 and the second acquirer server 116 (as shown by arrows 318 in FIG. 3B and 418 in FIG. 4B).
FIG. 5B is a process flow diagram 500B that illustrates an exemplary process for determining the set of operational parameters and the uptime/downtime for the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, in accordance with another exemplary embodiment of the present disclosure. FIG. 5B is described in conjunction with FIGS. 3A-3C and 4A-4C. After the identification of the plurality of network routes, the application server 118 determines the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116 (as shown in arrow 316 in FIG. 3B and arrow 416 in FIG. 4B).
For determining the set of operational parameters and the uptime/downtime for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116, the application server 118 may generate and communicate test requests to each of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 (as shown by arrows 518, 520, 522, and 524). Each communicated test request may include a unique transaction identifier and the first timestamp to indicate a time instance at which the test request is communicated to the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116. The application server 118 may update the record to include the unique identifiers and the first timestamps of the communicated test requests.
In a non-limiting example, it is assumed that the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 are having uptime, and hence the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 receive the corresponding test requests. In response to the received test requests, the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 communicate the acknowledgements to the application server 118 (as shown by arrows 526, 528, 530, and 532). Each acknowledgement may include the unique identifier of the corresponding test request. Upon receiving the acknowledgements from the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, the application server 118 may be configured to associate the second timestamp with each received acknowledgement. The second timestamp may indicate a time instance at which the acknowledgement is received by the application server 118.
The application server 118 may further determine the set of operational parameters and the uptime/downtime for the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 based on the received acknowledgements (as shown by arrow 534). Since the application server 118 received the acknowledgements from the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, the application server 118 may determine that the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 are up and running and available. The application server 118 may then determine the response time associated with each received acknowledgement. The application server 118 may determine the response time associated with each received acknowledgement based on the first and second timestamps. The response time of the first issuer server 110 may be a difference between the second timestamp associated with the acknowledgment from the first issuer server 110 and the first timestamp associated with the test request communicated to the first issuer server 110. The response time associated with each received acknowledgement may indicate a transaction processing time of the corresponding first and second issuer servers 110 and 112 and the corresponding first and second acquirer servers 114 and 116. In one embodiment, the application server 118 may determine the processing speeds of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116 as a function of the response time. For example, a high response time indicates a low processing speed and a low response time indicates a high processing speed.
The application server 118 may be further configured to rank the plurality of network routes in an order (e.g., an ascending order or descending order) based on the determined set of operational parameters and the determined uptime/downtime (as shown by arrow 536). In one example, the second issuer server 112 may be determined to have lower response time than the first issuer server 110 and the second acquirer server 116 may be determined to have a lower response time that the first acquirer server 114. In such a scenario, the application server 118 may rank the plurality of network routes based on the cumulative response time of each network route. The cumulative response time may be a sum of response times of both issuer and acquirer servers included in a network route. Thus, the application server 118 may rank the network route including the second issuer server 112 and the second acquirer server 116 highest due to lowest cumulative response time. Similarly, the application server 118 may rank the remaining network routes.
The application server 118 may then select the highest ranked network route among the plurality of network routes. For example, the application server 118 selects the network route including the second issuer server 112 and the second acquirer server 116 (as shown by arrows 318 in FIG. 3B and 418 in FIG. 4B).
FIG. 6 is a block diagram that illustrates the application server 118, in accordance with an exemplary embodiment of the present disclosure. The application server 118 includes processing circuitry 602, a memory 604, and a network interface 606. The processing circuitry 602, the memory 604, and the network interface 606 communicates with each other by way of a communication bus 608. The processing circuitry 602 includes a preliminary check engine 610, a selection engine 612, and a UPI transaction processing engine 614.
The processing circuitry 602 may include suitable logic, circuitry, interfaces, and/or code, executed by the circuitry, that may be configured to perform one or more transaction processing operations for facilitating UPI payment transactions. Examples of the processing circuitry 602 may include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), a central processing unit (CPU), or a microprocessor. The processing circuitry 602 may execute various transaction processing operations by way of the preliminary check engine 610, the selection engine 612, and the UPI transaction processing engine 614.
The memory 604 may include suitable logic, circuitry, and/or interfaces to store various instructions or code which when executed by the processing circuitry 602 causes the processing circuitry 602 to perform the transaction processing operations. The memory 604 may further store the database (hereinafter, referred to and designated as “the database 616”) that includes the details of various payment accounts on which UPI service is activated and corresponding identifiers. For example, the database 616 stores the details of the payer payment accounts A and B associated with the payer account identifier and the details of the payee payment accounts C and D associated with the payee account identifier (as described in the foregoing description of FIGS. 2A and 2B). In one embodiment, the database 616 may further indicate whether the preliminary check service is activated or deactivated for a payer or a payee account identifier. For example, when the preliminary check service is activated by the payer 102, the database 616 may indicate that for the payer account identifier of the payer 102, the preliminary check service is active. Examples of the memory 604 may include a random-access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), a removable storage drive, a hard disk drive (HDD), a flash memory, a solid-state memory, or the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 604 in the application server 118, as described herein. In another embodiment, the memory 604 may be realized in form of a database server or a cloud storage working in conjunction with the application server 118, without departing from the scope of the disclosure.
The network interface 606 includes suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to transmit and receive data over the communication network 120 using one or more communication network protocols. The network interface 606 transmits requests and messages to and receives requests and messages from the payer and payee devices 104 and 108, the first and second issuer servers 110 and 112, and the first and second acquirer servers 114 and 116 (as described in the foregoing description of FIGS. 1-5B). Examples of the network interface 606 may include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, a USB port, or any other device configured to transmit and receive data.
The preliminary check engine 610 may be configured to perform one or more operations for executing the preliminary check service for UPI transactions. For example, the preliminary check engine 610 may be configured to refer to the database 616 for identifying various issuer servers and acquirer servers corresponding to a UPI transaction request or a preliminary check request received by the application server 118. The preliminary check engine 610 may be further configured to identify the plurality of network routes (as described in the foregoing description of FIGS. 3A and 4B). The preliminary check engine 610 may be configured to generate and communicate test requests to the identified issuer and acquirer servers (as described in the foregoing description of FIGS. 5A and 5B). In an embodiment, the preliminary check engine 610 may include the first timestamp and a unique transaction identifier in each test request. The preliminary check engine 610 may be further configured to receive the acknowledgements in response to the communicated test requests. Each acknowledgement may be linked with the same identifier as of the corresponding test request. Upon receiving each acknowledgement, the preliminary check engine 610 may associate the second timestamp with each acknowledgement. The preliminary check engine 610 may be further configured to determine the set of operational parameters and the uptime/downtime for the identified issuer and acquirer servers based on the received acknowledgements. For example, if no acknowledgement is received from an issuer or acquirer server, the preliminary check engine 610 determines the corresponding issuer or acquirer server to be down and unavailable. The preliminary check engine 610 may then determine the response time for each acknowledgement based on the corresponding first and second timestamps as described in the foregoing description of FIGS. 5A and 5B. In an embodiment, the preliminary check engine 610 may execute the preliminary check when the preliminary check option is selected by the payer 102 or the preliminary check flag is set in the transaction request.
The network route selection engine 612 may be configured to select an optimal network route including an optimal issuer-acquirer pair for each UPI transaction based on the determination of the set of operational parameters and the uptime/downtime for the associated issuer and acquirer servers. For example, as described in the foregoing description of FIG. 3A-3C, the network route selection engine 612 selects the network route including the second issuer server 112 and the second acquirer server 116 for the UPI transaction between the payer 102 and the payee 106. The network route selection engine 612 may be further configured to recommend the selected network route to the payer 102.
The UPI transaction processing engine 614 may be configured to process the UPI transaction based on the selected network route, upon the consent of the payer 102 and the payee 106. For example, as described in the foregoing description of FIG. 3C and 4C, the UPI transaction processing engine 614 generates and communicates the funds transfer request to the second issuer server 112, which is a part of the selected network route, for processing the UPI transaction between the payer 102 and the payee 106.
FIG. 7 is a block diagram that illustrates a system architecture of a computer system 700, in accordance with an embodiment of the present disclosure. An embodiment of present disclosure, or portions thereof, may be implemented as computer readable code on the computer system 700. In one example, the payer and payee devices 104 and 108, the first and second issuer servers 110 and 112, the first and second acquirer servers 114 and 116, and the application server 118 may be implemented as the computer system 700. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of FIGS. 8A-8B, 9A-9B, 10, 11, and 12.
The computer system 700 includes a CPU 702 that may be a special-purpose or a general-purpose processing device. The CPU 702 may be a single processor, multiple processors, or combinations thereof. The CPU 702 may have one or more processor cores. In one example, the CPU 702 is an octa-core processor. Further, the CPU 702 may be connected to a communication infrastructure 704, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 700 may further include a main memory 706 and a secondary memory 708. Examples of the main memory 706 may include RAM, ROM, and the like. The secondary memory 708 may include a hard disk drive or a removable storage drive, such as a floppy disk drive, a magnetic tape drive, a compact disc, an optical disk drive, a flash memory, and the like.
The computer system 700 further includes an input/output (I/O) interface 710 and a communication interface 712. The I/O interface 710 includes various input and output devices that are configured to communicate with the CPU 702. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 712 may be configured to allow data to be transferred between the computer system 700 and various devices that are communicatively coupled to the computer system 700. Examples of the communication interface 712 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 712 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art.
FIGS. 8A and 8B, collectively represent a flowchart 800 that illustrates a method (or process) for facilitating a UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with an exemplary embodiment of the present disclosure.
With reference to FIG. 8A, at step 802, the transaction request including the payer and payee account identifiers is received by the application server 118 from the payer device 104. At step 804, the one or more payer and payee payment accounts associated with the respective payer and payee account identifiers are retrieved from the database 616 by the application server 118. The application server 118 further identifies the one or more issuer and acquirer servers (e.g., the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116) maintaining the identified one or more payer and payee payment accounts, respectively.
At step 806, the plurality of network routes between the identified one or more issuer and acquirer servers 110, 112, 114, and 116 are identified by the application server 118. The plurality of network routes include the default network route and other alternate network routes. At step 808, the set of operational parameters and the uptime/downtime are determined by the application server 118 for each of the identified issuer and acquirer servers 110, 112, 114, and 116. The set of operational parameters includes at least one of the processing speed and the response time. The determination of the set of operational parameters and the uptime/downtime is performed by communicating test requests to the identified issuer and acquirer servers 110, 112, 114, and 116.
At step 810, from the plurality of network routes, an alternate network route that is different from the default network route, is selected by the application server 118 for processing the transaction. The selection of the alternate network route is based on the determined set of operational parameters and the determination that at least one of the default first issuer server 110 and the default first acquirer server 114 is exhibiting the downtime. At step 812, the transaction amount request is communicated to the payer device 104 by the application server 118. At step 814, the transaction amount response is received by the application server 118 from the payer device 104.
With reference to FIG. 8B, at step 816, the transaction between the payer 102 and the payee 106 is processed by the application server 118. At step 818, a funds transfer request is communicated by the application server 118 to the selected second issuer server 112. The funds transfer request may include the details of the payer payment account B and the payee payment account D, the transaction amount, and the acquirer identifier of the selected second acquirer server 116. At step 820, the authentication code request is received by the application server 118 from the selected second issuer server 112. At step 822, the authentication code request is communicated by the application server 118 to the payer device 104. At step 824, the authentication code from the payer device 104 is received by the application server 118. At step 826, the authentication code is communicated by the application server 118 to the selected second issuer server 112. At step 828, the transaction response is received by the application server 118 from the selected second issuer server 112. At step 830, the transaction response is communicated by the application server 118 to the payer device 104.
FIGS. 9A and 9B, collectively represent a flowchart 900 that illustrates a method (or a process) for facilitating a UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with another exemplary embodiment of the present disclosure.
With reference to FIG. 9A, at step 902, the preliminary check request including the payer and payee account identifiers is received by the application server 118 from the payer device 104. At step 904, the one or more payer and payee payment accounts associated with the payer and payee account identifiers, respectively, are retrieved from the database 616 by the application server 118. the one or more issuer and acquirer servers (e.g., the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116) maintaining the one or more payer and payee payment accounts, respectively, are identified by the application server 118.
At step 906, the plurality of network routes between the identified one or more issuer and acquirer servers 110, 112, 114, and 116 are identified by the application server 118. The plurality of network routes include the default network route and other alternate network routes. At step 908, the set of operational parameters and the uptime/downtime are determined by the application server 118 for each of the identified issuer and acquirer servers 110, 112, 114, and 116. The set of operational parameters includes at least one of the processing speed and the response time. The determination of the set of operational parameters and the uptime/downtime is performed by communicating test requests to the identified issuer and acquirer servers 110, 112, 114, and 116.
At step 910, from the plurality of network routes, an alternate network route that is different from the default network route, is selected by the application server 118 for the transaction. The selection of the alternate network route is based on the determined set of operational parameters and the determination that at least one of the default first issuer server 110 and the default first acquirer server 114 is exhibiting the downtime. At step 912, a recommendation message is communicated by the application server 118 to recommend the selected alternate network route to the payer 102 for the transaction.
With reference to FIG. 9B, at step 914, the transaction request is received by the application server 118 from the payer device 104. The transaction request may be indicative of the transaction amount and the consent to use the alternate network route for the UPI transaction. At step 916, the UPI transaction between the payer 102 and the payee 106 is processed by the application server 118. At step 918, a funds transfer request is communicated by the application server 118 to the selected second issuer server 112. The funds transfer request may include the details of the payer payment account B and the payee payment account D, the transaction amount, and the acquirer identifier of the second acquirer server 116 that is a part of the selected alternate network route. At step 920, the authentication code request is received by the application server 118 from the selected second issuer server 112. At step 922, the authentication code request is communicated by the application server 118 to the payer device 104. At step 924, the authentication code from the payer device 104 is received by the application server 118. At step 926, the authentication code is communicated by the application server 118 to the selected second issuer server 112. At step 928, the transaction response is received by the application server 118 from the selected second issuer server 112. At step 930, the transaction response is communicated by the application server 118 to the payer device 104.
FIG. 10 is a flowchart 1000 that illustrates a method (or process) for determining the set of operational parameters and the uptime/downtime for the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116, in accordance with an exemplary embodiment of the present disclosure. At step 1002, test requests are communicated by the application server 118 to the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116. At step 1004, acknowledgements in response to the communicated test requests are received by the application server 118 from the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116. At step 1006, the set of operational parameters and the uptime/downtime are determined by the application server 118 based on the received acknowledgements for each of the identified first and second issuer servers 110 and 112 and the identified first and second acquirer servers 114 and 116. At 1008, the plurality of network routes are ranked by the application server 118 in an order based on the determined set of operational parameters and the uptime/downtime. One of the plurality of network routes is selected by the application server 118 based on the ranking.
FIG. 11 is a high-level flowchart 1100 that illustrates a method for facilitating the UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with the exemplary embodiment of the present disclosure. At step 1102, the transaction request including the payer and payee account identifiers is received by the application server 118 from the payer device 104. At step 1104, based on the transaction request, the one or more payer and payee payment accounts associated with the payer and payee account identifiers, respectively, are retrieved from the database 616 by the application server 118. At step 1106, the plurality of network routes between one or more issuer servers and one or more acquirer servers are identified by the application server 118. The one or more issuer servers (e.g., the first and second issuer servers 110 and 112) are associated with the one or more payer payment accounts A and B, and the one or more acquirer servers (e.g., the first and second acquirer servers 114 and 116) are associated with the one or more payee payment accounts C and D. The plurality of network routes include a default network route, formed by the first issuer server 110 and the first acquirer server 114, for the transaction.
At step 1108, the set of operational parameters and the uptime/downtime are determined by the application server 118 for each of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116. At step 1110, from the plurality of network routes, an alternate network route that is different from the default network route is selected by the application server 118 for processing the transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server 110 and the first acquirer server 114 is exhibiting the downtime. At step 1112, the transaction is processed by the application server 118 based on the selected alternate network route.
FIG. 12 is a high-level flowchart 1200 that illustrates a method (or process) for facilitating the UPI transaction between the payer 102 and the payee 106 by the application server 118, in accordance with another exemplary embodiment of the present disclosure. At step 1202, a request (e.g. the preliminary check request) including the payer and payee account identifiers is received by the application server 118 from the payer device 104. At step 1204, based on the received request, the one or more payer and payee payment accounts associated with the payer and payee account identifiers, respectively, are retrieved from the database 616 by the application server 118.
At step 1206, the plurality of network routes between one or more issuer servers and one or more acquirer servers are identified by the application server 118. The one or more issuer servers (e.g., the first and second issuer servers 110 and 112) are associated with the one or more payer payment accounts A and B, and the one or more acquirer servers (e.g., the first and second acquirer servers 114 and 116) are associated with the one or more payee payment accounts C and D. The plurality of network routes include a default network route, formed by the first issuer server 110 and the first acquirer server 114, for the transaction. At step 1208, the set of operational parameters and the uptime/downtime are determined by the application server 118 for each of the first and second issuer servers 110 and 112 and the first and second acquirer servers 114 and 116. At step 1210, from the plurality of network routes, an alternate network route that is different from the default network route is selected by the application server 118 for processing the transaction. The alternate network route is selected based on the determined set of operational parameters or the determination that at least one of the first issuer server 110 and the first acquirer server 114 is exhibiting the downtime. At step 1212, a recommendation message is communicated by the application server 118 to recommend the selected alternate network route to the payer 102 for the UPI transaction.
Technological improvements in the application server 118 enable the application server 118 to offer the ‘Preliminary Check Service’ for UPI transactions. When the ‘Preliminary Check Service’ is activated or offered, instead of processing a UPI transaction from default payer and payee payment accounts, the application server 118 identifies an optimal network route for the UPI transaction. Since the operational parameters (such as processing speed and response time) and the uptime/downtime of various issuer servers (e.g., the first and second issuer servers 110 and 112) and acquirer servers (e.g., the first and second acquirer servers 114 and 116) are determined and analyzed before processing the UPI transaction, a likelihood of the UPI transaction getting failed due to the downtime or slow response of a transacting party is significantly reduced. As a result, the payer 102 and the payee 106 are offered with a better and uninterrupted UPI transaction experience. Beneficially, such transaction experience may result in more individuals opting for UPI transaction service.
Techniques consistent with the present disclosure provide, among other features, systems and methods for facilitating a UPI transaction between a payer and a payee. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the disclosure, without departing from the breadth or scope.
In the claims, the words ‘comprising’, ‘including’ and ‘having’ do not exclude the presence of other elements or steps then those listed in a claim. The terms “a” or “an,” as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
While various embodiments of the present disclosure have been illustrated and described, it will be clear that the present disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present disclosure, as described in the claims.