Claims:A method for mitigating duplicate payments, the method comprising:
receiving, by processing circuitry, a first signal indicating that a first payment request is initiated on a user device using a first payment mode of a plurality of payment modes accessible on the user device for payment of a bill, wherein the first signal is indicative of at least a first identifier of the bill;
verifying, by the processing circuitry, whether the first identifier of the bill is different from one or more second identifiers in a transaction history database, wherein a first record is created in the transaction history database based on the verification that the first identifier of the bill is different from the one or more second identifiers, and wherein the created first record includes information of the first identifier and an indicator of successful payment of the bill;
receiving, by the processing circuitry, a second signal indicating one of (i) reception of a payment reminder on the user device from a second payment mode of the plurality of payment modes for the payment of the bill or (ii) initiation of a second payment request on the user device using the second payment mode for the payment of the bill, wherein the second signal is indicative of at least the first identifier of the bill; and
executing, by the processing circuitry, one of (i) a first action or (ii) a second action when the transaction history database includes the first record that has the first identifier of the bill and the indicator of successful payment of the bill, wherein the first action includes flagging the payment reminder on the user device as duplicate, and wherein the second action includes declining the second payment request.

2. The method of claim 1, further comprising tracking, by the processing circuitry, one or more activities performed using the plurality of payment modes on the user device, wherein the first signal and the second signal are received based on the tracking of the one or more activities.

3. The method of claim 1, wherein the transaction history database includes one or more second records each associated with a different bill and indicating a successful payment of a corresponding bill, and wherein each record of the one or more second records includes information of a unique identifier of the corresponding bill and an indicator of successful payment of the corresponding bill.

4. The method of claim 1, further comprising storing, by the processing circuitry, a consent database that includes one or more consent records associated with the user device, wherein a consent record of the one or more consent records indicates a permission granted to a payment mode of the plurality of payment modes accessible on the user device for payment of one or more bills of a service.

5. The method of claim 1, wherein the first identifier of the bill is compared with the one or more second identifiers in the transaction history database to verify whether the first identifier is different from the one or more second identifiers.

6. The method of claim 1, further comprising hosting, by the processing circuitry, a service application that tracks one or more activities performed using the plurality of payment modes on the user device, wherein the first signal and the second signal are generated by the service application based on the tracking of the one or more activities on the user device.

7. A system to mitigate duplicate payments, the system comprising:
processing circuitry configured to:
receive a first signal indicating that a first payment request is initiated on a user device using a first payment mode of a plurality of payment modes accessible on the user device for payment of a bill, wherein the first signal is indicative of at least a first identifier of the bill;
verify whether the first identifier of the bill is different from one or more second identifiers in a transaction history database, wherein a first record is created in the transaction history database based on the verification that the first identifier of the bill is different from the one or more second identifiers, and wherein the created first record includes information of the first identifier and an indicator of successful payment of the bill;
receive a second signal indicating one of (i) reception of a payment reminder on the user device from a second payment mode of the plurality of payment modes for the payment of the bill or (ii) initiation of a second payment request on the user device using the second payment mode for the payment of the bill, wherein the second signal is indicative of at least the first identifier of the bill; and
execute one of a first action or a second action when the transaction history database includes the first record indicating the first identifier of the bill and the indicator of successful payment of the bill, wherein the first action includes flagging the payment reminder on the user device as duplicate, and wherein the second action includes declining the second payment request.

8. The system of claim 7, further comprising a memory configured to store a consent database. wherein the consent database includes one or more consent records associated with the user device such that each consent record of the one or more consent records indicates a permission granted to a payment mode of the plurality of payment modes accessible on the user device for payment of one or more bills of a service.

9. The system of claim 7, wherein the transaction history database includes one or more second records each associated with a different bill and indicating a successful payment of the corresponding bill such that each record of the one or more second records includes information of a unique identifier of the corresponding bill and an indicator of successful payment of the corresponding bill.

10. A method for mitigating duplicate payments, the method comprising:
maintaining, by processing circuitry, a transaction history database that includes a plurality of records, each indicating a successful payment of a different bill, wherein a first record of the plurality of records includes information of a unique identifier of a corresponding bill and an indicator of successful payment of the corresponding bill;
receiving, by the processing circuitry, a first signal that indicates one of (i) reception of a payment reminder on a user device from one of a plurality of payment modes accessible on the user device, for payment of a bill or (ii) initiation of a payment request on the user device using one of the plurality of payment modes for the payment of the bill, wherein the first signal is indicative of at least a first identifier of the bill; and
executing, by the processing circuitry, one of a first action or a second action when the transaction history database includes the first identifier of the bill and the indicator of successful payment of the bill, wherein the first action includes flagging the payment reminder on the user device as duplicate, and the second action includes declining the payment request.

, Description:BACKGROUND

FIELD OF THE DISCLOSURE
Various embodiments of the present disclosure relate generally to electronic bill payment transactions. More particularly, various embodiments of the present disclosure relate to methods and systems for mitigating duplicate payment transactions.

DESCRIPTION OF THE RELATED ART
Deep penetration and spread of Internet have revolutionized the way users conduct bill payments, for example, credit card bill payments, utility bill payments, or the like. Instead of standing in long queues and waiting for their turn, users make use of various online payment applications (for example, digital wallet applications, unified payment interface applications, or the like) for conducting the bill payments. Many such payment applications have an additional capability of generating bill payment reminders for users. In other words, once a bill has been paid using a payment application by a user, the payment application generates a bill payment reminder to remind the user when the next billing cycle approaches, thus reducing a likelihood of delayed or missed payment.
In an attempt to increase their reach, service providers of these payment applications often give lucrative discounts and offers to users for using their payment applications. As a result, a user is always tempted to switch from one payment application to another payment application depending on ongoing offers and discounts. However, these payment applications once used for payment of a bill, keep a track of the next billing cycle and generate bill payment reminders. Thus, in a scenario, where a user may have used two different payment applications to pay electricity bill for two consecutive months, both the payment applications may automatically generate bill payment reminders for the electricity bill thereafter. In addition, the bill payment reminders may be generated at different time intervals by different payment applications. For example, one payment application may generate a bill payment reminder one week prior to the due date and another payment application may generate a bill payment reminder only three days prior to the due date. Due to these multiple bill payment reminders, a user many a times ends up paying for a bill more than once using different payment applications. Since the operation of these payment applications is independent of each other, no payment application triggers an alert if the user attempts to perform a bill payment for a bill that has already been paid using another payment application. As a result, the user may face various problems, such as shortage of funds, delay in refund, or no refund, which is undesirable.
A known solution to tackle this problem includes retrieving (or fetching) a bill payment status from a service provider by a payment application as and when a user attempts to make a bill payment. However, in certain scenarios, bill payment statuses are not updated in real time and may take days to reflect the actual status. In such scenarios, even if the payment application fetches the bill payment status of the bill from the service provider, there are high chances that a paid bill might be reflected as not paid. Thus, retrieval of the bill payment status from service providers may not be a fool-proof solution to mitigate duplicate bill payments.
In light of the foregoing, there is a need for a technical solution that solves the above-mentioned problems and provides a fool-proof solution to mitigate duplicate bill payments.

SUMMARY

In an embodiment of present disclosure, a method for mitigating duplicate payments is provided. The method may include receiving, by processing circuitry, a first signal indicating that a first payment request is initiated on a user device using a first payment mode of a plurality of payment modes accessible on the user device for payment of a bill. Whether a first identifier of the bill is different from one or more second identifiers in a transaction history database is verified by the processing circuitry. A first record may be created in the transaction history database based on the verification that the first identifier of the bill is different from the one or more second identifiers. The created first record may include information of the first identifier and an indicator of successful payment of the bill. A second signal may be received by the processing circuitry. The second signal may indicate one of (i) reception of a payment reminder on the user device from a second payment mode of the plurality of the payment modes for the payment of the bill or (ii) initiation of a second payment request on the user device using the second payment mode for the payment of the bill. The second signal may be indicative of at least the first identifier of the bill. One of a first action or a second action may be executed by the processing circuitry when the transaction history database includes the first record indicating the first identifier of the bill and the indicator of successful payment of the bill. The first action may include flagging the payment reminder on the user device as a duplicate and the second action may include declining the second payment request.
In another embodiment of the present disclosure, a system to facilitate the mitigation of duplicate payments is provided. The system includes processing circuitry. The processing circuitry may be configured to receive a first signal indicating that a first bill payment request is initiated on a user device using a first payment mode of a plurality of the payment modes accessible on the user device for payment of a bill. The first signal may be indicative of at least a first identifier of the bill. The processing circuitry may be configured to verify whether a first identifier of the bill is different from one or more second identifiers in a transaction history database. A first record may be created in the transaction history database based on the verification that the first identifier of the bill is different from the one or more second identifiers. The created first record may include information of the first identifier and an indicator of successful payment of the bill. The processing circuitry may be further configured to receive a second signal indicating one of (i) reception of a payment reminder on the user device from a second payment mode of the plurality of the payment modes for the payment of the bill or (ii) initiation of a second bill payment request on the user device using the second payment mode for the payment of the bill. The second signal may be indicative of at least the first identifier of the bill. The processing circuitry may be further configured to execute one of a first action or a second action when the transaction history database includes the first record indicating the first identifier of the bill and the indicator of successful payment of the bill. The first action may include flagging the bill payment reminder on the user device as duplicate and the second action may include declining the second bill payment request.
In another embodiment of the present disclosure, a method for mitigating duplicate payments is provided. The method includes maintaining, by processing circuitry, a transaction history database that includes a plurality of records, each indicating a successful payment of a different bill. A first record of the plurality of records may include information of at least a unique identifier of a corresponding bill and an indicator of successful payment of the corresponding bill. A first signal may be received by the processing circuity. The first signal may indicate one of (i) reception of a payment reminder on the user device from one of a plurality of payment modes accessible on the user device for payment of a bill or (ii) initiation of a payment request on the user device using one of the plurality of payment modes for the payment of the bill. The first signal may be indicative of at least a first identifier of the bill. One of a first action or a second action is executed by the processing circuitry when the transaction history database includes the first identifier of the bill and the indicator of successful payment of the bill. The first action may include flagging the payment reminder on the user device as duplicate and the second action may include declining the payment request.

BRIEF DESCRIPTION OF DRAWINGS

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. 1A is a block diagram that illustrates an exemplary environment for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 1B is a block diagram that illustrates an exemplary environment for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure;
FIG. 2 is a block diagram that illustrates an application server of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
FIGS. 3A-3C, collectively, represent a process flow diagram that illustrates an exemplary scenario for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 3D is a block diagram that illustrates a memory of the application server, in accordance with an exemplary embodiment of the present disclosure;
FIG. 4 is a block diagram that illustrates the application server for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure;
FIGS. 5A-5D, collectively, represent a process flow diagram that illustrates another exemplary scenario for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure;
FIG. 6 is a block diagram that illustrates a system architecture of a computer system, in accordance with an exemplary embodiment of the present disclosure;
FIG. 7 represents a high-level flowchart that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure;
FIG. 8 represents a high-level flowchart that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure; and
FIG. 9 represents a flowchart that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with an 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
A user may have provided consent to multiple payment modes (for example, online payment applications) for bill payment (for example, credit card bill payment and utility bill payment). As a result, the user may get bill payment reminders from these payment modes. Since operation of the payment modes is independent of each other, no payment mode triggers an alert if the user attempts to perform a bill payment for a bill that has already been paid using another payment mode, thus resulting in a duplicate payment for the bill. As a result, the user may face various problems such as shortage of funds, delay in refund, or no refund, which is undesirable.
Various embodiments of the present disclosure provide a method and a system that solve the above-mentioned problem by mitigating duplicate payment transactions. The system may include an application server that has processing circuitry and a memory. The processing circuitry may be configured to host a service application executable on user devices. The service application when executed on a user device may be configured to track one or more activities performed using various payment modes accessible on the user device, based a consent provided by a corresponding user. The memory may be configured to store therein a consent database. For each user who has registered with the application server, the consent database may include one or more consent records where each consent record indicates a permission granted by the user to a payment mode accessible on the user device for payment of bills of a service. For example, a user ‘A’ may grant permission (or consent) to two mobile payment applications (e.g., two payment modes) accessible on their user device to pay a credit card bill. In such a scenario, for the user ‘A’, the consent database may include two consent records, where each consent record indicates a permission granted by the user ‘A’ to one of the mobile payment applications for the payment of the credit card bill. New consent records may be created in the consent database based on new consents provided by the user ‘A’ and old consent records may be deleted from the consent database based on revocation of consents by the user ‘A’. A transaction history database maintained at the application server or at an issuer server may be used to keep a track of bill payments performed by various users. When the user ‘A’ initiates a payment request using a first payment mode on the user device for payment of, for example, a credit card bill for a first time, the processing circuitry may receive a first signal from the user device indicating that the payment request is initiated on the user device for the payment of the credit card bill. The first signal may be indicative of one or more details, such as a first identifier, of the credit card bill. Upon receiving the first signal, the processing circuitry may verify whether the first identifier of the credit card bill is different from one or more second identifiers in the transaction history database. Based on the verification that the first identifier of the credit card bill is different from the one or more second identifiers, a first record is created in the transaction history database. The created first record may include information of the first identifier and an indicator of successful payment of the credit card bill. In a scenario, where any other payment mode on the user device generates a payment reminder for the same credit card bill that the user has already paid or when the user initiates another payment request using another payment mode on the user device for the payment of the same credit card bill, the processing circuitry may receive a second signal from the user device. The second signal may include details of the credit card bill for which the payment reminder is generated or for which the duplicate payment request is initiated. The processing circuitry may verify using the transaction history database whether the payment reminder or the payment request is duplicate. Thus, when the transaction history database includes a record indicating the successful payment of the credit card bill and the first identifier of the credit card bill, the processing circuitry may flag the payment reminder on the user device as duplicate or decline the payment request for being duplicate.
Thus, instead of allowing payment of the same bill multiple times, the application server identifies and notifies the user of the duplicity of payment transaction or bill reminders. Since the bill payment reminders are also flagged as duplicate, the application server reduces a likelihood of duplicate payment transactions.
TERM DESCRIPTION (in addition to plain and dictionary meaning)
Payment is a financial transaction that includes exchange of funds between two or more entities. For example, the payment may include transferring an amount from an account of a user to an account of a service provider that offers a service availed by the user. Examples of the service may include utility and non-utility services.
Bill (or invoice) indicates an amount of money that a user owes a service provider for the use service or goods offered by the service provider. In an example, the bill may be a recurring bill statement where the user uses the service on a regular basis. Such bills have a definite billing cycle, where billing cycle refers to an interval of time between two billing statements (e.g., bills). A billing cycle may be of any time duration, for example, a month, two months, or the like. Every bill has a unique identifier, for example, a bill number that changes with every bill statement. The identifier may be a numeric code, an alphabetic code, an alphanumeric code, or a combination or numerals, letters, and special characters.
A payment request refers to a debit request initiated by a user through a payment mode. The payment request is verified/or pre-checked for duplicity before processing.
Transaction history database includes record data of unique payment transactions. In an example, the transaction history database may be a relational database having rows and columns identified by a primary key. The transaction history database may be used to verify duplicate payment transactions.
A payment reminder may refer to a notification generated by a payment mode to remind a user regarding a pending payment. The payment reminder may be rendered via a push notification, an email reminder, an SMS reminder, an in-app notification or the like on a user device.
An application server is a computing server that facilitates mitigation of duplicate payment transactions. The application server may be implemented in hardware or software, or a combination thereof. In one embodiment, the application server may be implemented in computer programs executing on programmable computers, such as personal computers, laptops, or a network of computer systems or user mobile devices.
Payment modes are various modes of online payments. Examples of the payment modes may include third-party applications, digital wallets, credit card payment solutions, Internet Banking applications, unified payment interface (UPI) applications, third-party open-banking applications, or the like.
FIG. 1A is a block diagram that illustrates an exemplary environment for mitigating duplicate bill payments, in accordance with an exemplary embodiment of the present disclosure. With reference to FIG. 1A, an exemplary environment 100A is shown. The exemplary environment 100A includes a service provider server 102, an acquirer server 104, a user device 106 of a user 108, an issuer server 110, a payment network server 112, and an application server 114. The service provider server 102, the acquirer server 104, the user device 106, the issuer server 110, the payment network server 112, and the application server 114 may communicate with each other by way of a communication network 116 or through separate communication channels therebetween.
The service provider server 102 may be a server arrangement which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for executing various billing operations associated with a service (for example, a utility service or a non-utility service) availed by users (e.g., the user 108). Examples of the utility service may include an electricity service, a water supply service, a postpaid phone service, or the like. Examples of the non-utility service may include an internet service, a credit card service, equated monthly installments, monthly loan payments, monthly subscriptions, or the like. Based on corresponding usage of the service by the users, the service provider server 102 may be configured to generate bill statements (e.g., bills or invoices) for the users on every billing cycle (for example, every month, bi-monthly, or the like). Bills generated by the service provider server 102 may be associated with unique identifiers, and indicate billing cycle details such as month, amount to be paid for availing the service in that month, or the like. In an embodiment, the bill may exist in physical form (for example, on a paper) having an optical/or bar code printed on it. In another embodiment, the bill may exist in digital form and communicated to users on their corresponding user devices. Since every bill has a unique identifier, the service provider server 102 may use the bill identifiers as primary identification information for identifying bills and resolving user queries pertaining to bills. For the sake of brevity, it is assumed that the service offered by the service provider server 102 has a monthly billing cycle. In other words, the service provider server 102 may generate and communicate new bills to the users every month.
In order to accept bill payments from the users, a service provider associated with the service provider server 102 may have established a payment account with a financial institution, such as an acquirer, that is a part of a financial payment system. The acquirer server 104 is associated with the acquirer. The acquirer server 104 may be a server arrangement which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing various payment transactions. For example, the acquirer server 104 may be configured to credit the payment account of the service provider based on bill payments made by the users. The acquirer server 104 may be configured to communicate one or more notifications to the service provider server 102 to indicate payment activities (for example, payment credit) related to the payment account. The acquirer server 104 may communicate with the service provider server 102 via the communication network 116. For the sake of brevity, only one acquirer server 104 is shown in FIG. 1A. However, in an actual implementation, there may be multiple service providers of utility and non-utility services having payment accounts maintained at different acquirers, without deviating from the scope of the disclosure.
The user device 106 may refer to a computing device of the user 108. Examples of the user device 106 may include a mobile phone, a laptop, a smartphone, a tablet, a computer, a phablet, a wearable device such as a digital watch, or the like. The user device 106 may include suitable logic, circuitry, interfaces, and/or code to enable the user 108 to perform various payment related activities, such as bills payments of various utility and non-utility services. The user 108 may be required to make bill payments every billing cycle to continue availing the service.
The user device 106 may be configured to run (or execute) various computer executable applications for performing bill payments. For example, the user device 106 may run computer executable applications of a plurality of payment modes, such as first and second payment modes 118a and 118b, using which the user 108 may perform the bill payments. In other words, the plurality of payment modes may be accessible on the user device 106 for performing bill payments. Examples of the first and second payment modes 118a and 118b may include digital wallets, Internet Banking applications, unified payment interface (UPI) applications, third-party open-banking applications, or the like.
In order to perform digital payment transactions using the first and second payment modes 118a and 118b, the user 108 may have established a payment account with a financial institution, such as an issuer, that is a part of the financial payment system. The issuer server 110 is associated with the issuer that maintains the payment account (hereinafter referred to and designated as “the user account 120”) of the user 108. The issuer server 110 may be a server arrangement which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing various payment transactions. For example, the issuer server 110 may be configured to credit and debit the user account 120 based on payment transactions made to and from the user account 120. The issuer server 110 may be configured to communicate one or more notifications to the user device 106 to indicate various payment activities (for example, payment credit, payment debit, or the like) related to the user account 120. Examples of the user account 120 may include a bank account, a digital wallet, or the like. The issuer server 110 may communicate with the user device 106 via the communication network 116.
For the sake of brevity, it is assumed that the user 108 has established one payment account with one issuer. However, in an actual implementation, the user 108 may have established multiple payment accounts with multiple issuers, without deviating from the scope of the disclosure.
The payment network server 112 may be a computing server that is operated by a payment network. The payment network may be an intermediate entity between acquirers (for example, the acquirer associated with the acquirer server 104) and issuers (e.g., an issuer associated with the issuer server 110) for processing transactions. In other words, the acquirer server 104 may communicate with the issuer server 110 through the payment network server 112 to determine whether the user account 120 is in good standing and has sufficient funds and balance to cover an amount of a payment request. Authorization of the payment requests is declined or accepted based on such determinations performed between the issuer server 110 and the acquirer server 104 via the payment network server 112.
Examples of the acquirer server 104, the issuer server 110, and the payment network server 112 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 first and second payment modes 118a and 118b may be linked to the user account 120 to fund payment transactions initiated using the first and second payment modes 118a and 118b. The user 108 may have granted permissions (or consent) to the first and second payment modes 118a and 118b for bill payment. For example, the user 108 may have provided consent to the first payment mode 118a to pay a bill of the service (for example, offered by the service provider server 102) in the month of January 2021. Based on the consent provided by the user 108, the first payment mode 118a may be configured to retrieve bill statements of the user 108 from the service provider server 102 every billing cycle and generate bill payment reminders for the user 108. The user 108 may further provide consent to the second payment mode 118b, without revoking the previous consent provided to the first payment mode 118a, to pay a bill of the service in the month of February 2021. In such a scenario, both the first and second payment modes 118a and 118b may be configured to retrieve bill statements of the user 108 from the service provider server 102 every billing cycle and generate bill payment reminders for the user 108. The user 108 may choose any of the first and second payment modes 118a and 118b accessible on the user device 106 to initiate a payment request for the payment of the bill of the service.
In certain scenarios, a bill payment status of the service may not be updated in real time by the service provider server 102 upon payment of the bill by the user 108. Thus, the other payment mode 118a or 118b that was not chosen by the user 108 for the payment of the bill may still generate a bill payment reminder for the bill payment even though the bill has been paid. Such duplicate payment reminders may cause confusion for the user 108 and the user 108 may end up paying for the same bill again using the other payment mode 118a or 118b.
The application server 114 may be configured to offer a solution to mitigate the problem of duplicate bill payments. The application server 114 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, that perform various operations required for mitigating duplicate payment transactions. For example, the application server 114 may be configured to host a service application 122 executable on various devices (for example, the user device 106). The service application 122, when executed on the user device 106, may function as a gateway between the application server 114 and the user device 106. The service application 122, when executed on the user device 106, may be configured to track one or more activities performed using the plurality of payment modes (e.g., the first and second payment modes 118a and 118b) on the user device 106, based on a consent of the user 108. The service application 122 may further generate one or more signals (for example, application programming interface (API) calls) for the application server 114 to indicate reception of bill payment reminders on the user device 106 from the first and second payment modes 118a and 118b and initiation of bill payment requests on the user device 106 using the first and second payment modes 118a and 118b. The service application 122 may generate the one or more signals based on the tracking of the one or more activities on the user device 106. Based on the received signals, the application server 114 may be configured to execute various actions, such as flagging duplicate payment reminders on the user device 106 and declining duplicate payment requests that are initiated on the user device 106. Various components and operation of the application server 114 are described in detail in FIGS. 2, 3A-3C, 4, and 5A-5D.
Examples of the application server 114 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. Although the application server 114 is shown to be a standalone entity in FIG. 1A, the scope of the disclosure is not limited to it. In another embodiment, the application server 114 may be implemented as a part of the issuer server 110, the acquirer server 104, or the payment network server 112 without deviating from the scope of the disclosure.
The communication network 116 may be a medium through which content and messages are transmitted between the service provider server 102, the acquirer server 104, the user device 106, the issuer server 110, the payment network server 112, the application server 114, and other entities that are pursuant to one or more standards for the interchange of transaction requests, such as the ISO8583 standard. Examples of the communication network 116 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 100A may connect to the communication network 116 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.
In operation, the application server 114 may be configured to host the service application 122. The application server 114 may be configured to execute a registration process (for example, a sign-up process) when the user 108 requests access to the service application 122 for the first time. During the registration process, unique login credentials (for example, a login identifier (id) and a password) are created for the user 108. In addition, during registration, basic profile information, such as name, valid contact information, or the like, is procured from the user 108. Upon successful validation of the profile information, the user 108 may be registered and may be able login to the service application 122 using the login credentials. In the initial set up of the service application 122 on the user device 106, the service application 122 may be configured to seek consent from the user 108 to access the first and second payment modes 118a and 118 accessible on the user device 106. In an example, the service application 122 may seek a read-only access to track various consent related activities and payment related activities on the first and second payment modes 118a and 118b. When the consent is provided by the user 108, the service application 122 may be configured to read consent information pertaining to the first and second payment modes 118a and 118b. The consent information read by the service application 122 may include details of various bill payment consents provided by the user 108 to the first and second payment modes 118a and 118b. For example, the user 108 may have provided a consent to the first payment mode 118a to pay monthly bills of a service using the user account 120. In such an example, the consent information pertaining to the first payment mode 118a may include details of the first payment mode 118a, the service, and the user account 120. Similarly, the user 108 may have further provided a consent to the second payment mode 118b to pay monthly bills of the same service using the user account 120. In such a scenario, the consent information pertaining to the second payment mode 118b may include details of the second payment mode 118b, the service, and the user account 120.
The service application 122 running on the user device 106 may be configured to communicate the consent information of the first and second payment modes 118a and 118 to the application server 114 via an API call to the application server 114. The application server 114 may be configured to store the received consent information as one or more consent records in a consent database (as shown in FIGS. 2 and 3B). The consent database may include consent records associated with the user device 106 and other user devices. A consent record in the consent database may indicate a permission (or consent) granted to a payment mode (e.g., the first or second payment mode 118a or 118b) of a plurality of payment modes accessible on a user device (e.g., the user device 106) for payment of bills of the service. In an embodiment, the consent database may further include a consent record pertaining to a consent provided by the user 108 to the service application 122 for accessing the first and second payment modes 118a and 118b. In a scenario, where the user 108 grants a new consent to any of the first and second payment modes 118a and 118b or revokes any previous consents of the first and second payment modes 118a and 118b, the service application 122 may communicate updated consent information to the application server 114 via an API call. Subsequently, the application server 114 may update the consent database based on the updated consent information.The service application 122 may be further configured to track the activities performed using the first and second payment modes 118a and 118b on the user device 106. For example, the user 108 may initiate a first payment request on the user device 106 using the first payment mode 118a for payment of a bill of the service. The service application 122 may generate a signal (e.g., an API call) indicating that the first payment request is initiated on the user device using the first payment mode 118a and communicate the generated signal to the application server 114. The generated signal may be indicative of information such as a first identifier of the bill, an amount of the bill, and the first payment mode 118a used for initiating the first payment request. The application server 114 may be configured to verify whether the bill associated with the first payment request is already paid or not. For such verification, the application server 114 may query a transaction history database (as shown in FIGS. 2, 3D, and 4) that includes details of various bill payment transactions made on the user device 106. The application server 114 may be configured to compare the first identifier of the bill with one or more second identifiers in the transaction history database. In a scenario, where the transaction history database does not include any record of the first identifier, the application server 114 establishes that the first payment request is not duplicate and the first payment request is processed successfully. Upon successful processing of the first payment and the verification of the first payment request, a first record may be created in the transaction history database such that the first record includes information of the first identifier and an indicator of successful payment of the bill.
If the service application 122 detects reception of a payment reminder on the user device 106 from any of the first and second payment modes 118a and 118b for the payment of the same bill or initiation of a new payment request on the user device 106 using any of the first and second payment modes 118a and 118b for the payment of the same bill, the service application 122 may generate and communicate another signal (for example, API call) to the application server 114. The generated signal may include the details of the first identifier of the bill. The application server 114 may be configured to verify whether the first identifier included in the received signal corresponds to an already paid bill or not. In other words, the application server 114 may verify, based on the received signal, whether the first identifier of the bill is different from one or more bill identifiers in the transaction history database. For such verification, the application server 114 may query the transaction history database using the first identifier and compare the first identifier with various bill identifiers included in the transaction history database. In a scenario where the first identifier in the received signal is same as one of the bill identifiers in the transaction history database, the application server 114 may establish that the bill is already paid. Consequently, the application server 114 may execute one of a first action or a second action when the transaction history database includes the first identifier of the bill and an indicator of a successful payment of the bill. The first action includes flagging the bill payment reminder on the user device 106 as duplicate and the second action includes declining the second payment request. Thus, the application server 114 mitigates duplicate bill payments, without requiring any of the first and second payment modes 118a and 118b to fetch bill payment status from the service provider server 102.
Although in FIG. 1A, the service application 122 is shown to be a separate entity, in other embodiments, the service application 122 may be integrated with the first and second payment modes 118a and 118b, without deviating from the scope of the disclosure. For example, the service application 122 may be integrated as a software development kit (SDK) plugin with the first and second payment modes 118a and 118b. In such an embodiment, API calls may be communicated to the application server 114 based on initiation of payment requests on the first and second payment modes 118a and 118b or generation of bill payment reminders on the first and second payment modes 118a and 118b. Further, the bill payment reminders on the first and second payment modes 118a and 118b may be flagged as duplicate and the initiated payment requests may be declined based on responses from the application server 114 to the API calls.
FIG. 1B is a block diagram that illustrates another exemplary environment for mitigating any duplicate transactions, in accordance with another exemplary embodiment of the present disclosure. With reference to FIG. 1B, an exemplary environment 100B is shown. The exemplary environment 100B includes the service provider server 102, the acquirer server 104, the user device 106 of the user 108, the issuer server 110, the payment network server 112, and the application server 114. The service provider server 102, the acquirer server 104, the user device 106, the issuer server 110, the payment network server 112, and the application server 114 may communicate with each other by way of the communication network 116 or through separate communication channels therebetween. In FIG. 1B, the service application 122 hosted by the application server 114 is shown to be implemented on the issuer server 110 along with the user device 106.
In such embodiments, when the issuer server 110 receives a payment request for payment of a bill from the user account 120, the service application 122 executed at the issuer server 110 may generate a signal (e.g., an API call) indicating that the payment request is initiated for the payment of the bill and communicate the generated signal to the application server 114. The generated signal may be indicative of information such as an identifier of the bill, and other information related to the bill such as a customer ID, an amount of the bill, or the like. The application server 114 may be configured to verify whether the bill associated with the payment request is already paid or not. For such verification, the application server 114 may query the transaction history database (as shown in FIGS. 2 and 3D) that includes details of various bill payment transactions. The application server 114 may be configured to compare the identifier of the bill with other bill identifiers in the transaction history database. In a scenario, where the transaction history database does not include any record of the identifier, the application server 114 may establish that the payment request is not duplicate. The application server 114 may communicate a response (e.g., an API response) to the API call to the issuer server 110 indicating that the payment request corresponds to an unpaid bill. Based on the API response, the issuer server 110 may process the payment request. Upon processing of the payment request, a new record in the transaction history database may be created such that the new record includes information of the identifier and an indicator of successful payment of the bill.
However, in a scenario, where the identifier matches one of the bill identifiers in the transaction history database, the application server 114 may establish that the bill is already paid and the payment request is duplicate. Consequently, the application server 114 may communicate a response to the issuer server 110 indicating the duplicity of the payment transaction. Based on the response, the payment request may be declined by the issuer server 110.
Implementation of the service application 122 at the issuer server 110 provides an additional layer of security to those users who may not have the service application 122 installed on their user devices. Thus, mitigating duplicate transactions for users who have the service application 122 installed on their user devices and users who do not have the service application 122 installed on their user devices.
FIG. 2 is a block diagram that illustrates the application server 114, in accordance with an exemplary embodiment of the present disclosure. FIG. 2 is described in conjunction with elements of FIG. 1A. The application server 114 may include a network interface 202, a memory 204, and processing circuitry 206.
The network interface 202 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to transmit and receive data over the communication network 116 using one or more communication network protocols. The network interface 202 may transmit requests, messages, and notifications to and receive requests, messages, and notifications from the user device 106. Examples of the network interface 202 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 memory 204 may include suitable logic, circuitry, and/or interfaces to store various instructions or code which when executed by the processing circuitry 206 causes the processing circuitry 206 to perform their corresponding operations. The memory 204 may be further configured to store the consent database (hereinafter, referred to and designated as “the consent database 208”) and the transaction history database (hereinafter, referred to and designated as “the transaction history database 210”). The consent database 208 and the transaction history database 210 are described in detail in conjunction with FIGS. 3A-3C, 4, and 5A-5D. Examples of the memory 204 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 204 in the application server 114, as described herein. In another embodiment, the memory 204 may be realized in form of a database server or a cloud storage working in conjunction with the application server 114, without departing from the scope of the disclosure.
The processing circuitry 206 may include one or more processors and hosts (such as an application host 212, a consent aggregator 214, and a transaction analyzer 216) that enable the application server 114 to execute various operations for mitigating duplicate payment transactions.
The application host 212 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, to perform one or more application hosting operations required for the operation of the application server 114. The application host 212 may be configured to host the service application 122. Examples of the application host 212 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 consent aggregator 214 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, to perform one or more consent aggregation operations required for the operation of the application server 114. The consent aggregator 214 may be configured to update and modify the consent database 208 based on the consent information retrieved by the service application 122 from the user device 106. For example, the consent aggregator 214 may create new records and/or delete previous records based on the consent information retrieved by the service application 122. Examples of the consent aggregator 214 may include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, an FPGA, a CPU, or a microprocessor.
The transaction analyzer 216 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, to perform one or more transaction analyzing operations required for the operation of the application server 114. In an embodiment, when the transaction history database 210 is maintained at the application server 114, the transaction analyzer 216 may be configured to update and modify the transaction history database 210 based on various signals (e.g., API calls) received from the service application 122. For example, the transaction analyzer 216 may create new records based on the signals received from the service application 122. The transaction analyzer 216 may be further configured to look-up the transaction history database 210 to verify whether payment reminders generated by the first and second payment modes 118a and 118b on the user device 106 correspond to bills that are already paid. The transaction analyzer 216 may be further configured to look-up the transaction history database 210 to verify whether payment requests initiated on the user device 106 using the first and second payment modes 118a and 118b are duplicate payment requests. The transaction analyzer 216 may be further configured to flag duplicate bill payment reminders (e.g., the first action) and decline duplicate payment requests (e.g., the second action) based on the verification. Examples of the transaction analyzer 216 may include, but are not limited to, an ASIC processor, a RISC processor, a CISC processor, an FPGA, a CPU, or a microprocessor.
Although FIG. 2 illustrates that the transaction history database 210 is maintained at the application server 114, in some embodiments, the transaction history database 210 may be maintained at the issuer server 110, without deviating from the scope of the disclosure. Embodiments where the transaction history database 210 is maintained at the issuer server 110 are described later in conjunction with FIGS. 4 and 5A-5D.
FIGS. 3A-3C, collectively, represent a process flow diagram 300 that illustrates an exemplary scenario for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure. For the sake of ongoing description, it is assumed that the service application 122 is executed on the user device 106 and the user 108 has provided a read-only access to the service application 122 to track various consent related activities and payment related activities on the first and second payment modes 118a and 118b (e.g., the plurality of payment modes accessible on the user device 106).
A first consent may be provided to the first payment mode 118a by the user 108 to pay bills of a service (for example, a utility service or a non-utility service) using the user account 120 (as shown by arrow 302). While providing the consent to the first payment mode 118a, the user 108 may have provided various details (such as a customer ID, information of the service provider, etc.) of a service account of the user 108, details of the user account 120, or the like to the first payment mode 118a. The service application 122 that is running on the user device 106 may track the consent related activity on the first payment mode 118a and may generate an API call to the application server 114. The API call may include information of the first consent (as shown by arrow 304). The first consent information may include a name of the service (e.g., SER1) for which the first consent is granted, the first payment mode 118a to which the first consent is granted, and an underlying payment account (for example, the user account 120) linked to the first payment mode 118a. In an embodiment, the first consent may be a time limited consent (for example, a consent with a limited validity period). In such a scenario, the first consent information may further include the details of the validity period (e.g., 2 months, 3 months, or the like) of the first consent. The consent aggregator 214 may be configured to receive the first consent information from the service application 122 and update the consent database 208 stored in the memory 204 (as shown by arrow 306). The update of the consent database 208 is described in conjunction with FIG. 3D.
Referring now to FIG. 3D, the memory 204, in accordance with an exemplary embodiment of the present disclosure, is shown. The memory 204 may have the consent database 208 and the transaction history database 210 stored therein. Based on the first consent information, the consent aggregator 214 may be configured to create a first consent record (e.g., ‘Consent 1’) in the consent database 208. Creation of a consent record in the consent database 208 may refer to addition of a new row in the consent database 208. The first consent record (‘Consent 1’) may include the first consent information, such as the first payment mode 118a to which the first consent is granted, the name of the service (e.g., SER1) for which the first consent is granted, and the underlying payment account (for example, the user account 120) linked to the first payment mode 118a.
Referring back to FIG. 3A, a second consent may be provided to the second payment mode 118b by the user 108 to pay bills of the service (e.g., SER1) (as shown by arrow 308). The service application 122 that is running on the user device 106 may further track the consent related activity on the second payment mode 118b and may generate another API call to the application server 114. The API call may include information of the second consent (as shown by arrow 310). The second consent information may include a name of the service (e.g., SER1) for which the second consent is granted, the second payment mode 118b to which the second consent is granted, and an underlying payment account (for example, the user account 120) linked to the second payment mode 118b. The consent aggregator 214 may be configured to receive the second consent information from the service application 122 and update the consent database 208 stored in the memory 204 (as shown by arrow 312). The update of the consent database 208 is described in conjunction with FIG. 3D.
Referring now to FIG. 3D, based on the second consent information, the consent aggregator 214 may be configured to create a second consent record (e.g., ‘Consent 2’) in the consent database 208. The second consent record may include the second consent information, such as the second payment mode 118b to which the second consent is granted, the name of the service (e.g., SER1) for which the second consent is granted, and the underlying payment account (for example, the user account 120) linked to the second payment mode 118b. Each row in the consent aggregator 214 may correspond to a unique consent record. In other words, the consent database 208 may include one or more consent records associated with the user device 106 and other user devices such that each consent record indicates a permission granted to a payment mode for payment of bills of a service on a corresponding user device.
Referring back to FIG. 3A, for the sake of ongoing description, it is assumed that monthly payment reminder cycles of the first and second payment modes 118a and 118b are different, and the monthly payment reminder cycle of the first payment mode 118a is prior to the monthly payment reminder cycle of the second payment mode 118b. Monthly payment reminder cycle of a payment mode may refer to a time instance every month at which the payment mode retrieves bill statements of its users from service providers or third-party servers that maintain bill statements. For example, the monthly payment reminder cycle of the first payment mode 118a may get triggered on 10th day of every month and the monthly payment reminder cycle of the second payment mode 118b may get triggered on 20th day of every month.
When the monthly payment reminder cycle of the first payment mode 118a is triggered for a month (for example, June), the first payment mode 118a may communicate a bill information request to the service provider server 102 (as shown by arrow 314). The bill information request may include the customer ID of the user 108 that is linked to the service account of the user 108 of the service (SER1). The service provider server 102 may receive the bill information request and communicate bill statement of the current billing cycle (e.g. June) to the first payment mode 118a running on the user device 106 (as shown by arrow 316). The bill statement may include a first identifier (e.g., ‘B1’) of the bill, billing cycle details (e.g., month), an amount to be paid, a bill payment due date, or the like. In this example, the retrieved bill statement for the service (SER1) may be for the month of June 2021 and may indicate that an amount of $300 is to be paid by June 30, 2021.
Upon receiving the bill of the current billing cycle, the first payment mode 118a may generate a first payment reminder to notify the user 108 regarding the amount and the due date (as shown by arrow 318). The first payment reminder may be presented on a graphical user interface (UI) rendered on the user device 106 by the first payment mode 118a. In an embodiment, the first payment mode 118a may further offer one or more discounts or offers (for example, X% discount, shopping vouchers, or the like) to the user 108 upon the payment of the bill using the first payment mode 118a.
When the first payment mode 118a generates the first payment reminder on the user device 106, the service application 122 running on the user device 106 may track the payment reminder activity on the first payment mode 118a. Based on the tracked activity, the service application 122 may generate and communicate a first signal (e.g., an API call) to the application server 114 (as shown by arrow 320). The first signal may be indicative of the first identifier (‘B1’) of the bill and the first payment mode 118a that generated the first payment reminder. The transaction analyzer 216 may receive the first signal and may look-up the transaction history database 210 based on the first signal to verify the first payment reminder for duplicity (as shown by arrow 322). In other words, the transaction analyzer 216 may verify whether the first identifier (‘B1’) of the bill is different from one or more other identifiers included in the transaction history database 210. For verification, the transaction analyzer 216 may compare the first identifier (‘B1’) with one or more other identifiers included in the transaction history database 210. In one scenario, the transaction analyzer 216 may not find a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In such scenario, the transaction analyzer 216 may establish that the first payment reminder is not duplicate.
Referring now to FIG. 3B, the transaction analyzer 216 may generate an instruction for the service application 122 to reset a duplicate flag of the first payment reminder to ‘0’ (as shown by arrow 324). Resetting the duplicate flag of the first payment reminder to ‘0’ may indicate that the first payment reminder is not duplicate, and hence no action is to be performed for the first payment reminder. The service application 122 may receive the instruction and establish that the first payment reminder is not duplicate.
Upon receiving the first payment reminder, the user 108 may initiate a first payment request using the first payment mode 118a to make payment of the bill (as shown by arrow 326). The service application 122 running on the user device 106 may track the payment activity on the first payment mode 118a and may detect that the first payment request is initiated using the first payment mode 118a. Based on the tracked activity, the service application 122 may generate and communicate a second signal (e.g., an API call) to the application server 114 (as shown by arrow 328). The second signal may be indicative of the first payment request, the first identifier (‘B1’) of the bill, and the first payment mode 118a used for the initiation of the first payment request.
The transaction analyzer 216 may receive the second signal from the service application 122. Based on the second signal, the transaction analyzer 216 may be configured to verify the first payment request for duplicity (as shown by arrow 330). For verifying the first payment request, the transaction analyzer 216 may look-up the transaction history database 210 to identify whether the transaction history database 210 includes the first identifier (‘B1’). For verification, the transaction analyzer 216 may compare the first identifier (‘B1’) with one or more other identifiers in the transaction history database 210. In the current scenario, since the bill of the service (SER1) is not paid yet, the transaction analyzer 216 may not find a match of the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In other words, the first identifier (‘B1’) of the bill may be different from one or more other identifiers stored in the transaction history database 210. Subsequently, the transaction analyzer 216 may be configured to create a first record in the transaction history database 210 (as shown by arrow 332). The first record may include information of the first identifier (‘B1’). The first record may further include a success indicator that indicates whether the payment of the bill is successful or not. Initially, the success indicator may merely indicate “payment pending” status. Creation of the first record is described in conjunction with FIG. 3D.
Referring now to FIG. 3D, based on the information in the second signal, the transaction analyzer 216 may be configured to create the first record (e.g., ‘Record 1’) in the transaction history database 210. Creation of the first record may correspond to addition of a new row in the transaction history database 210. The first record (‘Record 1’) may include the first identifier (‘B1’). In some embodiment, the first record (‘Record 1’) may additionally include a transaction identifier (‘TXN1’) of the first payment request, the first payment mode 118a used for initiating the first payment request, a bill amount (e.g., ‘$300’), the customer ID of the user 108 with the service (SER1), or the like. The first record (‘Record 1’) may further include the success indicator that indicates whether bill payment as per the first payment request was successful or not. The value of the success indicator may be updated by the transaction analyzer 216, when the transaction analyzer 216 receives a confirmation from the service application 122 regarding a success of the bill payment. In other words, the transaction history database 210 may include one or more records each associated with a different bill and indicating a successful payment of the corresponding bill. Each record in the transaction history database 210 may include information of a unique identifier of the corresponding bill and an indicator of successful payment of the corresponding bill.
Referring back to FIG. 3B, the transaction analyzer 216 may be further configured to communicate an allow payment instruction to the service application 122 (as shown by arrow 334). Based on the allow payment instruction, the service application 122 may allow the first payment mode 118a to transmit the first payment request to the payment network server 112 for processing of the bill payment. The first payment mode 118a may then transmit the first payment request to the payment network server 112 for processing of the bill payment (as shown by arrow 336). The payment network server 112 may process the first payment request received from the first payment mode 118a (as shown by arrow 338). Processing of a payment transaction by the issuer server 110, the payment network server 112, and the acquirer server 104 is a standard practice and will be known to a person of ordinary skill in the art.
Upon successful processing of the first payment request, the payment network server 112 may communicate a payment successful notification to the first payment mode 118a (as shown by arrow 340). The service application 122 running on the user device 106 may further track the activity on the first payment mode 118a and may detect reception of the payment successful notification. Based on the tracked activity, the service application 122 may generate and communicate a third signal (e.g., an API call) to the application server 114 (as shown by arrow 342). The third signal may be indicative of the payment successful notification and the first identifier (‘B1’) of the bill.
The transaction analyzer 216 may be further configured to update the first record in the transaction history database 210 to indicate that bill payment against the first identifier (‘B1’) is successful (as shown by arrow 344). As shown in FIG, 3D, the transaction analyzer 216 may update the success indicator in the first record (‘Record 1’) to ‘Yes’, thereby indicating that the bill payment corresponding to the first identifier ‘B1’ is successful.
When the monthly payment reminder cycle of the second payment mode 118b is triggered for the month of June, the second payment mode 118b may communicate a bill information request to the service provider server 102 (as shown by arrow 346). The bill information request may include the customer ID of the user 108 that is linked to the service account of the service (SER1). The service provider server 102 may communicate bill statement of the current billing cycle (e.g. June) to the second payment mode 118b running on the user device 106 (as shown by arrow 348). The bill statement may include the first identifier (‘B1’) of the bill, billing cycle details (e.g., June month), the amount to be paid (e.g., ‘$300), the payment due date (e.g. June 30, 2021), or the like.
Upon receiving the bill of the current billing cycle, the second payment mode 118b may generate a second payment reminder to notify the user 108 regarding the amount and the due date (as shown by arrow 350). The second payment reminder may be presented on a graphical UI rendered on the user device 106 by the second payment mode 118b. When the second payment mode 118b generates the second payment reminder on the user device 106, the service application 122 running on the user device 106 may track the payment reminder activity on the second payment mode 118b. Based on the tracked activity, the service application 122 may generate and communicate a fourth signal (e.g., an API call) to the application server 114 (as shown by arrow 352). The fourth signal may be indicative of the first identifier (‘B1’) of the bill and the second payment mode 118b that generated the second payment reminder. The transaction analyzer 216 may receive the fourth signal and may look-up the transaction history database 210 based on the fourth signal to verify the second payment reminder for duplicity (as shown by arrow 354). For verification, the transaction analyzer 216 may compare the first identifier (‘B1’) with one or more other identifiers included in the transaction history database 210. In this current scenario, since the bill corresponding to the first identifier (‘B1’) is already paid, the transaction history database 210 includes the first record (Record 1’) that has the first identifier (‘B1’). Thus, the transaction analyzer 216 may flag the second payment reminder as duplicate (for example, the first action).
The transaction analyzer 216, upon detecting that the second payment reminder is duplicate, may generate an instruction for the service application 122 to set a duplicate flag of the second payment reminder to ‘1’ (as shown by arrow 356). Setting the duplicate flag of the second payment reminder to ‘1’ may flag the second payment reminder as duplicate. The service application 122 may receive the instruction and set the duplicate flag of the second payment reminder to ‘1’. When the duplicate flag of the second payment reminder is to ‘1’, the second payment mode 118a may be configured to render a UI on the user device 106 to notify the user 108 that the second payment reminder is duplicate and the bill is already paid (as shown by arrow 358). In other words, setting the duplicate flag of the second payment reminder to ‘1’ may cause the second payment mode 118b to change a bill payment status of the bill from ‘pending’ to ‘paid’.
In an exemplary scenario, the user 108 may still initiate a second payment request using the second payment mode 118b to make payment of the bill (as shown by arrow 360). The service application 122 running on the user device 106 may track the payment activity on the second payment mode 118b and may detect that the second payment request is initiated using the second payment mode 118b. Based on the tracked activity, the service application 122 may generate and communicate a fifth signal (e.g., an API call) to the application server 114 (as shown by arrow 362). The fifth signal may be indicative of the second payment request, the first identifier (‘B1’) of the bill, and the second payment mode 118b used for the initiation of the second payment request.
The transaction analyzer 216 may receive the fifth signal from the service application 122. Based on the fifth signal, the transaction analyzer 216 may be configured to verify the second payment request for duplicity (as shown by arrow 364). For verifying the second payment request, the transaction analyzer 216 may look-up the transaction history database 210 to identify whether the transaction history database 210 includes the first identifier (‘B1’). For verification, the transaction analyzer 216 may compare the first identifier (‘B1’) with one or more other identifiers included in the transaction history database 210. In the current scenario, since the bill of the service (SER1) is already paid, the transaction analyzer 216 finds a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In other words, the first identifier (‘B1’) of the bill and the indicator of successful payment of the bill is included in the transaction history database 210.
The transaction analyzer 216 may be further configured to communicate a decline instruction to the service application 122 for the second payment request (as shown by arrow 366). The service application 122 may further communicate the decline instruction to the second payment mode 118a (as shown by arrow 368), thereby declining the second payment request (e.g., second action). Based on the decline instruction, the second payment mode 118b may not transmit the second payment request to the payment network server 112 and may be configured to render a UI on the user device 106 to notify the user 108 regarding the decline of the second payment request due to the bill being already paid (as shown by arrow 370). In other words, the application server 114 by implementing the service application 122 mitigates a likelihood of a duplicate payment being performed on the user device 106.
FIG. 4 is a block diagram 400 that illustrates the application server 114 for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure. In FIG. 4, the transaction history database 210 is shown to be maintained at the issuer server 110 instead of the application server 114. In such embodiments, for verification of duplicity of payment reminders and payment requests, the transaction analyzer 216 may query the issuer server 110 using unique identifiers of the bills. The creation of new records and the update of the transaction history database 210 may be managed by the issuer server 110. Various operations of the application server 114 in accordance with this embodiment are described in detail in FIGS. 5A-5D.
FIGS. 5A-5D, collectively, represent a process flow diagram 500 that illustrates another exemplary scenario for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure. For the sake of ongoing description, it is assumed that the service application 122 is executed on the user device 106 and the user 108 has provided a read-only access to the service application 122 to track various consent related activities and payment related activities on the first and second payment modes 118a and 118b.
The user 108 may have provided the first consent to the first payment mode 118a and the second consent to the second payment mode 118b to pay bills of a service (for example, a utility service or a non-utility service) using the user account 120. The consent aggregator 214 may update the consent database 208 stored in the memory 204 as described in the foregoing description of FIG. 3A. When the monthly payment reminder cycle of the first payment mode 118a is triggered for a month (for example, June), the first payment mode 118a may retrieve a bill statement of the current billing cycle (e.g. June) from the service provider server 102. The bill statement may include the first identifier (e.g., ‘B1’) of the bill, billing cycle details (e.g., month), an amount to be paid, a bill payment due date, or the like.
Upon receiving the bill of the current billing cycle, the first payment mode 118a may generate a first payment reminder to notify the user 108 regarding the amount and the due date (as shown by arrow 502). The first payment reminder may be presented on a graphical UI rendered on the user device 106 by the first payment mode 118a. When the first payment mode 118a generates the first payment reminder on the user device 106, the service application 122 running on the user device 106 may track the payment reminder activity on the first payment mode 118a. Based on the tracked activity, the service application 122 may generate and communicate a sixth signal (e.g., an API call) to the application server 114 (as shown by arrow 504). The sixth signal may be indicative of the first identifier (‘B1’) of the bill and the first payment mode 118a that generated the first payment reminder. The transaction analyzer 216 may receive the sixth signal and verify the first payment reminder for duplicity (as shown by arrow 506). For verification, the transaction analyzer 216 may communicate a first query to the issuer server 110 that is maintaining the transaction history database 210 associated with the user account 120 linked to the first payment mode 118a (as shown by arrow 508). In an embodiment, the transaction analyzer 216 may retrieve the information of the user account 120 linked to the first payment mode 118a for the payment of bills of the service (SER1) from the consent database 208. The first query may include the first identifier (‘B1’) of the bill for which the first payment reminder is generated. The issuer server 110 may compare the first identifier (‘B1’) with one or more other identifiers included in the transaction history database 210. In one scenario, the issuer server 110 may not find a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In such scenario, the issuer server 110 may communicate a first response to the application server 114 indicating that the first identifier (‘B1’) is different from the one or more other identifiers included in the transaction history database 210 (as shown by arrow 510). Based on the first response, the verification by the transaction analyzer 216 is complete and the transaction analyzer 216 establishes that the first payment reminder is not duplicate.
The transaction analyzer 216 may generate an instruction for the service application 122 to reset a duplicate flag of the first payment reminder to ‘0’ (as shown by arrow 512). Resetting the duplicate flag of the first payment reminder to ‘0’ may indicate that the first payment reminder is not duplicate, and hence no action is to be performed for the first payment reminder. The service application 122 may receive the instruction and establish that the first payment reminder is not duplicate.
Upon receiving the first payment reminder, the user 108 may initiate a first payment request using the first payment mode 118a to make payment of the bill (as shown by arrow 514). The service application 122 running on the user device 106 may track the payment activity on the first payment mode 118a and may detect that the first payment request is initiated using the first payment mode 118a. Based on the tracked activity, the service application 122 may generate and communicate a seventh signal (e.g., an API call) to the application server 114 (as shown by arrow 516). The seventh signal may be indicative of the first payment request, the first identifier (‘B1’) of the bill, and the first payment mode 118a used for the initiation of the first payment request.
The transaction analyzer 216 may receive the seventh signal from the service application 122. Based on the seventh signal, the transaction analyzer 216 may be configured to verify the first payment request for duplicity (as shown by arrow 518). For verifying the first payment request, the transaction analyzer 216 may communicate a second query to the issuer server 110 that is maintaining the transaction history database 210 associated with the user account 120 linked to the first payment mode 118a (as shown by arrow 520). The transaction analyzer 216 may retrieve the information of the user account 120 linked to the first payment mode 118a for the payment of bills of the service (SER1) from the consent database 208. The second query may include the first identifier (‘B1’) of the bill for which the first payment request is initiated. The issuer server 110 may compare the first identifier (‘B1’) with one or more other identifiers included in the transaction history database 210. In one scenario, the issuer server 110 may not find a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In such scenario, the issuer server 110 may communicate a second response to the application server 114 indicating that the first identifier (‘B1’) is different from the one or more other identifiers included in the transaction history database 210 (as shown by arrow 522). Based on the first response, the verification by the transaction analyzer 216 is complete and the transaction analyzer 216 establishes that the first payment request is not duplicate.
Referring now to FIG. 5B, the transaction analyzer 216 may be further configured to communicate an allow payment instruction to the service application 122 (as shown by arrow 524). Based on the allow payment instruction, the service application 122 may allow the first payment mode 118a to transmit the first payment request to the payment network server 112 for processing of the bill payment. The first payment mode 118a may then transmit the first payment request to the payment network server 112 for processing of the bill payment (as shown by arrow 526). The payment network server 112 may process the first payment request received from the first payment mode 118a and may communicate the processed first payment request to the issuer server 110 linked to the user account 120 (as shown by arrow 528). The issuer server 110 may process the first payment request (as shown by arrow 530) and may debit the user account 120 based on the bill amount. The issuer server 110 may create a first record in the transaction history database 210 (as shown by arrow 532). The first record may include information of the first identifier (‘B1’). The first record may further include a success indicator that indicates successful payment of the bill.
Upon successful processing of the first payment request, the issuer server 110 may communicate a payment response to the payment network server 112 (as shown by arrow 534) and the payment network server 112 may communicate a payment successful notification to the first payment mode 118a (as shown by arrow 536).
Referring now to FIG. 5C, when the monthly payment reminder cycle of the second payment mode 118b is triggered for the month of June, the second payment mode 118b may retrieve the bill statement of the current billing cycle (e.g. June) from the service provider server 102 and generate a second payment reminder to notify the user 108 regarding the amount and the due date (as shown by arrow 538). The second payment reminder may be presented on a graphical UI rendered on the user device 106 by the second payment mode 118b. When the second payment mode 118b generates the second payment reminder on the user device 106, the service application 122 running on the user device 106 may track the payment reminder activity on the second payment mode 118b. Based on the tracked activity, the service application 122 may generate and communicate an eighth signal (e.g., an API call) to the application server 114 (as shown by arrow 540). The eighth signal may be indicative of the first identifier (‘B1’) of the bill and the second payment mode 118b that generated the second payment reminder. The transaction analyzer 216 may receive the eighth signal and verify the second payment reminder for duplicity (as shown by arrow 542). For verification, the transaction analyzer 216 may communicate a third query to the issuer server 110 that is maintaining the transaction history database 210 associated with the user account 120 linked to the first payment mode 118a (as shown by arrow 544). The issuer server 110 may compare the first identifier (‘B1’) with the one or more other identifiers included in the transaction history database 210. In one scenario, the issuer server 110 may find a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In such scenario, the issuer server 110 may communicate a third response to the application server 114 indicating the transaction history database 210 includes the first record that has the first identifier (‘B1’) and the indicator of successful payment of the bill (as shown by arrow 546). Based on the third response, the verification by the transaction analyzer 216 is complete and the transaction analyzer 216 may flag the second payment reminder as duplicate.
The transaction analyzer 216, upon detecting that the second payment reminder is duplicate, may generate an instruction for the service application 122 to set a duplicate flag of the second payment reminder to ‘1’ (as shown by arrow 548). Setting the duplicate flag of the second payment reminder to ‘1’ may flag the second payment reminder as duplicate. The service application 122 may receive the instruction and set the duplicate flag of the second payment reminder to ‘1’. When the duplicate flag of the second payment reminder is to ‘1’, the second payment mode 118a may be configured to render a UI on the user device 106 to notify the user 108 that the second payment reminder is duplicate and the bill is already paid (as shown by arrow 550). In other words, setting the duplicate flag of the second payment reminder to ‘1’ may cause the second payment mode 118b to change a bill payment status of the bill from ‘pending’ to ‘paid’.
In an exemplary scenario, the user 108 may still initiate a second payment request using the second payment mode 118b to make payment of the bill (as shown by arrow 552). The service application 122 running on the user device 106 may track the payment activity on the second payment mode 118b and may detect that the second payment request is initiated using the second payment mode 118b. Based on the tracked activity, the service application 122 may generate and communicate a ninth signal (e.g., an API call) to the application server 114 (as shown by arrow 554). The ninth signal may be indicative of the second payment request, the first identifier (‘B1’) of the bill, and the second payment mode 118b used for the initiation of the second payment request. The transaction analyzer 216 may receive the ninth signal from the service application 122. Based on the ninth signal, the transaction analyzer 216 may be configured to verify the second payment request for duplicity (as shown by arrow 556).
Referring to FIG. 5D, for verifying the second payment request, the transaction analyzer 216 may communicate a fourth query to the issuer server 110 that is maintaining the transaction history database 210 associated with the user account 120 linked to the first payment mode 118a (as shown by arrow 558). Based on the fourth query, the issuer server 110 may compare the first identifier (‘B1’) with the one or more other identifiers included in the transaction history database 210. In one scenario, the issuer server 110 may find a match for the first identifier (‘B1’) in the transaction history database 210 based on the comparison. In such scenario, the issuer server 110 may communicate a fourth response to the application server 114 indicating that the transaction history database 210 includes the first record that has the first identifier (‘B1’1) and the indicator of successful payment of the bill (as shown by arrow 560). Based on the fourth response, the verification by the transaction analyzer 216 is complete and the transaction analyzer 216 establishes that the second payment request is duplicate. The transaction analyzer 216 may be further configured to communicate a decline instruction to the service application 122 for the second payment request (as shown by arrow 562). The service application 122 may further communicate the decline instruction to the second payment mode 118a (as shown by arrow 564), thereby declining the second payment request. Based on the decline instruction, the second payment mode 118b may not transmit the second payment request to the payment network server 112 and may be configured to render a UI on the user device 106 to notify the user 108 regarding the decline of the second payment request due to the bill being already paid (as shown by arrow 566). In other words, the application server 114 by implementing the service application 122 mitigates a likelihood of a duplicate payment being performed on the user device 106.
FIG. 6 is a block diagram that illustrates a system architecture of a computer system 600, in accordance with an exemplary embodiment of the present disclosure. An embodiment of disclosure, or portions thereof, may be implemented as computer readable code on the computer system 600. In one example, the service provider server 102, the acquirer server 104, the issuer server 110, and the payment network server 112 may be implemented as the computer system 600. Hardware, software, or any combination thereof may embody modules and components used to implement methods of FIGS. 7, 8, and 9. The computer system 600 may include a processor 602, a communication infrastructure 604, a main memory 606, a secondary memory 608, an I/O interface 610, and a communication interface 612.
The processor 602 may be a special-purpose or a general-purpose processing device. The processor 602 may be a single processor, multiple processors, or combinations thereof. Further, the processor 602 may be connected to the communication infrastructure 604, such as a bus, message queue, multi-core message-passing scheme, and the like. Examples of the main memory 606 may include a RAM, a ROM, and the like. The secondary memory 608 may include an HDD 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 I/O interface 610 includes various input and output devices that are configured to communicate with the processor 602. 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 612 may be configured to allow data to be transferred between the computer system 600 and various devices that are communicatively coupled to the computer system 600. Examples of the communication interface 612 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 612 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art.
FIG. 7 represents a high-level flowchart 700 that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure.
At step 702, a first signal is received by the processing circuitry 206. The first signal may indicate that a first payment request is initiated on the user device 106 using the first payment mode 118a of the plurality of payment modes accessible on the user device 106 for payment of a bill. The first signal may be indicative of a first identifier of the bill. At step 704, the processing circuitry 206 verifies whether a first identifier of the bill is different from one or more second identifiers in the transaction history database 210. Verification of whether the first identifier of the bill is different from one or more second identifiers in the transaction history database 210 may correspond to verifying the first payment request for duplicity (as described in the foregoing description of FIGS. 3A-3C and 5A-5D). A first record is created in the transaction history database 210 when the first identifier of the bill is different from the one or more second identifiers. In an embodiment the first record may be created by the transaction analyzer 216. In another embodiment, the first record may be created by the issuer server 110. The created first record may include information of the first identifier and an indicator of successful payment of the bill.
At step 706, a second signal is received by the processing circuitry 206. The second signal may indicate one of reception of a payment reminder on the user device 106 from the second payment mode 118b of the plurality of payment modes for the payment of the bill or initiation of a second payment request on the user device 106 using the second payment mode 118b for the payment of the bill. The second signal may be indicative of at least the first identifier of the bill. At step 708, one of a first action or a second action is executed by the processing circuitry 206 when the transaction history database 210 includes the first record that has the first identifier of the bill and the indicator of successful payment of the bill. The first action includes flagging the payment reminder on the user device 106 as duplicate and the second action includes declining the second payment request initiated using the second payment mode 118b. Execution of the first action and the second action is described in detail in the foregoing description of FIGS. 3A-3C and 5A-5D.
FIG. 8 represents a high-level flowchart 800 that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with another exemplary embodiment of the present disclosure.
At step 802, the transaction history database 210 is maintained by the processing circuitry 206. The transaction history database 210 may include a plurality of records, each indicating a successful payment of a different bill. A first record of the plurality of records includes information of a unique identifier of a corresponding bill and an indicator of successful payment of the corresponding bill. At step 804, a first signal is received by the processing circuitry 206. The first signal may indicate one of reception of a payment reminder on the user device 106 from one of the plurality of payment modes (e.g., the first and second payment modes 118a and 118b) accessible on the user device 106 for payment of a bill or initiation of a payment request on the user device 106 using one of the plurality of payment modes for the payment of the bill. The first signal may be indicative of at least a first identifier of the bill. At step 806, one of a first action or a second action is executed by the processing circuitry 206 when the transaction history database 210 includes the first identifier of the bill and the indicator of successful payment of the bill. The first action includes flagging the payment reminder on the user device 106 as duplicate and the second action includes declining the payment request.
FIG. 9 represents a flowchart 900 that illustrates a method (or process) for mitigating duplicate payment transactions, in accordance with an exemplary embodiment of the present disclosure.
At step 902, the service application 122 is hosted by the processing circuitry 206. The service application 122 tracks one or more activities performed using the plurality of payment modes (e.g., the first and second payment modes 118a and 118b) on the user device 106. At step 904, the consent database 208 is stored by the processing circuitry 206 in the memory 204. The consent database 208 may include one or more consent records associated with the user device 106. A consent record of the one or more consent records indicates a permission granted to a payment mode of the plurality of payment modes accessible on the user device 106 for payment of one or more bills of a service. At step 906, one or more activities performed using the plurality of payment modes on the user device 106 are tracked by the processing circuitry 206.
At step 908, a first signal is received by the processing circuitry 206. The first signal may indicate that a first payment request is initiated on the user device 106 using the first payment mode 118a of the plurality of payment modes accessible on the user device 106 for payment of a bill. The first signal may be indicative of a first identifier of the bill. At step 910, the processing circuitry 206 verifies whether a first identifier of the bill is different from one or more second identifiers in the transaction history database 210. A first record is created in the transaction history database 210 when the first identifier of the bill is different from the one or more second identifiers. In an embodiment the first record may be created by the transaction analyzer 216. In another embodiment, the first record may be created by the issuer server 110. The created first record may include information of the first identifier and an indicator of successful payment of the bill.
At step 912, a second signal is received by the processing circuitry 206. The second signal may indicate one of reception of a payment reminder on the user device 106 from the second payment mode 118b of the plurality of payment modes for the payment of the bill or initiation of a second payment request on the user device 106 using the second payment mode 118b for the payment of the bill. The second signal may be indicative of at least the first identifier of the bill. The first signal and the second signal are received based on the tracking of the one or more activities. The first signal and the second signal may be generated by the service application 122 based on the tracking of the one or more activities on the user device 106.
At step 914 one of a first action or a second action is executed by the processing circuitry 206 when the transaction history database 210 includes the first record that has the first identifier of the bill and the indicator of successful payment of the bill. The first action includes flagging the payment reminder on the user device 106 as duplicate and the second action includes declining the second payment request initiated using the second payment mode 118b, and then the process ends.
The method and system (e.g., the application server 114) of the present disclosure offer various advantages. For example, the application server 114 is not only capable of identifying and notifying the user 108 of duplicate payment reminders, but is also capable of declining duplicate payment transactions initiated on different payment modes accessible of the user device 106. In other words, the application server 114 offers a one stop solution to mitigate duplicate payment transactions. Since the service application 122 is capable of monitoring payment related activities on various payment modes (for example, digital wallets, UPI applications, netbanking applications, or the like) when permitted by the user 108, a likelihood of making duplicate payment across the payment modes is completely mitigated. Besides the transaction history database 210 is updated in real time, thus even if a duplicate transaction or a duplicate payment reminder is generated within seconds of the first payment, the application server 114 is capable of detecting and mitigating duplicity.
Techniques consistent with the present disclosure provide, among other features, systems, and methods for mitigating duplicate payment transactions. 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 the disclosure, without departing from the breadth or scope.
In the claims, the words ‘comprising’, ‘including’, and ‘having’ does not exclude the presence of other elements or steps than 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 may not 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.