Method and system for managing pending transactions

Abstract

A computer-implemented method is provided. A first transaction from a sender to a receiver via a receiver PSP server is identified. While the first transaction is pending, at least one subsequent transaction from the sender to the receiver is detected. Transaction parameters of the at least one subsequent transaction are compared with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment. When one of the first transaction and the at least one subsequent transaction is identified as successful, one or more messages are sent to indicate the success of the first transaction and the at least one subsequent transaction and to discard the other transaction.

Description

Technical Field

[0001] The present disclosure relates generally to person-to-person (P2P) real-time transactions, and more particularly to managing pending transactions. Background Art

[0002] A person-to-person (P2P) real-time transaction refers to an electronic money transfer from one person (the sender) to another person (the receiver) via a P2P payment application. P2P real-time transactions allow customers to instantly transfer funds from their bank accounts to another individual's account via the internet. When a P2P payment application is used for a P2P real-time transaction between a sender and a receiver, the transaction may become pending due to various reasons, such as limited internet connectivity, PSP server issues, network bandwidth, network load, etc. While a transaction is pending, the sender can repeat the transaction until it succeeds. Upon a successful transaction, the previously pending transaction may succeed or fail. If a pending transaction succeeds, the sender may lose funds due to multiple fund transfers and may need to file a complaint to claim the amount of the multiple transactions.

[0003] In existing methods, if a transaction is pending and funds are being debited from the sender's bank account, the sender must manually request to reverse the transaction. The receiver may deny the sender's request, and the sender may lose funds. Therefore, there is a need to quickly manage pending transactions.

[0004] The information disclosed in this Background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. Summary of the Invention

[0005] Additional features and advantages are realized through the techniques of the present disclosure.Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

[0006] In some non-limiting embodiments or aspects, a computer-implemented method is provided, comprising: identifying, by a sender payment service provider (PSP) server, a first transaction from a sender to a recipient via a recipient PSP server via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the recipient PSP server; detecting, by the sender PSP server, while the first transaction is pending, at least one subsequent transaction from the sender to the recipient; comparing, by the sender PSP server, transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine whether the first transaction and the recipient are valid. At least one subsequent transaction is associated with a single payment made by the sender to the recipient; the sender PSP server identifies one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and the sender PSP server sends one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful and discards the other transactions of the first transaction and the at least one subsequent transaction, wherein the other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0007] In some non-limiting embodiments or aspects, the transaction parameter may be at least one of: a transaction identifier (ID), an amount, a currency, a mobile phone number of the sender and the receiver, a timestamp, a unique identification number of the sender and the receiver, a device fingerprint data of the sender, or any combination thereof.

[0008] In some non-limiting embodiments or aspects, the computer-implemented method further includes assigning a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when the status of the corresponding transaction is updated to pending in a payment response code by the RTP server, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, and wherein the payment response code is generated based on a response provided by the receiver PSP server. In some non-limiting embodiments or aspects, the status of the first transaction and the at least one subsequent transaction is updated to pending in the payment response code when one of the following occurs: the first transaction and the at least one subsequent transaction are initiated and being processed; and no response for the corresponding transaction is received from the receiver PSP server within a predetermined time. In some non-limiting embodiments or aspects, processing of the first transaction and the at least one subsequent transaction is performed simultaneously by the sender PSP server. In some non-limiting embodiments or aspects, the one or more messages are updated using a void command along with the unique pending ID for the successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0009] In some non-limiting embodiments or aspects, a sender payment service provider (PSP) server is provided, comprising one or more processors and a memory communicatively coupled to the one or more processors, wherein the memory stores processor-executable instructions that, when executed, cause the one or more processors to: identify a first transaction from a sender to a receiver via a receiver PSP server via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the receiver PSP server; while the first transaction is pending, detect at least one subsequent transaction from the sender to the receiver; and comparing transaction parameters with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful and the other of the first transaction and the at least one subsequent transaction are discarded, and wherein the other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0010] In some non-limiting embodiments or aspects, the sender PSP server further includes assigning, by the one or more processors, a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when the status of the corresponding transaction is updated to pending by the RTP server in a payment response code, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, and wherein the payment response code is generated based on a response provided by the recipient PSP server. In some non-limiting embodiments or aspects, the one or more processors update the status of the first transaction and the at least one subsequent transaction to pending in the payment response code upon one of the following conditions: the first transaction and the at least one subsequent transaction are initiated and being processed; and no response for the corresponding transaction is received from the recipient PSP server within a predetermined time. In some non-limiting embodiments or aspects, the one or more processors process the first transaction and the at least one subsequent transaction simultaneously. In some non-limiting embodiments or aspects, the one or more processors update one or more messages using a typeless command along with the unique pending ID for the successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0011] In some non-limiting embodiments or aspects, a non-transitory computer-readable medium is provided comprising instructions stored thereon, the instructions, when processed by one or more processors, causing a sender payment service provider (PSP) server to perform operations comprising: identifying a first transaction from a sender to a receiver via a receiver PSP server via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the receiver PSP server; while the first transaction is pending, detecting at least one subsequent transaction between the sender and the receiver; comparing one or more transaction parameters of the at least one subsequent transaction to one of the first transaction; The method comprises the steps of: comparing the first transaction and the at least one subsequent transaction to one or more transaction parameters to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful and discards the other transactions of the first transaction and the at least one subsequent transaction, and wherein the other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0012] In some non-limiting embodiments or aspects, the non-transitory computer-readable medium further includes assigning, by the one or more processors, a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when the status of the corresponding transaction is updated to pending in a payment response code by the RTP server, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, wherein the payment response code is generated based on a response provided by the receiver PSP server. In some non-limiting embodiments or aspects, the one or more processors update the status of the first transaction and the at least one subsequent transaction to pending in the payment response code upon one of the following: the first transaction and the at least one subsequent transaction are initiated and being processed; and no response for the corresponding transaction is received from the receiver PSP server within a predetermined time. In some non-limiting embodiments or aspects, the one or more processors process the first transaction and the at least one subsequent transaction simultaneously. In some non-limiting embodiments or aspects, the one or more processors update one or more messages using a typeless command along with the unique pending ID for the successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0013] In some non-limiting embodiments or aspects, a computer-implemented method for managing pending transactions is provided. The method includes identifying, by a sender payment service provider (PSP) server, a first transaction from a sender to a recipient via a recipient PSP server, conducted via the sender PSP server. In some non-limiting embodiments or aspects, a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the recipient PSP server. Furthermore, the method includes detecting, by the sender PSP server, at least one subsequent transaction from the sender to the recipient while the first transaction is pending. Furthermore, the method includes comparing, by the sender PSP server, transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient. Furthermore, the method includes identifying, by the sender PSP server, one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction. Thereafter, the method includes sending, by the sender PSP server, one or more messages based on the monitoring. In some non-limiting embodiments or aspects, the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful and that the other of the first transaction and the at least one subsequent transaction was discarded, wherein the other transaction was discarded by at least one of the sending PSP server and the receiving PSP server based on the one or more messages.

[0014] In some non-limiting embodiments or aspects, a sender payment service provider (PSP) server is provided. The sender PSP server is configured to manage pending transactions. The sender PSP server includes one or more processors and a memory communicatively coupled to the one or more processors. The one or more processors are configured to identify a first transaction conducted from a sender to a recipient via a recipient PSP server via the sender PSP server. In some non-limiting embodiments or aspects, a real-time payment (RTP) server facilitates transactions between the sender PSP server and the recipient PSP server. Furthermore, the one or more processors are configured to detect at least one subsequent transaction from the sender to the recipient while the first transaction is pending. Furthermore, the one or more processors are configured to compare transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient. Furthermore, the one or more processors are configured to identify one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction. Thereafter, the one or more processors are configured to send one or more messages based on the monitoring. In some non-limiting embodiments or aspects, the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful and that the other of the first transaction and the at least one subsequent transaction was discarded, wherein the other transaction was discarded by at least one of the sending PSP server and the receiving PSP server based on the one or more messages.

[0015] In some non-limiting embodiments or aspects, the present disclosure discloses a non-transitory computer-readable medium comprising instructions stored thereon that, when processed by one or more processors, cause a sender payment service provider (PSP) server to manage pending transactions. The one or more processors are configured to identify a first transaction conducted from a sender to a recipient via a recipient PSP server via the sender PSP server. In some non-limiting embodiments or aspects, a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the recipient PSP server. Furthermore, the one or more processors are configured to detect at least one subsequent transaction from the sender to the recipient while the first transaction is pending. Furthermore, the one or more processors are configured to compare transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient. Furthermore, the one or more processors are configured to identify one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction. Thereafter, the one or more processors are configured to send one or more messages based on the monitoring. In some non-limiting embodiments or aspects, the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful and that the other of the first transaction and the at least one subsequent transaction was discarded, wherein the other transaction was discarded by at least one of the sending PSP server and the receiving PSP server based on the one or more messages.

[0016] Additional non-limiting embodiments or aspects are set forth in the following numbered clauses.

[0017] Article 1: A computer-implemented method comprising: identifying, by a sender payment service provider (PSP) server, a first transaction from a sender via a receiver PSP server to a receiver via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the receiver PSP server; detecting, by the sender PSP server, while the first transaction is pending, at least one subsequent transaction from the sender to the receiver; comparing, by the sender PSP server, transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine whether the first transaction and the at least one subsequent transaction are pending. The transaction is associated with a single payment made by the sender to the recipient; the sender PSP server identifies one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and the sender PSP server sends one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful and discards the other transactions of the first transaction and the at least one subsequent transaction, wherein the other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0018] Clause 2: The computer-implemented method of Clause 1, wherein the transaction parameter may be at least one of: a transaction identifier (ID), an amount, a currency, a mobile phone number of the sender and the recipient, a timestamp, a unique identification number of the sender and the recipient, a device fingerprint data of the sender, or any combination thereof.

[0019] Clause 3: A computer-implemented method according to Clause 1 or Clause 2, further comprising assigning a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when the status of the corresponding transaction is updated to pending by the RTP server in a payment response code, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, and wherein the payment response code is generated based on a response provided by the recipient PSP server.

[0020] Clause 4: The computer-implemented method of any of Clauses 1 to 3, wherein the status of the first transaction and the at least one subsequent transaction is updated to pending in the payment response code when one of the following occurs: the first transaction and the at least one subsequent transaction are initiated and are being processed; and no response for the corresponding transaction is received from the recipient PSP server within a predetermined time.

[0021] Clause 5: The computer-implemented method of any of Clauses 1 to 4, wherein processing of the first transaction and the at least one subsequent transaction is performed concurrently by the sender PSP server.

[0022] Clause 6: The computer-implemented method of any of Clauses 1-5, wherein the one or more messages are updated using a typeless command along with the unique pending ID of a successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0023] Article 7: A sender payment service provider (PSP) server comprising one or more processors and a memory communicatively coupled to the one or more processors, wherein the memory stores processor-executable instructions that, when executed, cause the one or more processors to: identify a first transaction from a sender to a recipient via a recipient PSP server via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the recipient PSP server; while the first transaction is pending, detect at least one subsequent transaction from the sender to the recipient; and compare transaction parameters of the at least one subsequent transaction to a transaction parameter of the at least one subsequent transaction. The method comprises the steps of: comparing transaction parameters of the first transaction with the transaction parameters of the at least one subsequent transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful and discarding the other transactions of the first transaction and the at least one subsequent transaction, wherein the other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0024] Clause 8: The sender PSP server of Clause 7, further comprising assigning, by the one or more processors, a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when the status of the corresponding transaction is updated to pending by the RTP server in a payment response code, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, wherein the payment response code is generated based on a response provided by the recipient PSP server.

[0025] Article 9: The sender PSP server according to Article 7 or Article 8, wherein the one or more processors update the status of the first transaction and the at least one subsequent transaction to pending in the payment response code when one of the following occurs: the first transaction and the at least one subsequent transaction are initiated and are being processed; and no response for the corresponding transaction is received from the recipient PSP server within a predetermined time.

[0026] Clause 10: The sender PSP server of any of Clauses 7 to 9, wherein the one or more processors process the first transaction and the at least one subsequent transaction concurrently.

[0027] Clause 11: The sender PSP server of any of Clauses 7 to 10, wherein the one or more processors update one or more messages using a typeless command along with a unique pending ID of a successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0028] Article 12: A non-transitory computer-readable medium comprising instructions stored thereon that, when processed by one or more processors, cause a sender payment service provider (PSP) server to perform operations comprising: identifying a first transaction conducted from a sender via a receiver PSP server to a receiver via the sender PSP server, wherein a real-time payment (RTP) server facilitates the transaction between the sender PSP server and the receiver PSP server; detecting at least one subsequent transaction between the sender and the receiver while the first transaction is pending; comparing one or more transaction parameters of the at least one subsequent transaction with one or more transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the receiver; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; and sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful and discarding the other of the first transaction and the at least one subsequent transaction, wherein the other transaction is discarded by at least one of the sender PSP server and the receiver PSP server based on the one or more messages.

[0029] Clause 13: The non-transitory computer-readable medium of Clause 12, further comprising assigning, by the one or more processors, a unique pending identifier (ID) to each of the first transaction and the at least one subsequent transaction when a status of the corresponding transaction is updated to pending in a payment response code by the RTP server, wherein the RTP server generates the payment response code in response to receiving a payment request code from the sender PSP server, wherein the payment response code is generated based on a response provided by the recipient PSP server.

[0030] Clause 14: The non-transitory computer-readable medium of Clause 12 or Clause 13, wherein the one or more processors update the status of the first transaction and the at least one subsequent transaction as pending in the payment response code upon one of the following: the first transaction and the at least one subsequent transaction are initiated and are being processed; and no response for the corresponding transaction is received from the recipient PSP server within a predetermined time.

[0031] Clause 15: The non-transitory computer-readable medium of any of Clauses 12-14, wherein the one or more processors process the first transaction and the at least one subsequent transaction concurrently.

[0032] Clause 16: The non-transitory computer-readable medium of any of Clauses 12-15, wherein the one or more processors utilize a typeless command to update one or more messages along with a unique pending ID of a successful transaction, wherein the one or more messages are in accordance with the ISO 8583 standard.

[0033] The foregoing summary is illustrative only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The novel features and characteristics of the present disclosure are set forth in the appended claims. However, the disclosure itself, as well as the preferred mode of use, additional objects and advantages thereof, may best be understood with reference to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings. The accompanying drawings, which are incorporated into and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the principles disclosed. In the figures, the leftmost digit of a reference number identifies the figure in which the reference number first appears. One or more non-limiting embodiments will now be described by way of example only and with reference to the accompanying drawings, wherein like reference numerals represent similar elements, and in the drawings:

[0035] Figure 1is an exemplary platform for performing person-to-person (P2P) real-time transactions according to some non-limiting embodiments or aspects of the present disclosure;

[0036] Figure 2 is an exemplary flow chart for managing pending transactions according to some non-limiting embodiments or aspects of the present disclosure;

[0037] Figure 3 is an exemplary flow chart for determining a transaction status as pending according to some non-limiting embodiments or aspects of the present disclosure;

[0038] Figure 4A is an exemplary table including an International Organization for Standardization (ISO) message format according to some non-limiting embodiments or aspects of the present disclosure;

[0039] Figures 4B to 4E An exemplary table illustrating data fields associated with a first position, a second position, a third position, and a fourth position of a message type indicator (MTI) identifier according to some non-limiting embodiments or aspects of the present disclosure is shown;

[0040] Figure 5 is an exemplary sequence diagram for managing pending transactions according to some non-limiting embodiments or aspects of the present disclosure;

[0041] Figures 6A to 6D is an exemplary sender PSP application according to some non-limiting embodiments or aspects of the present disclosure;

[0042] Figure 6E is an exemplary recipient PSP application according to some non-limiting embodiments or aspects of the present disclosure; and

[0043] Figure 7 is a block diagram of a general computer system for managing pending transactions according to an embodiment of the present disclosure.

[0044] It will be understood by those skilled in the art that any block diagram herein represents a conceptual view of an illustrative system embodying the principles of the present subject matter. Similarly, it will be understood that any flow charts, flowcharts, state transition diagrams, pseudocode, and the like represent various processes that can be substantially represented in a computer-readable medium and executed by a computer or processor, whether or not such a computer or processor is explicitly shown. Although each of the figures illustrates a specific embodiment for purposes of illustrating clear examples, other embodiments may omit, add, reorder, and / or modify any of the elements shown in the figures. DETAILED DESCRIPTION

[0045] In this document, the term “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0046] In the following detailed description of the embodiments of the present disclosure, reference is made to the accompanying drawings which form a part of the present disclosure, and specific embodiments in which the present disclosure may be practiced are shown in the accompanying drawings by way of illustration. However, it should be understood that it is not intended to limit the present disclosure to the disclosed forms, but on the contrary, the present disclosure is intended to cover all modifications, equivalents, and alternatives within the spirit and scope of the present disclosure. It should be understood that other embodiments may be utilized and may be changed without departing from the scope of the present disclosure. Therefore, the following description should not be considered to have a restrictive meaning.

[0047] The terms "comprises" or "comprising" or any other variations thereof are intended to cover a non-exclusive inclusion, such that an arrangement, apparatus, or method that comprises a list of components or steps includes not only those components or steps but may also include other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, the listing of one or more elements in a system or device following the phrase "comprises..." does not exclude the presence of other or additional elements in the system or method without further constraints.

[0048] The terms "includes" or "including" or any other variations thereof are intended to encompass a non-exclusive inclusion, such that an arrangement, apparatus, or method that includes a list of components or steps includes not only those components or steps, but may also include other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, the listing of one or more elements in a system or device following "includes..." does not, without further constraints, exclude the presence of other or additional elements in the system or method.

[0049] As used herein, aspects, components, elements, structures, actions, steps, functions, instructions, etc. should not be understood as being critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more projects and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more projects (e.g., related projects, unrelated projects, a combination of related projects and unrelated projects, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one project, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. In addition, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on". Unless explicitly specified otherwise, the term "some non-limiting embodiments or aspects" means "one or more (but not all) embodiments or aspects of the present disclosure". The description of some non-limiting embodiments or aspects with several components communicating with each other does not mean that all these components are needed. On the contrary, various optional components are described to illustrate various possible embodiments of the present disclosure.

[0050] When a single device or article is described herein, it will be apparent that more than one device / article (whether or not cooperating) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not cooperating), it will be apparent that a single device / article may be used in place of the more than one device or article, or a different number of devices / articles may be used in place of the number of devices or procedures shown. The functionality and / or features of a device may alternatively be embodied by one or more other devices that are not explicitly described as having such functionality / features. Thus, other embodiments of the present disclosure need not include the device itself.

[0051] As used herein, the terms "communication," "transmit," "send," and / or "receive" may refer to the receipt, acceptance, transmission, delivery, provision, etc. of information (e.g., data, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is capable of receiving information from the other unit and / or sending information to the other unit, directly or indirectly. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. In addition, although the information sent may be modified, processed, relayed, and / or routed between the first and second units, the two units may also communicate with each other. For example, a first unit may communicate with a second unit even if the first unit passively receives information and does not actively send information to the second unit. As another example, a first unit may communicate with a second unit if at least one intermediate unit (e.g., a third unit located between the first and second units) processes information received from the first unit and transmits the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (eg, a data packet, etc.) that includes data. It should be understood that many other arrangements are possible.

[0052] As used herein, the terms "server" and / or "processor" may refer to one or more computing devices or computing units, such as processors, storage devices, and / or similar computer components, that communicate with client devices and / or other computing devices over a network, such as the Internet or a private network, and, in some examples, facilitate communication between other servers and / or client devices. It should be understood that various other arrangements are possible. As used herein, the term "system" may refer to one or more computing devices or combinations of computing devices, such as, but not limited to, processors, servers, client devices, software applications, and / or other similar components. In addition, as used herein, references to "server" or "processor" may refer to a previously listed server and / or processor that is recited as performing a previous step or function, a different server and / or processor, and / or a combination of servers and / or processors. For example, as used in the specification and claims, a first server and / or first processor recited as performing a first step or function may refer to the same or a different server and / or processor that is recited as performing a second step or function.

[0053] Non-limiting embodiments of the present disclosure relate to a method, a sender payment service provider (PSP) server, and a non-transitory computer-readable medium for managing pending transactions. A first transaction from a sender to a recipient via a recipient PSP server is identified. A real-time payment (RTP) server facilitates the transaction between the sender PSP server and the recipient PSP server. While the first transaction is pending, at least one subsequent transaction from the sender to the recipient is detected. Transaction parameters of the at least one subsequent transaction are compared with transaction parameters of the first transaction to determine that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient. One of the first transaction and the at least one subsequent transaction is identified as successful by monitoring the first transaction and the at least one subsequent transaction. Based on the monitoring, one or more messages are sent to the sender PSP server and the recipient PSP server. The one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful, and the other of the first transaction and the at least one subsequent transaction is discarded. The other transactions are discarded by at least one of the sender PSP server and the recipient PSP server based on the one or more messages.

[0054] In the following detailed description of the embodiments of the present disclosure, reference is made to the accompanying drawings which form a part of the present disclosure and in which are shown by way of illustration specific embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it is understood that other embodiments may be utilized and changes may be made without departing from the scope of the present disclosure. Therefore, the following description should not be construed in a limiting sense.

[0055] Figure 1 A non-limiting embodiment or aspect of a platform (100) for performing real-time person-to-person (P2P) transactions according to the present disclosure is presented. The platform (100) is provided as a service to a sender (101) and a receiver (105) to enable users (senders and receivers) to perform transactions. A non-limiting embodiment of the platform (100) is described in connection with online payment transactions. The present disclosure relates to real-time P2P transactions. The present disclosure relates to online transactions conducted using a P2P payment application.

[0056] In some non-limiting embodiments or aspects, the platform (100) includes a sender PSP server (102), an RTP server (103), and a receiver PSP server (104). The sender (101) may be a first person who transfers funds from a first bank account associated with the first person to a second person associated with a second bank account. The PSP is an entity that provides payment services to users. The sender PSP server (102) is an entity associated with the sender (101) that provides payment services to the sender (101) for sending amounts. The sender PSP server (102) may be associated with the sender's (101) bank. The sender PSP server (102) is a backend service associated with the sender's (101) bank. The sender PSP application (not shown) provides frontend services for the sender (101). The RTP server (103) allows funds to be transferred between a sender (101) and a receiver (105) via a sender PSP server (102) and a receiver PSP server (104) respectively. For example, the RTP server (103) may be a Unified Payments Interface (UPI) server.

[0057] In some non-limiting embodiments or aspects, the RTP server (103) may implement any type of instant payment service. In some non-limiting embodiments or aspects, funds may be transferred using a virtual payment address (VPA). Whenever a user initiates a transaction, the RTP server (103) does not need to enter bank details or other sensitive information. The receiving PSP server (104) may be associated with the bank of the receiving party (105). The receiving PSP server (104) is a backend service associated with the bank of the receiving party (105). The receiving PSP application (not shown) provides front-end services for the receiving party (105). The sending PSP application and the receiving PSP application use the RTP library to facilitate payments. The receiving party (105) may be the person receiving funds from the sending party (101).

[0058] In some non-limiting embodiments or aspects, when the funds transfer is automated, the sender (101) and the receiver (105) can be two different systems. In some non-limiting embodiments or aspects, the sender PSP server (102) and the receiver PSP server (104) can be payment gateways connected to multiple banking entities, thereby facilitating transactions for users (sender (101) and receiver (105)) with ease.

[0059] The RTP server (103) facilitates two types of transactions, namely, payment request and collection request. A payment request (and / or payment request code) is a transaction in which the sender (101) uses an account number, mobile number, Aadhaar TMA collection request is a transaction in which the recipient (105) pulls funds from the sender (101) using a VPA. This disclosure is explained with reference to payment requests (and / or payment request codes). However, this disclosure is not limited to payment requests (and / or payment request codes) alone, and those skilled in the art will also understand the operation of payment collections.

[0060] Figure 2 is a flow chart illustrating a method (200) for managing pending transactions according to some non-limiting embodiments or aspects of the present disclosure. Figure 2 As shown in , the method (200) may include one or more steps. The method (200) may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, process steps, modules, and functions that perform specific functions or implement specific abstract data types.

[0061] The order in which the method (200) is described is not to be construed as limiting, and any number of the described method blocks may be combined in any order to implement the method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0062] At step (201), the method includes identifying, by a sender PSP server (102), a first transaction from a sender (101) to a receiver (105) via a receiver PSP server (104) via the sender PSP server (102), wherein an RTP server (103) facilitates the transaction between the sender PSP server (102) and the receiver PSP server (104). The sender PSP server (102) may identify the first transaction from the sender (101) to the receiver (105). The first transaction may be associated with a transaction ID, an amount, a currency, a mobile phone number of the sender (101) and the receiver (105), a timestamp, a unique identification number of the sender (101) and the receiver (105), a device fingerprint data of the sender (101), or any combination thereof. The first transaction may have a success, pending, or failure status. In some non-limiting embodiments or aspects, the RTP server (103) may send an indication message to the sender PSP server (102) indicating that the transaction is successful, pending, or failed. In some non-limiting embodiments or aspects, if the status of the first transaction is pending, a unique pending ID is assigned to the first transaction. Figure 3, shows an exemplary flow chart (300) for determining the status of a transaction as pending. At box (301), the sender PSP server (102) initiates the transaction when the sender (101) enters the required details, such as transaction amount, recipient details, password, etc. At box (302), the RTP server (103) determines whether an explicit response to the transaction is received from the recipient PSP server (104).

[0063] The RTP server (103) may determine the status of the transaction based on the response from the recipient PSP server (104). The transaction status may be one of success, failure, or pending. In some non-limiting embodiments or aspects, success and failure status may be clear states, while statuses such as timeout, not connected to the server, transaction pending, and connection loss may be indeterminate states. When the status is clear, the RTP server (103) updates the payment response code to success or failure at box (304). Even if a response is received from the recipient PSP server (104), the status of the transaction may be failure due to various reasons such as Internet connection, data input error, etc. The RTP server (103) waits for a predetermined time for the response.

[0064] At block (303), if no response is received within a predetermined time or after a timeout, or if the transaction status at block (304) is indeterminate, the RTP server (103) may update the transaction status to pending in the payment response code. Return to Reference Figure 2 , the RTP server (103) may update the status of the first transaction in the payment response code. In a first example (not shown), the sender (101) may be a customer and the receiver (105) may be a merchant. The first transaction may involve transferring funds from the customer to the merchant. The customer may transfer an amount of $300 to the merchant. Due to the internet connection, the first transaction may be pending. The unique pending ID may be XXXP.

[0065] At step (202), the method includes detecting, by the sender PSP server (102), at least one subsequent transaction from the sender (101) to the receiver (105) while the first transaction is pending. The sender PSP server (102) may detect the at least one subsequent transaction from the sender (101) to the receiver (105). In the present disclosure, the at least one subsequent transaction from the sender (101) to the receiver (105) refers to a transaction performed by the sender (101) to the receiver (105) while the first transaction from the sender (101) to the receiver (105) is pending. Referring to the first example, since the status of the first transaction is pending due to the internet connection, the user may perform a subsequent transaction with the merchant for the same amount of $300.

[0066] In step (203), the method includes comparing, by the sender PSP server (102), transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction to determine whether the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender (101) to the receiver (105). The transaction parameters may be at least one of the following: transaction ID, amount, currency, mobile phone numbers of the sender (101) and the receiver (105), timestamp, unique identification numbers of the sender (101) and the receiver (105), device fingerprint data of the sender (101), or any combination thereof. The sender PSP server (102) may compare the transaction parameters of the first transaction and the at least one subsequent transaction to determine whether both transactions are associated with a single payment made by the sender (101) to the receiver (105).

[0067] Referring to the first example, the transaction parameters for the first transaction may be: transaction ID: XXX0, amount: 300, currency: INR, user's mobile number: 99XXXXXX01, merchant's mobile number: 99XXXXXX11, timestamp: 10:00 AM, user's unique ID: XXXXXXXXXXXX1, merchant's unique ID: XXXXXXXXXXX2, 4-digit personal identification number (PIN): XXX3 of the user's mobile phone. The transaction parameters for a subsequent transaction may be: transaction ID: XXX1, amount: 300, currency: INR, user's mobile number: 99XXXXXX01, merchant's mobile number: 99XXXXXX11, timestamp: 10:02 AM, user's unique ID: XXXXXXXXXXX1, merchant's unique ID: XXXXXXXXXXX2, 4-digit personal identification number (PIN): XXX3 of the user's mobile phone. The transaction ID and timestamp are different, while the other transaction parameters for the transaction associated with a single payment from the user to the merchant remain the same. The sender PSP server (102) compares the transaction parameters of the first transaction and the subsequent transaction to determine whether both transactions are associated with a single payment from the user to the merchant. The sender PSP server (102) may also assign a unique pending ID XXXP to the subsequent transaction to identify that the first transaction and the subsequent transaction are associated with a single payment from the user to the merchant. In another embodiment, the sender PSP server (102) may group the pending transactions associated with the single payment together by assigning the unique pending IDs as 10.1, 10.2...10.n, 10 indicating a single payment from the user to the merchant. In another embodiment, all transaction IDs associated with the single payment may be stored in a tuple. It will be appreciated by those skilled in the art that any other method may be used to group and identify transactions associated with the single payment, and the scope of this disclosure is not limited to the above method.

[0068] At step (204), the method includes, by the sender PSP server (102), identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction. In some non-limiting embodiments or aspects, the first transaction and the at least one subsequent transaction may be processed simultaneously by the sender PSP server (102). The RTP server (103) updates the payment response code based on the response from the receiver PSP server (104). The payment response code provides the transaction status as successful, pending, or failed. When the response received from the receiver PSP server (104) is a successful transaction, the RTP server (103) updates the payment response code to successful and sends a success indication message to the sender PSP server (102). The sender PSP server (102) may determine a unique pending ID associated with the transaction based on the transaction ID of the transaction.

[0069] In some non-limiting embodiments or aspects, the indication message may be in accordance with the International Organization for Standardization (ISO) 8583 standard. Referring to a first example, a first transaction from a user to a merchant may be successful, or a subsequent transaction from a user to a merchant may be successful. The RTP server (103) may update the payment response code of the first transaction or the subsequent transaction to success based on a response from the receiving PSP server (104), and notify the sending PSP server (102) of this message.

[0070] At step (205), the method includes sending one or more messages by the sender PSP server (102) based on the monitoring. The one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful and that the other transactions in the first transaction and the at least one subsequent transaction are discarded. The other transactions are discarded by at least one of the sender PSP server (102) and the receiver PSP server (104) based on the one or more messages. After the first transaction or the at least one subsequent transaction is successful, the sender PSP server (102) may determine a unique pending ID associated with the transaction based on the transaction ID of the transaction, as mentioned in the above paragraph. In some non-limiting embodiments or aspects, when one of the first transaction or the at least one subsequent transaction is successful, the one or more messages are updated using a typeless command together with the unique pending ID of the successful transaction.

[0071] The sender PSP server (102) sends the one or more messages to indicate a successful transaction and discard all other transactions. The other transactions are discarded by the sender PSP server (102) or the recipient PSP server (104) based on the one or more messages. In some non-limiting embodiments or aspects, when the sender PSP server (102) discards the other transactions, the sender PSP server (102) sends a discard message to the recipient PSP server (104) to notify the sender (101) and the recipient (105) of the end of processing of the single payment associated with the sender (101) and the recipient (105), and vice versa (i.e., when the recipient PSP server discards the other transactions).

[0072] In some non-limiting embodiments or aspects, transactions associated with a single payment from a sender (101) to a recipient (105) are assigned the same pending ID. The sender PSP server (102) or the recipient PSP server (104) discards all transactions from the sender (101) to the recipient (105) except for successful transactions. When the pending ID is the same for all transactions associated with the single payment, the sender PSP server (102) or the recipient PSP server (104) may discard the successful transaction based on the transaction ID of the successful transaction. In another embodiment, when the assigned pending ID is different for each pending transaction, the sender PSP server (102) or the recipient PSP server (104) may discard the successful transaction based on the pending ID of the successful transaction.

[0073] In some non-limiting embodiments or aspects, the one or more messages are in accordance with the ISO 8583 standard. ISO 8583 defines a transaction message structure for performing transactions. Referring to a first example, a first transaction from a user to a merchant with transaction ID XXX0 may succeed sometime after a subsequent transaction is performed, and the sender PSP server (102) or the recipient PSP server (104) may discard the subsequent transaction. The subsequent transaction is discarded so that if the subsequent transaction becomes successful after a certain time, the user may lose funds.

[0074] Now refer to Figure 4A , shows an example of ISO 8583 message format. Figure 4A As shown, one or more messages generated according to ISO 8583 may include a message type identifier (MTI), a major bitmap, a minor bitmap, and data elements. MTI is a four-digit field that describes the category and function of each message. There are few versions of the ISO 8583 standard, which are: ISO 8583:1987, ISO 8583:1993, and ISO 8583:2003. The first of the four digits indicates the version of ISO 8583. Figure 4BThe first digit indicating the version of the ISO standard is shown in FIG. As shown in the figure, when the first digit of the four-digit number is 0, the version is ISO 8583:1987. Similarly, when the first digit of the four-digit number is 1, the version is ISO 8583:1993, and when the first digit of the four-digit number is 2, the version is ISO 8583:2003.

[0075] Figure 4C The field associated with the second bit of the MTI is shown in FIG. As shown in the figure, the second bit can take values ​​0 to 9. Figure 4C As can be seen in , for values ​​0 and 9, the MTI field is reserved for ISO. Figure 4D The fields associated with the third bit of the MTI are shown. Figure 4D As can be seen in , for values ​​8 and 9, the MTI field is reserved for ISO.

[0076] In some non-limiting embodiments or aspects, the sender PSP server (102) may include a typeless command and a unique pending ID for the successful transaction in one or more messages indicating a successful transaction. In some non-limiting embodiments or aspects, the second of the four bits may indicate a successful transaction in one or more messages. For example, a value of 0 in the second bit may be defined as indicating a successful transaction. In another example, a value of 9 in the second bit may be defined as indicating a successful transaction. One of ordinary skill in the art will appreciate that the command indicating a successful transaction in a plurality of pending transactions may be indicated using various commands and in various fields of the ISO 8583 message format.

[0077] In some non-limiting embodiments or aspects, the third of the four bits can indicate a successful transaction in one or more messages. For example, a value of 8 in the third bit can be defined as indicating a successful transaction. In another example, a value of 9 in the third bit can be defined as indicating a successful transaction. In some non-limiting embodiments or aspects, a field is defined for all values ​​of the fourth bit. Therefore, using the fourth bit may not identify a successful transaction. Figure 4E The fields associated with the fourth bit of the MTI are shown.

[0078] In some non-limiting embodiments or aspects, a bitmap is a field that indicates which data elements may be present or absent in a transaction message. A transaction message includes at least one bitmap, referred to as a primary bitmap, which indicates which of data elements 1 to 64 are present. A secondary bitmap may also be present, and this bitmap indicates which of data elements 65 to 128 are present. Furthermore, a third bitmap may be used to indicate the presence or absence of fields 129 to 192. In some non-limiting embodiments or aspects, a typeless command, along with a unique pending ID for a successful transaction, may be accommodated in the first 1 to 64 bits of a data element or in bits 65 to 128 of a data element. Therefore, the primary and secondary bitmaps may be updated to indicate the typeless command and the unique pending ID for a successful transaction in one or more messages. The bitmap value indicates whether the typeless command, along with the unique pending ID for a successful transaction, is present in bits 1 to 64 or bits 65 to 128.

[0079] In some non-limiting embodiments or aspects, the data elements are all fields that include transaction information. ISO 8583:1997 includes up to 128 data elements (wherein a message will have up to 2 bitmap fields). Later versions include up to 192 data elements (wherein a message will have up to 3 bitmap fields). Each field (data element) has a specific meaning and format. In some non-limiting embodiments or aspects, the data elements may also include untyped commands and unique pending IDs for successful transactions. For example, data fields 46, 47, 48, 55-63, 105-119 may be used. In another embodiment, field 128 is used for a message authentication code in a conventional system. According to the present disclosure, field 128 may be used for untyped commands and unique pending IDs for successful transactions.

[0080] Now refer to Figure 5, which shows an exemplary sequence diagram (500) for managing pending transactions. For example, a sender (101) causes a first transaction to be facilitated by an RTP server (103) via a sender PSP server (102) to a receiver (105) via a receiver PSP server (104). The sender PSP server (102) sends a payment request (and / or a payment request code) along with transaction parameters to the receiver PSP server (104) via the RTP server (103). The first transaction is processed, and the RTP server (103) waits for a payment response for the first transaction from the receiver PSP server (104). If no response is received, the RTP server (103) updates the status of the first transaction to pending in the payment response code after a timeout (predefined time period). The RTP server (103) sends an indication message as pending to the sender PSP server (102). The sender PSP server (102) assigns a unique pending ID to the first transaction. Since the first transaction is pending, the sender (101) can conduct a subsequent transaction with the receiver (105).

[0081] The sender PSP server (102) sends a payment request (and / or a payment request code) along with transaction parameters to the receiver PSP server (104) via the RTP server (103). The sender PSP server (102) compares the transaction parameters of the first transaction with the transaction parameters of the subsequent transaction. The sender PSP server (102) determines that the first transaction and the subsequent transaction are associated with a single payment made by the sender (101) to the receiver (105). When processing the subsequent transaction, the RTP server (103) waits for a payment response for the subsequent transaction from the receiver PSP server (104). If there is no response to the subsequent transaction within a predefined time period, then after a timeout, the RTP server (103) updates the status of the subsequent transaction to pending in the payment response code. The RTP server (103) sends an indication message as pending to the sender PSP server (102). The sender PSP server (102) assigns a unique pending ID to the subsequent transaction.

[0082] While the first transaction is pending, the sender (101) may perform multiple transactions. Transactions associated with a single payment cycle until the transaction is successful. The sender PSP server (102) simultaneously monitors the multiple transactions to identify successful transactions. When one of the multiple transactions is successful, the sender PSP server (102) sends one or more messages. When a response is received from the recipient PSP server (104), the transaction may be successful. After the transaction is successful, the sender PSP server (102) or the recipient PSP server (104) discards all other transactions. The sender's (101) balance is updated.

[0083] Figures 6A to 6D An exemplary sender PSP application (601) is shown, and Figure 6E An exemplary receiving PSP application (602) is shown. Figure 6A As shown in FIG, the sender PSP application (601) may provide options such as "Home", "Transfer" and "History". The sender (101) may select the "Transfer" option. The sender PSP application (601) may provide fields such as the recipient number, the recipient name and the amount entered by the sender (101). In some non-limiting embodiments or aspects, the sender (101) may only provide the recipient name, and the recipient number may be obtained by the sender PSP application (601) from the sender's (101) contacts.

[0084] The sender (101) may make a first transaction (e.g., $5,000) to the receiver (105). The sender (101) may enter the receiver number (e.g., 98XXXXXX01), the receiver name (e.g., ABC), and the amount (e.g., 5,000). After entering the details for making the transfer, the sender (101) may select the "Send" option to initiate the transaction. The first transaction may be pending, and the status of the first transaction may be displayed, such as Figure 6B As shown. The first transaction may be associated with a transaction ID (e.g., XXX0) and a timestamp (e.g., 12:15 01 / 01 / 2020). After the first transaction, the sender (101) may display a balance of $65,000. The sender PSP application (601) may display other details, such as that the transaction is pending for the payment to ABC. Because the first transaction is pending, the sender (101) may make a subsequent transaction to the recipient (105) for the same amount of $5,000.

[0085] like Figure 6C As shown, the subsequent transaction may be associated with a transaction ID (e.g., XXX1) and a timestamp (e.g., 13:15 01 / 01 / 2020). After the subsequent transaction, the sender's (101) balance may be displayed as $60,000. The sender PSP application (601) may display other details, such as that the transaction is pending for payment to ABC. The sender PSP server (102) may monitor both the first transaction and the subsequent transaction to identify successful transactions. Figure 6D As shown, a subsequent transaction with transaction ID XXX1 may become successful at timestamp 14:00. The sender PSP server (102) or the receiver PSP server (104) may discard the first transaction and update the sender balance to 65,000. Figure 6E A receiving PSP application (602) is shown indicating an amount received from a sender (101) (eg, XYZ).

[0086] In a non-limiting example, a first person may initiate a first transaction. The first person may send $500 to a second person. The sender PSP server (102) may receive an indication message from the RTP server (103) that the first transaction is pending. The first person may initiate a subsequent transaction for the same amount of $500 to the second person. The sender PSP server (102) may receive an indication message from the RTP server (103) that the second transaction is also pending. The sender PSP server (102) may compare transaction parameters of the first transaction and the second transaction to determine that the first transaction and the second transaction are associated with a single payment from the first person to the second person. The first person may initiate a third transaction for the same amount of $500 to the second person. The sender PSP server (102) may receive an indication message from the RTP server (103) that the third transaction is also pending.

[0087] The sender PSP server (102) may compare transaction parameters of the first transaction and the third transaction to determine that the first transaction and the third transaction are associated with a single payment from the first person to the second person. The first person may initiate a fourth transaction of the same amount of $500 to the second person. The sender PSP server (102) may receive an indication message from the RTP server (103) that the fourth transaction is also pending. The sender PSP server (102) may compare transaction parameters of the first transaction and the fourth transaction to determine that the first transaction and the fourth transaction are associated with a single payment from the first person to the second person. The sender PSP server (102) may process the first transaction, the second transaction, the third transaction, and the fourth transaction simultaneously. The sender PSP server (102) may receive an indication message indicating that the third transaction was successful some time after processing the third transaction. The sender PSP server (102) sends one or more messages to discard the first transaction, the second transaction, and the fourth transaction. The sender PSP server (102) or the receiver PSP server (104) discards the first transaction, the second transaction, and the fourth transaction and updates the sender's balance.

[0088] The present disclosure is not limited to online transactions. For example, the present disclosure can be used at a point of sale (POS) machine in a store. When a user conducts a first transaction using the POS machine, and while payment is pending, the user can conduct subsequent transactions. Here, a merchant server associated with the POS machine can determine that the subsequent transaction and the first transaction are related to a single payment, and can assign a pending ID to both the first transaction and the subsequent transaction. In addition, the merchant server can perform Figure 2 Steps 201 to 205 are to determine the successful transaction in the first transaction and subsequent transactions, and to abandon another transaction. In addition, the amount of redundant transactions can be credited to the user's credit.

[0089] The present disclosure provides an automated way to discard multiple pending (redundant) transactions after one transaction from multiple transactions succeeds. The present disclosure provides a method to intelligently identify and manage multiple transactions of a user associated with a single payment. The present disclosure avoids debiting user funds multiple times.

[0090] Computer system

[0091] Figure 7 A block diagram of an exemplary computer system (700) for implementing embodiments consistent with the present disclosure is shown. In some non-limiting embodiments or aspects, the computer system (700) is used to implement the generation of sentiment-based summaries for user review. The computer system (700) may include a central processing unit ("CPU" or "processor") (702). The processor (702) may include at least one data processor. The processor (702) may include a special-purpose processing unit, such as an integrated system (bus) controller, a memory management control unit, a floating point unit, a graphics processing unit, a digital signal processing unit, etc.

[0092] The processor (702) can be arranged to communicate with one or more input / output (I / O) devices (not shown) via an I / O interface (701). The I / O interface (701) can use communication protocols / methods such as, but not limited to, audio, analog, digital, mono, RCA, stereo, IEEE-1394, serial bus, universal serial bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital video interface (DVI), high-definition multimedia interface (HDMI), radio frequency (RF) antenna, S-Video, VGA, IEEE 802.n / b / g / n / x, Cellular (e.g., Code Division Multiple Access (CDMA), High Speed ​​Packet Access (HSPA+), Global System for Mobile Communications (GSM), Long Term Evolution (LTE), etc.

[0093] Using the I / O interface (701), the computer system (700) can communicate with one or more I / O devices. For example, the input device (710) can be an antenna, a keyboard, a mouse, a joystick, an (infrared) remote control, a camera, a card reader, a fax machine, a dongle, a biometric reader, a microphone, a touch screen, a touchpad, a trackball, a stylus, a scanner, a storage device, a transceiver, a video device / source, etc. The output device (711) can be a printer, a fax machine, a video display (e.g., a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED), a plasma, a plasma display panel (PDP), an organic light emitting diode display (OLED), etc.), an audio speaker, etc.

[0094] The processor (702) can be arranged to communicate with the communication network (709) via the network interface (703). The network interface (703) can communicate with the communication network (709). The network interface (703) can use connection protocols including, but not limited to, direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc. The communication network (709) can include, but not limited to, direct interconnection, local area network (LAN), wide area network (WAN), wireless network (e.g., using wireless application protocol), the Internet, etc. The network interface (703) can use connection protocols including, but not limited to, direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc.

[0095] The communication network (709) includes but is not limited to direct interconnection, e-commerce network, peer-to-peer (P2P) network, local area network (LAN), wide area network (WAN), wireless network (e.g., using wireless application protocol), Internet, The first network and subsequent networks may be dedicated networks or shared networks, which represent an association of different types of networks that communicate with each other using various protocols, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), etc. In addition, the first network and subsequent networks may include various network devices, including routers, bridges, servers, computing devices, storage devices, etc.

[0096] In some non-limiting embodiments or aspects, the processor (702) may be arranged to communicate with the memory (705) (eg, Figure 7 The storage interface (704) can be connected to a memory (705), including but not limited to a memory drive, a removable optical drive, etc., and the memory uses a connection protocol such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, USB, Fibre Channel, Small Computer System Interface (SCSI), etc. The memory drive can also include a drum, a magnetic disk drive, a magneto-optical disk drive, an optical disk drive, a redundant array of independent disks (RAID), a solid-state memory device, a solid-state drive, etc.

[0097] The memory (705) may store a series of program or database components, including but not limited to a user interface (706), an operating system (707), a web browser (708), etc. In some non-limiting embodiments or aspects, the computer system (700) may store user / application data, such as data, variables, records, etc., as described in the present disclosure. Such a database may be implemented as a fault-tolerant, relational, scalable, secure database, such as or

[0098] The operating system (707) can facilitate resource management and operation of the computer system (700). Examples of operating systems include, but are not limited to, Apple OS X, UNIX-like system distributions (e.g., BERKELEYSOFTWARE DISTRIBUTION TM (BSD), FREEBSD TM , NETBSD TM 、OPENBSD TM etc.), LINUXDISTRIBUTIONS TM (For example, RED HAT TM UBUNTU TM 、KUBUNTU TM etc.), IBM TM OS / 2, MICROSOFT (XP TM VISTA TM / 7 / 8,10, etc.), iOS TM 、 Android TM 、 OS, etc.

[0099] In some non-limiting embodiments or aspects, the computer system (700) may implement a program component stored by a web browser (708). The web browser (708) may be a hypertext viewing application, such as INTERNET CHROME TM 、 etc. Secure web browsing can be provided using Hypertext Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. The web browser (708) can utilize AJAX, for example TM 、DHTML TM 、 Application Programming Interface (API), etc. In some non-limiting embodiments or aspects, the computer system (700) may implement a mail server ( Figure 7 The mail server may be an Internet mail server, such as Exchange, etc. Mail servers can use ASP, C++ / C#, .NET、CGI SCRIPTS、 PHP, The mail server can use tools such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), and other communication protocols. In some non-limiting embodiments or aspects, the computer system (700) may implement a program component stored in a mail client. The mail client ( Figure 7 (not shown) may be a mail viewing application, such as MAIL, wait.

[0100] In addition, one or more computer-readable storage media may be used to implement embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory that can store information or data that can be read by a processor. Thus, a computer-readable storage medium can store instructions executed by one or more processors, including instructions that cause the processor to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, e.g., non-transient. Examples include RAM, ROM, volatile memory, non-volatile memory, hard drives, compact disc (CD) ROMs, DVDs, flash drives, magnetic disks, and any other known physical storage media.

[0101] The described operations can be implemented as a method, system, or article of manufacture of software, firmware, hardware, or any combination thereof using standard programming and / or engineering techniques. The described operations can be implemented as code maintained in a "non-transient computer-readable medium," where a processor can read and execute the code from the computer-readable medium. The processor is at least one of a microprocessor and a processor capable of processing and executing queries. Non-transient computer-readable media can include media such as magnetic storage media (e.g., hard drives, floppy disks, magnetic tapes, etc.), optical storage (CD-ROMs, DVDs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, flash memories, firmware, programmable logic, etc.), etc. In addition, non-transient computer-readable media can include all computer-readable media except transient ones. The code implementing the described operations can be further implemented in hardware logic (e.g., integrated circuit chips, programmable gate arrays (PGAs), application-specific integrated circuits (ASICs), etc.).

[0102] An "article of manufacture" includes a non-transitory computer-readable medium and / or hardware logic in which code may be implemented. A device in which code implementing the described operational embodiments is encoded may include the computer-readable medium or the hardware logic. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of this disclosure, and that the article of manufacture may include suitable information-bearing media known in the art.

[0103] Unless expressly specified otherwise, the terms "an embodiment," "one or more embodiments," "some non-limiting embodiments or aspects," and "one embodiment" mean "one or more (but not all) embodiments of the disclosure."

[0104] The description of an embodiment with several components in communication with each other does not imply that all of these components are required. Rather, various optional components are described to illustrate the various possible embodiments of the present disclosure.

[0105] Unless expressly specified otherwise, the terms "including," "comprising," "having," and variations thereof mean "including but not limited to." An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a," "an," and "the" mean "one or more," unless expressly specified otherwise. The description of some non-limiting embodiments or aspects with several components in communication with each other does not mean that all of these components are required. Instead, various optional components are described to illustrate various possible embodiments of the present disclosure.

[0106] Figure 2 、 3The operations shown in Figures 5 and 6 illustrate certain events that occur in a certain order. In alternative embodiments, certain operations may be performed, modified, or removed in a different order. In addition, steps may be added to the logic described above, and the steps may still conform to the described embodiments. In addition, the operations described herein may be performed in sequence, or certain operations may be processed in parallel. However, the operations may be performed by a single processing unit or a distributed processing unit.

[0107] Finally, the language used in this specification is selected primarily for readability and didactic purposes, and is not selected to delineate or limit the subject matter of the present invention. It is therefore intended that the scope of the present disclosure be limited not by this detailed description, but by any claims that issue on applications based on this disclosure. Accordingly, the disclosure of the embodiments of the present disclosure is intended to be illustrative, not limiting, of the scope of the present disclosure, which is set forth in the appended claims.

[0108] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1. A computer-implemented method comprising: identifying, by a sender payment service provider server, a first transaction from a sender to a receiver via a receiver payment service provider server via the sender payment service provider server, wherein a real-time payment server facilitates the transaction between the sender payment service provider server and the receiver payment service provider server; detecting, by the sender payment service provider server, at least one subsequent transaction from the sender to the receiver while the first transaction is pending at the receiver payment service provider server; while the first transaction is pending at the recipient payment service provider server, comparing, by the sender payment service provider server, transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction; determining, by the sender payment service provider server, that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying, by the sender payment service provider server, one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; as well as One or more messages are sent by the sender payment service provider server based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction is successful, and the other of the first transaction and the at least one subsequent transaction is discarded, wherein the other transaction is discarded by at least one of the sender payment service provider server and the recipient payment service provider server based on the one or more messages.

2. The computer-implemented method of claim 1 , wherein the transaction parameter can be at least one of the following: a transaction identifier, an amount, a currency, a mobile phone number of the sender and the recipient, a timestamp, a unique identification number of the sender and the recipient, a device fingerprint data of the sender, or any combination thereof.

3. The computer-implemented method of claim 1 , further comprising assigning a unique pending identifier to each of the first transaction and the at least one subsequent transaction when a status of the corresponding transaction is updated to pending by the real-time payment server in a payment response code, wherein the real-time payment server generates the payment response code in response to receiving a payment request code from the sender payment service provider server, and wherein the payment response code is generated based on a response provided by the recipient payment service provider server.

4. The computer-implemented method of claim 3 , wherein the status of the first transaction and the at least one subsequent transaction is updated to pending in the payment response code when one of the following occurs: the first transaction and the at least one subsequent transaction are initiated and are being processed; and no response for the corresponding transaction is received from the recipient payment service provider server within a predetermined time.

5. The computer-implemented method of claim 1 , wherein processing of the first transaction and the at least one subsequent transaction is performed concurrently by the sender payment service provider server.

6. The computer-implemented method of claim 3, wherein the one or more messages are updated using a typeless command along with the unique pending identifier of a successful transaction, wherein the one or more messages are in accordance with ISO 8583 standard.

7. A payment service provider server of a sender, comprising: one or more processors; and a memory communicatively coupled to the one or more processors, wherein the memory stores processor-executable instructions that, when executed, cause the one or more processors to: identifying a first transaction from a sender via a receiver payment service provider server to a receiver via the sender payment service provider server, wherein a real-time payment server facilitates the transaction between the sender payment service provider server and the receiver payment service provider server; detecting at least one subsequent transaction from the sender to the receiver while the first transaction is pending at the receiver payment service provider server; while the first transaction is pending at the recipient payment service provider server, comparing transaction parameters of the at least one subsequent transaction with transaction parameters of the first transaction; determining that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; as well as sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful, and discarding the other of the first transaction and the at least one subsequent transaction, wherein the other transaction is discarded by at least one of the sender payment service provider server and the recipient payment service provider server based on the one or more messages.

8. The sender payment service provider server of claim 7, further comprising assigning, by the one or more processors, a unique pending identifier to each of the first transaction and the at least one subsequent transaction when a status of the corresponding transaction is updated to pending in a payment response code by the real-time payment server, wherein the real-time payment server generates the payment response code in response to receiving a payment request code from the sender payment service provider server, wherein the payment response code is generated based on a response provided by the recipient payment service provider server.

9. The sender payment service provider server of claim 8, wherein the one or more processors update the status of the first transaction and the at least one subsequent transaction to pending in the payment response code when one of the following occurs: the first transaction and the at least one subsequent transaction are initiated and being processed; and no response for the corresponding transaction is received from the receiver payment service provider server within a predetermined time.

10. The sender payment service provider server of claim 7, wherein the one or more processors process the first transaction and the at least one subsequent transaction concurrently.

11. The sender payment service provider server of claim 8, wherein the one or more processors update one or more messages along with the unique pending identifier of the successful transaction using a typeless command, wherein the one or more messages are in accordance with the ISO 8583 standard.

12. A non-transitory computer-readable medium comprising instructions stored thereon, the instructions, when processed by one or more processors, causing a sender payment service provider server to perform operations comprising: identifying a first transaction from a sender via a receiver payment service provider server to a receiver via the sender payment service provider server, wherein a real-time payment server facilitates the transaction between the sender payment service provider server and the receiver payment service provider server; detecting at least one subsequent transaction between the sender and the receiver while the first transaction is pending at the receiver payment service provider server; while the first transaction is pending at the recipient payment service provider server, comparing one or more transaction parameters of the at least one subsequent transaction with one or more transaction parameters of the first transaction; determining that the first transaction and the at least one subsequent transaction are associated with a single payment made by the sender to the recipient; identifying one of the first transaction and the at least one subsequent transaction as successful by monitoring the first transaction and the at least one subsequent transaction; as well as sending one or more messages based on the monitoring, wherein the one or more messages indicate that one of the first transaction and the at least one subsequent transaction was successful, and discarding the other of the first transaction and the at least one subsequent transaction, wherein the other transaction is discarded by at least one of the sender payment service provider server and the recipient payment service provider server based on the one or more messages.

13. The non-transitory computer-readable medium of claim 12, further comprising assigning, by the one or more processors, a unique pending identifier to each of the first transaction and the at least one subsequent transaction when a status of the corresponding transaction is updated to pending in a payment response code by the real-time payment server, wherein the real-time payment server generates the payment response code in response to receiving a payment request code from the sender payment service provider server, wherein the payment response code is generated based on a response provided by the receiver payment service provider server.

14. The non-transitory computer-readable medium of claim 13, wherein the one or more processors update the status of the first transaction and the at least one subsequent transaction as pending in the payment response code upon one of the following occurrences: the first transaction and the at least one subsequent transaction are initiated and being processed; and no response for the corresponding transaction is received from the recipient payment service provider server within a predetermined time.

15. The non-transitory computer-readable medium of claim 12, wherein the one or more processors process the first transaction and the at least one subsequent transaction concurrently.

16. The non-transitory computer-readable medium of claim 13, wherein the one or more processors update one or more messages along with the unique pending identifier of a successful transaction using a typeless command, wherein the one or more messages are in accordance with the ISO 8583 standard.

Images