System and computer-implemented method for fulfilling order requests

Abstract

The present invention relates to a system and computer-implemented method for fulfilling an order request. The method includes receiving information about a transaction between a user and a merchant, and information about an error in processing the transaction. Further, based on a guarantee value received from the merchant, requesting one or more entities to provide at least one of a portion or all of the guarantee value. Further, in response to the request, receiving a contribution value from each of the one or more entities, wherein the contribution value is one of the portion or all of the guarantee value. Finally, upon determining that the contribution values received from the one or more entities collectively reach the guarantee value, providing a guarantee message to the merchant indicating successful payment to fulfill the order request of the user.

Description

Technical Field

[0001] This disclosure relates to order management. Specifically, but not exclusively, this disclosure relates to a system and method for fulfilling order requests. Background Technology

[0002] Order fulfillment is typically a process within an online / offline platform, involving a user making a service request and / or one or more product requests to a merchant, who then initiates a payment transaction based on the details provided by the user. The merchant then processes the service request and / or one or more product requests and delivers them to the user. Merchant-initiated payment transactions can include card transactions, archived card transactions, Uniform Payment Methods (UPI), etc. Merchant-initiated payment transactions may be completed immediately by the issuing bank's server, or may require an additional time, such as one to two days, to complete. The transaction is complete when the acquiring bank's server receives the payment from the issuing bank's server. Typically, the issuing bank's server is associated with the user, and the acquiring bank is associated with the merchant. In some cases, the issuing bank and the acquiring bank may be the same entity.

[0003] Merchants may be reluctant to process and deliver user-initiated order requests when additional time is required to complete payment transactions. Typically, merchants are highly unlikely to fulfill orders that cannot be completed immediately and may require further processing time. Such scenarios may force users to initiate new transactions or make new purchases. Therefore, existing technology does not provide a method for completing payment transactions initiated by merchants to fulfill user order requests in such situations. This can lead to trust issues between merchants and users, ultimately impacting customer satisfaction and retention.

[0004] The information disclosed in this background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that this information constitutes prior art known to those skilled in the art. Summary of the Invention

[0005] Additional features and advantages are achieved through the technology disclosed herein. Other embodiments and aspects of this disclosure are described in detail herein and are considered part of the claimed disclosure.

[0006] In some non-limiting embodiments or aspects, a computer-implemented method is provided, comprising: receiving, via at least one processor, information about a transaction between a user and a merchant, and information about an error that occurred while processing the transaction; receiving, via at least one processor, a guarantee value from the merchant indicating a portion of a total amount associated with the transaction for fulfilling the user's order request, wherein the merchant transmits the guarantee value to a guarantee server after becoming aware of an error that occurred while processing the transaction; requesting, via at least one processor, one or more entities to provide at least one portion or all of the guarantee value received from the merchant; in response to the request, receiving, via at least one processor, contribution values ​​from each of the one or more entities, wherein the contribution values ​​are one portion or all of the guarantee value; and in response to determining that the total of the contribution values ​​received from the one or more entities reaches the guarantee value, transmitting, via at least one processor, a guarantee message indicating successful payment to the merchant to fulfill the user's order request.

[0007] In some non-limiting embodiments or aspects, errors occurring during transaction processing include at least one of the following: message failure, hardware failure, network failure, or any combination thereof. In some non-limiting embodiments or aspects, the one or more entities include at least one of a financial institution and an individual. In some non-limiting embodiments or aspects, responses to requests from the one or more entities are received within a first predefined time period. In some non-limiting embodiments or aspects, responses to requests from the one or more entities are rejected after the first predefined time period. In some non-limiting embodiments or aspects, a user's order request is rejected when it is determined that the contribution value received from the one or more entities is not equal to the guaranteed value. In some non-limiting embodiments or aspects, the at least one processor, the merchant, and the one or more entities are connected via a communication network. In some non-limiting embodiments or aspects, a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: user, merchant, order request, or any combination thereof. In some non-limiting embodiments or aspects, the one or more parameters include at least one of the following: user information, bank identification number (BIN), transaction log information, merchant information, order request details, the user's past transactions, the merchant's past transactions, or any combination thereof.

[0008] In some non-limiting embodiments or aspects, a guarantee server is provided, the guarantee server including at least one processor and a memory communicatively coupled to the at least one processor, wherein the memory stores processor instructions that, when executed, cause the at least one processor to: receive information about a transaction between a user and a merchant, and information about an error that occurred while processing the transaction; receive from the merchant a guarantee value, representing a portion of the total amount associated with the transaction, indicating the fulfillment of the user's order request, wherein the merchant transmits the guarantee value to the guarantee server after becoming aware of an error that occurred while processing the transaction; request one or more entities to provide at least one portion or all of the guarantee value received from the merchant; in response to the request, receive a contribution value from each of the one or more entities, wherein the contribution value is one portion or all of the guarantee value; and in response to determining that the total contribution values ​​received from the one or more entities have reached the guarantee value, transmit a guarantee message to the merchant indicating successful payment to fulfill the user's order request.

[0009] In some non-limiting embodiments or aspects, errors occurring during the processing of the transaction include at least one of the following: message failure, hardware failure, network failure, or any combination thereof. In some non-limiting embodiments or aspects, the one or more entities include at least one of a financial institution and an individual. In some non-limiting embodiments or aspects, the at least one processor is configured to receive responses to requests from the one or more entities within a first predefined time period. In some non-limiting embodiments or aspects, the at least one processor is configured to reject responses to requests from the one or more entities after the first predefined time period. In some non-limiting embodiments or aspects, the at least one processor is configured to send a message indicating that the contribution value received from the one or more entities is not equal to the guaranteed value to the merchant, causing the merchant to reject the user's order request. In some non-limiting embodiments or aspects, a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: user, merchant, order request, or any combination thereof.

[0010] In some non-limiting embodiments or aspects, a computer-implemented method is provided, comprising: when an error occurs while processing a transaction between a user and a merchant and a guarantee server has fulfilled an order associated with the transaction, re-initiating the transaction via at least one processor after receiving information about the transaction; in response to receiving a success message: receiving or determining, via at least one processor, a total amount associated with the transaction between the user and the merchant, and allocating a contribution value and a supplementary value based on the contribution value from the total amount to each of one or more entities, wherein the contribution value of the one or more entities is at least one of a portion or all of a guarantee value, wherein the guarantee value is a portion of the total amount associated with the transaction; and in response to receiving a failure message, performing, via at least one of: re-initiating the transaction between the user and the merchant after a second predefined time period, and discarding the transaction.

[0011] In some non-limiting embodiments or aspects, a re-initiated transaction is discarded after a transaction is initiated for a predefined value and a failure message is received. In some non-limiting embodiments or aspects, re-initiating a transaction includes inserting a value into one or more fields of the transaction message of the re-initiated transaction via at least one processor, thereby indicating that the transaction be re-initiated after a second predefined time period, wherein the re-initiated transaction failed due to an error that occurred while processing the transaction. In some non-limiting embodiments or aspects, the one or more fields in the transaction message include at least one of the following: a message type indicator (MTI), a bitmap, a data element, or any combination thereof.

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

[0013] Article 1. A computer-implemented method comprising: receiving, via at least one processor, information about a transaction between a user and a merchant, and information about an error occurring during the processing of the transaction; receiving, via at least one processor, a guarantee value from the merchant indicating a portion of a total amount associated with the transaction for fulfilling the user's order request, wherein the merchant transmits the guarantee value to a guarantee server after becoming aware of the error occurring during the processing of the transaction; requesting, via at least one processor, one or more entities to provide at least one portion or all of the guarantee value received from the merchant; in response to the request, receiving, via at least one processor, contribution values ​​from each of the one or more entities, wherein the contribution values ​​are one portion or all of the guarantee value; and in response to determining that the total of the contribution values ​​received from the one or more entities reaches the guarantee value, transmitting, via at least one processor, a guarantee message indicating successful payment to the merchant to fulfill the user's order request.

[0014] Article 2. The method according to Article 1, wherein the error occurring in processing the transaction includes at least one of the following: message failure, hardware failure, network failure, or any combination thereof.

[0015] Article 3. The one or more entities described in accordance with Article 1 or Article 2 include at least one of financial institutions and individuals.

[0016] Article 4. The method according to any one of Articles 1 to 3, wherein a response to the request is received from the one or more entities within a first predefined time period.

[0017] Article 5. The method described in any one of Articles 1 to 4, wherein responses to the request from the one or more entities are rejected after a first predefined time period.

[0018] Article 6. The method according to any one of Articles 1 to 5, wherein the user's order request is rejected when it is determined that the contribution value received from the one or more entities is not equal to the guarantee value.

[0019] Article 7. The method according to any one of Articles 1 to 6, wherein the at least one processor, the merchant, and the one or more entities are connected via a communication network.

[0020] Article 8. The method of claim 1, wherein a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: the user, the merchant, the order request, or any combination thereof.

[0021] Article 9. The method according to any one of Articles 1 to 8, wherein the one or more parameters include at least one of the following: user information, bank identification number (BIN), transaction log information, merchant information, details of the order request, the user's past transactions, the merchant's past transactions, or any combination thereof.

[0022] Article 10. A guarantee server comprising at least one processor and a memory communicatively coupled to the at least one processor, wherein the memory stores processor instructions that, when executed, cause the at least one processor to: receive information about a transaction between a user and a merchant, and information about an error that occurred while processing the transaction; receive from the merchant a guarantee value, representing a portion of a total amount associated with the transaction, indicating the fulfillment of the user's order request, wherein the merchant transmits the guarantee value to the guarantee server after becoming aware of the error that occurred while processing the transaction; request one or more entities to provide at least one portion or all of the guarantee value received from the merchant; in response to the request, receive a contribution value from each of the one or more entities, wherein the contribution value is one portion or all of the guarantee value; and in response to determining that the total contribution values ​​received from the one or more entities have reached the guarantee value, transmit a guarantee message to the merchant indicating successful payment to fulfill the user's order request.

[0023] Article 11. The guarantee server as described in Article 10, wherein the error occurring in processing the transaction includes at least one of the following: message failure, hardware failure, network failure, or any combination thereof.

[0024] Article 12. A guarantee server as described in Article 10 or 11, wherein the one or more entities include at least one of a financial institution and an individual.

[0025] Article 13. A guarantee server according to any one of Articles 10 to 12, wherein the at least one processor is configured to receive a response to the request from the one or more entities within a first predefined time period.

[0026] Article 14. A guarantee server according to any one of Articles 10 to 13, wherein the at least one processor is configured to reject responses to the request from the one or more entities after a first predefined time period.

[0027] Article 15. A guarantee server according to any one of Articles 10 to 14, wherein the at least one processor is configured to send a message indicating that a contribution value received from the one or more entities is not equal to the guarantee value to the merchant, so that the merchant rejects the user's order request.

[0028] Article 16. A guarantee server as described in any one of Articles 10 to 15, wherein a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: the user, the merchant, the order request, or any combination thereof.

[0029] Article 17. A computer-implemented method comprising: upon receiving information about a transaction between a user and a merchant, and upon an error occurring while processing the transaction and a guarantee that a server had fulfilled an order associated with the transaction, re-initiating the transaction via at least one processor; in response to receiving a success message: receiving or determining, via at least one processor, a total amount associated with the transaction between the user and the merchant, and allocating a contribution value and a supplementary value based on the contribution value from the total amount to each of one or more entities, wherein the contribution value of the one or more entities is at least one of a portion or all of a guarantee value, wherein the guarantee value is a portion of the total amount associated with the transaction; and in response to receiving a failure message, performing, via at least one of: re-initiating the transaction between the user and the merchant after a second predefined time period, and discarding the transaction.

[0030] Article 18. The method according to Article 17, wherein after initiating the transaction for a predefined value and receiving the failure message, the re-initiated transaction is discarded.

[0031] Article 19. The method according to Article 17 or Article 18, wherein re-initiating the transaction comprises inserting a value into one or more fields of the transaction message of the re-initiated transaction by at least one processor, thereby indicating that the transaction is re-initiated after the second predefined time period, and wherein the re-initiated transaction failed due to an error that occurred while processing the transaction.

[0032] Article 20. The method according to any one of Articles 17 to 19, wherein the one or more fields in the transaction message include at least one of the following: Message Type Indicator (MTI), bitmap, data element, or any combination thereof.

[0033] In some non-limiting embodiments or aspects, this document discloses a computer-implemented method for fulfilling an order request. The method includes receiving information about a transaction between a user and a merchant, and information about an error that occurred while processing the transaction. Furthermore, the method includes receiving from the merchant a guarantee value, indicating a portion of the total amount associated with the transaction for fulfilling the user's order request. The merchant transmits the guarantee value to a guarantee server after becoming aware of the error that occurred while processing the transaction. Additionally, the method includes requesting one or more entities to provide part or all of the guarantee value received from the merchant. Subsequently, the method includes receiving contribution values ​​from each of the one or more entities in response to the request, wherein the contribution values ​​are one of the parts or all of the guarantee value. Finally, the method includes transmitting or providing a guarantee message indicating successful payment to the merchant to fulfill the user's order request after determining that the total of the contribution values ​​received from the one or more entities reaches the guarantee value.

[0034] Furthermore, in some non-limiting embodiments or aspects, this disclosure may include a guarantee server for fulfilling order requests. The guarantee server includes a processor and a memory communicatively coupled to the processor, wherein the memory stores processor-executable instructions that, upon execution, cause the processor to receive information about a transaction between a user and a merchant, and information about errors that occurred while processing the transaction. Furthermore, the processor is configured to receive from the merchant a guarantee value, representing a portion of the total amount associated with the transaction, for fulfilling the user's order request, wherein the merchant transmits the guarantee value to the guarantee server after becoming aware of the error that occurred while processing the transaction. Additionally, the processor is configured to request one or more entities to provide at least one portion or all of the guarantee value received from the merchant. Subsequently, in response to the request, the processor is configured to receive a contribution value from each of the one or more entities, wherein the contribution value is one portion or all of the guarantee value. Finally, the processor is configured to provide the merchant with a guarantee value indicating successful payment to fulfill the user's order request after determining that the total contribution values ​​received from the one or more entities have reached the guarantee value.

[0035] Furthermore, in some non-limiting embodiments or aspects, this disclosure may include a method for re-initiating a failed transaction. The method includes receiving multiple details associated with the transaction. Furthermore, the method includes initiating the transaction after receiving information about the transaction between a user and a merchant, when an error occurs while processing the transaction, and when it is guaranteed that the server has fulfilled the order associated with the transaction. The method also includes receiving a response to the initiated transaction, wherein the response includes at least one of a success or failure message. Upon receiving a success message, the method includes receiving a total amount associated with the transaction between the user and the merchant from the merchant. Furthermore, the method includes allocating a contribution value and a supplementary value based on the contribution value from the total amount to each of one or more entities, wherein the contribution value of the one or more entities is at least one of a portion or all of a guaranteed value, and wherein the guaranteed value is a portion of the total amount associated with the transaction. Upon receiving the failure message, the method includes performing at least one of the following: initiating the transaction between the user and the merchant after a second predefined time period, or abandoning the transaction.

[0036] The foregoing overview is merely illustrative and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, other aspects, embodiments, and features will become apparent from the drawings and the following detailed description. Attached Figure Description

[0037] The novel features and characteristics of this disclosure are set forth in the appended claims. However, the disclosure itself, as well as preferred modes of use, additional objectives, and advantages thereof, can be best understood by referring to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings. The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the principles disclosed. In the drawings, the leftmost digit of the reference numerals identifies the figure in which the reference numeral first appears. One or more embodiments will now be described by way of example only with reference to the accompanying drawings, wherein similar reference numerals denote similar elements, and in the drawings:

[0038] Figure 1 Exemplary environments for fulfilling order requests are shown according to some non-limiting embodiments or aspects of this disclosure;

[0039] Figure 2 A simplified block diagram of a guarantee server for fulfilling order requests and re-initiating transactions, according to an embodiment of the present disclosure, is shown.

[0040] Figure 3 A flowchart is shown illustrating method steps for fulfilling an order request according to some non-limiting embodiments or aspects of this disclosure;

[0041] Figure 4 Exemplary environments for transmitting or providing warranty messages to merchants are shown, according to some non-limiting embodiments or aspects of this disclosure;

[0042] Figure 5 A flowchart is shown illustrating method steps for re-initiating a transaction according to some non-limiting embodiments or aspects of this disclosure;

[0043] Figure 6 Exemplary environments for re-initiating previously failed transactions are shown, based on some non-limiting embodiments or aspects of this disclosure; and

[0044] Figure 7 Exemplary computer systems for fulfilling order requests are shown according to some non-limiting embodiments or aspects of this disclosure.

[0045] Those skilled in the art will understand that any block diagram herein represents a conceptual view of an illustrative system embodying the principles of the subject matter of this invention. Similarly, it should be understood that any flowchart, diagram, state transition diagram, pseudocode, etc., represents various processes that can be substantially represented in a computer-readable medium and therefore executed by a computer or processor, whether or not such a computer or processor is explicitly shown. Although each figure shows a particular embodiment for the purpose of illustrating clear examples, other embodiments may omit, add, reorder, and / or modify any elements shown in the figures. Detailed Implementation

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

[0047] In the following detailed description of embodiments of this disclosure, reference is made to the accompanying drawings, which form a part of this disclosure, and specific embodiments in which this disclosure may be practiced are illustrated by way of illustration. However, it should be understood that this disclosure is not intended to be limited to the forms disclosed, but rather, it is intended to cover all modifications, equivalents, and alternatives that fall within the spirit and scope of this disclosure. It should be understood that other embodiments may be utilized and changes may be made without departing from the scope of this disclosure. Therefore, the following description should not be considered restrictive.

[0048] The term "comprises" or any other variation thereof is intended to cover non-exclusive inclusion, such that an arrangement, apparatus, or method that includes a list of components or steps may include not only those components or steps but also other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, without further constraints, one or more elements in a system or apparatus following "comprises…a" do not exclude the presence of other elements or additional elements in the system or method.

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

[0050] The aspects, components, elements, structures, actions, steps, functions, instructions, etc., used herein should not be construed as critical or essential unless explicitly described as such. Furthermore, as used herein, the article “a” is intended to include one or more items and is interchangeable with “one or more” and “at least one.” Additionally, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and is interchangeable with “one or more” or “at least one.” Where only one item is desired, the term “a” or similar language is used. Furthermore, as used herein, the terms “having” and the like are intended to be open-ended terms. Additionally, 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 this disclosure.” The description of some non-limiting embodiments or aspects having several components communicating with each other does not imply that all of these components are required. Rather, various optional components are described to illustrate various possible embodiments of this disclosure.

[0051] When this document describes a single device or article, it will be apparent that more than one device / article (whether or not cooperating) may be used in place of the single device / article. Similarly, when this document describes more than one device or article (whether or not cooperating), it will be apparent that a single device / article may be used in place of more than one device or article, or that a different number of devices / articles may be used in place of the number of devices or programs shown. The functionality and / or features of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Therefore, other embodiments of this disclosure need not include the device itself.

[0052] As used herein, the terms “communication,” “transmission,” “send,” and / or “receive” can refer to the receiving, accepting, sending, transmitting, or providing of information (e.g., data, signals, messages, instructions, commands, etc.). Communication between one unit (e.g., an apparatus, system, component of an apparatus or system, or a combination thereof) and another unit means that the first unit is able to receive information directly or indirectly from and / or send information to the other unit. This can refer to a direct or indirect connection that is inherently wired and / or wireless (e.g., a direct communication connection, an indirect communication connection, and / or the like). Furthermore, although the transmitted information may be modified, processed, relayed, and / or routed between the first and second units, the two units can also communicate with each other. For example, the first unit can communicate with the second unit even if it passively receives information and does not actively send information to the second unit. As another example, the first unit can communicate with the 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 (e.g., a data packet, etc.) that includes data. It should be understood that many other arrangements are possible.

[0053] As used herein, the terms “server” and / or “processor” can refer to one or more computing devices, such as processors, storage devices, and / or similar computer components, that communicate with client devices and / or other computing devices via 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” can 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. Furthermore, as used herein, references to “server” or “processor” can refer to a previously listed server and / or processor described as performing a preceding step or function, different servers and / or processors, and / or combinations of servers and / or processors. For example, as used in the specification and claims, a first server and / or first processor described as performing a first step or function can refer to the same or different server and / or processor described as performing a second step or function.

[0054] This disclosure relates to a system and a computer-implemented method for fulfilling an order request. In some non-limiting embodiments or aspects, the method includes receiving information about a transaction between a user and a merchant, and information about errors that occurred while processing the transaction. Furthermore, based on a guarantee value received from the merchant, one or more entities are requested to provide at least one part or all of the guarantee value. In response to the request, a contribution value is received from each of the one or more entities, wherein the contribution value is one part or all of the guarantee value. Finally, after determining that the total of the contribution values ​​received from the one or more entities reaches the guarantee value, a guarantee message indicating successful payment is provided to the merchant to fulfill the user's order request.

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

[0056] Figure 1Exemplary environments for fulfilling order requests are illustrated according to some non-limiting embodiments or aspects of this disclosure. In some non-limiting embodiments or aspects, a user (101) may initiate a payment transaction with a merchant (102) after issuing an order request. The order request issued by the user (101) may include at least purchasing one or more goods from the merchant (102) in a store or through an e-commerce application, requesting services from the merchant (102) in a store or through an e-commerce application, such as a taxi taking the user (101) to a destination location, etc. The payment transaction initiated by the user (101) may include at least one of the following: a card transaction at a point-of-sale (POS) device associated with the merchant (102), an archived card transaction through a payment application, a payment wallet, etc.

[0057] In some non-limiting embodiments or aspects, the merchant (102) may send an authentication and / or authorization request message associated with a payment transaction between the user (101) and the merchant (102) to the issuer server (105) via a gateway (103) and a directory server (104). The authentication request may include verifying at least one of the following: user credentials, a bank identification number (BIN) of a card associated with the user (101), a card verification value, a card expiry date, merchant authentication, or any combination thereof. User credentials may include, for example, a username, password, PIN, etc. The authorization request may include a request to the issuer server (105) associated with the user (101) to approve the payment transaction. The merchant (102), gateway (103), directory server (104), and issuer server (105) may be connected via at least one of wired or wireless media, networks, and / or architectures.

[0058] In some non-limiting embodiments or aspects, a payment transaction may be successfully completed upon receiving a successful response to an authentication and / or authorization request. Furthermore, the merchant (102) may fulfill the user's (101) order request. Successful authorization of the payment transaction may "freeze" or "retain" the total amount associated with the payment transaction in the user's account. The total amount may be transferred from the issuer's server (105) to the merchant's account (acquiring bank account) during the settlement process.

[0059] In some non-limiting embodiments or aspects, errors may occur when processing payment transactions. These errors may include, for example, at least one of the following: message failure, hardware failure, network failure, or any combination thereof. Message failures may include authorization rejection for a transaction message, settlement rejection for a transaction message, etc. For example, message failures may include exceeding transaction limits, requiring a phone number, incorrect merchant account configuration, verification errors, etc. Those skilled in the art will recognize that verification errors are different from invalid user credentials. For example, errors may occur due to incomplete KYC details at the issuing server (105), etc. Hardware failures may include functional problems with one or more hardware components, such as routers, network switches, servers, etc. Network failures may include connectivity problems associated with the merchant (102), gateway (103), directory server (104), and issuing server (105).

[0060] In some non-limiting embodiments or aspects, the assurance server (106) is able to receive information from the merchant (102) regarding the transaction between the user (101) and the merchant (102), as well as information regarding errors that occurred during the processing of the transaction. The information regarding the transaction may include one or more of the following: at least one of the user details, such as name, address, telephone number, etc.; the BIN associated with the user's (101) card; the merchant details, such as name, address, telephone number, etc.; the merchant category; details of the acquiring bank (not shown) associated with the merchant (102); details of the issuing server bank associated with the user (101); the total amount associated with the transaction; the Internet Protocol (IP) address associated with the transaction, etc. Errors associated with the transaction may include at least one of the error type (e.g., message failure, hardware failure, network failure, etc.) and the error code associated with the error. For example, for the error "Amount exceeding the permissible limit was found," the associated error code could be "4006". In some non-limiting embodiments or aspects, the transaction message may be provided to the assurance server (106). The transaction message provided to the assurance server (106) may include a field indicating the type of error that occurred while processing the transaction message. In some non-limiting embodiments or aspects, the error type is included in the transaction message by one of the merchant (102), the directory server (104), the gateway (103), and the issuer server (105). The assurance server (106) may store the received transaction information for re-initiating the transaction after a second predefined time period.

[0061] In addition, the guarantee server (106) receives from the merchant (102) a guarantee value for a portion of the total amount associated with the transaction, or a guarantee value for the total amount, to fulfill the user's (101) order request. For example, for an order request with a total amount of $100, the guarantee value could be $80. The guarantee value indicates the minimum amount that the merchant (102) will receive from one or more entities (107A, 107B, ..., 107N) if the transaction is resubmitted for authentication and / or authorization after a second predefined time period following a failed transaction or rejection by the issuing server (105). For example, if a transaction is rejected for "exceeding the transaction limit," the user (101) may request the issuing server (105) to increase the transaction limit, and the guarantee server (106) may resubmit the transaction after 15 minutes. The guarantee server (106) requests one or more entities (107A, 107B, ..., 107N) to provide part or all of the guarantee value within the first predefined time period. The first predefined time period indicates the duration for which each of one or more entities (107A, 107B, ..., 107N) is to send a contribution value to the assurance server (106). For example, the assurance server (106) may request one or more entities (107A, 107B, ..., 107N) to respond within 60 seconds. In response to the request, the assurance server (106) may receive a contribution value from each of the one or more entities (107A, 107B, ..., 107N) within the first predefined time period, wherein the contribution value is a part or all of the assurance value. For example, entity 1 (107A) may provide a contribution value of $50, and entity N (107N) may provide a contribution value of $30. The assurance server (106) determines the sum of the contribution values ​​received from one or more entities (107A, 107B, ..., 107N) and compares the sum of the contribution values ​​with the assurance value. If the sum of the contribution values ​​equals the guarantee value requested by the guarantee server (106), then the merchant (102) is provided with a guarantee message by the guarantee server (106) indicating successful payment of the guarantee value. Finally, the merchant (102) can fulfill the user's (101) order request. Therefore, the payment of the guarantee value in the event of an error in the payment transaction helps to fulfill the user's (101) order and reduces the rate at which the merchant (102) cancels orders. In some non-limiting embodiments or aspects, the user's (101) experience with the merchant (102) is improved by fulfilling the order even during payment transaction failures. In some non-limiting embodiments or aspects, when a payment transaction fails, the transaction amount may be debited to the user (101). In some non-limiting embodiments or aspects, when the re-initiation of a payment transaction repeatedly fails, the transaction amount may be credited back to the user (101).

[0062] In some non-limiting embodiments or aspects, the assurance server (106) may request the merchant (102) to lower the assurance value or request the merchant (102) to accept the sum of the received contribution values ​​as the assurance value for fulfilling the order request when it determines that the contribution value received from one or more entities (107A, 107B, ..., 107N) is not equal to the assurance value. After the merchant (102) lowers the assurance value, the assurance server (106) may again request contribution values ​​from one or more entities (107A, 107B, ..., 107N).

[0063] In some non-limiting embodiments or aspects, a user's (101) order request is rejected for at least one of the following reasons: the guarantee server (106) receives a response to the request from one or more entities (107A, 107B, ..., 107N) after a first predefined time period and determines that the contribution value received from one or more entities (107A, 107B, ..., 107N) is not equal to the guarantee value. Furthermore, responses to the request from one or more entities (107A, 107B, ..., 107N) after the first predefined time period are rejected by the guarantee server (106).

[0064] In some non-limiting embodiments or aspects, it is guaranteed that the server (106), one or more entities (107A, 107B, ..., 107N), and the merchant (102) can be connected via a communication network (not shown). Furthermore, the communication network may include, for example, direct interconnection, e-commerce networks, peer-to-peer (P2P) networks, local area networks (LANs), wide area networks (WANs), wireless networks (e.g., using wireless application protocols), the Internet, etc. Cellular networks, etc.

[0065] In some non-limiting embodiments or aspects, the assurance server (106) re-initiates the transaction between the user (101) and the merchant (102) by copying the transaction after a second predefined time period. The second predefined time period indicates the minimum duration required for the assurance server (106) to wait for the transaction to be re-initiated. Copying the transaction includes copying the information of the initiating transaction into the re-initiated transaction without manual input. The transaction is sent to the issuer server (105) via a gateway (103) and a directory server (104). The assurance server (106) receives a response from the issuer server (105), including at least one of a success or failure message.

[0066] In some non-limiting embodiments or aspects, when a re-initiated transaction is successful, the transaction amount is credited to the merchant (102) or the acquiring bank. The warranty server (106) may request the merchant (102) to transfer the total amount to allocate it to one or more entities (107A, 107B, ..., 107N). In some non-limiting embodiments or aspects, the warranty server (106) receives from the merchant (102) or determines, based on available information, the total amount associated with the transaction and allocates a contribution value from the total amount to the corresponding one or more entities (107A, 107B, ..., 107N). In some non-limiting embodiments or aspects, the warranty server (106) may allocate a supplementary value based on the contribution value from the total amount to each of the one or more entities (107A, 107B, ..., 107N).

[0067] In some non-limiting embodiments or aspects, upon receiving a failure message, the server (106) is guaranteed to perform at least one of the following: initiate a transaction between the user (101) and the merchant (102) after a second predefined time period, or abandon the transaction after repeated attempts.

[0068] In some non-limiting embodiments or aspects, the one or more entities (107A, 107B, ..., 107N) include at least one of the following: one or more financial institutions, banks, insurance companies, credit unions, trust companies, mortgage companies, brokerage firms, individuals, or any combination thereof.

[0069] Figure 2 A simplified block diagram of a warranty server (106) according to a non-limiting embodiment or aspect of this disclosure is shown. In some non-limiting embodiments or aspects, the warranty server (106) may include at least one central processing unit (“CPU” or “processor”) (201) and a memory (202) storing instructions executable by at least one processor (201). The processor (201) may include at least one data processor for executing program components for performing user- or system-generated requests. The memory (202) is communicatively coupled to the processor (201). The warranty server (106) also includes an input / output (I / O) interface (203). The I / O interface (203) is coupled to the processor (201) thereby transmitting input signals and / or output signals. In some non-limiting embodiments or aspects, the data stored in the memory (202) may include entity data (204), transaction information (205), and other data (206).

[0070] In some non-limiting embodiments or aspects, entity data (204) includes information about one or more entities (107A, 107B, ..., 107N). The one or more entities (107A, 107B, ..., 107N) include at least one of one or more financial institutions and individuals. The information may include one or more of the following: name, address, authentication details, KYC details, associated bank, etc.

[0071] In some non-limiting embodiments or aspects, the transaction information (205) may include at least one of the following: the BIN associated with the user's (101) card, the card's expiry date, the card verification value (CVV), the issuing server's (105) bank details, the password, the PIN number, the One-Time Password (OTP) details, the acquiring bank details, the total amount, the billing address, the merchant details, the Internet Protocol (IP) address associated with the transaction, or any combination thereof. For example, for a transaction originating in India, the issuing server's bank details and the acquiring bank details may include the name, address, Indian Financial System Code (IFSC) code, etc. The merchant details may include the name, category code, etc. Furthermore, the transaction information (205) may include details about errors that occurred during the processing of the transaction. Errors that occurred during the processing of the transaction include at least one of message failures, hardware failures, and network failures. For example, the error "Amount exceeding the permissible limit found" and the associated error code "4006" may be stored in the transaction information (205).

[0072] In some non-limiting embodiments or aspects, other data (206) may include a guarantee value received from the merchant (102), a contribution value provided by each of one or more entities (107A, 107B, ..., 107N), a first predefined time period data for receiving responses from one or more entities (107A, 107B, ..., 107N), and a second predefined time period data for re-initiating the transaction between the user (101) and the merchant (102).

[0073] In some non-limiting embodiments or aspects, the supplementary value determination module (207) is used to determine a supplementary value based on a contribution value provided by each of the one or more entities (107A, 107B, ..., 107N). The contribution value provided by one or more entities (107A, 107B, ..., 107N) is part or all of the guaranteed value requested by the merchant (102). For example, for a guaranteed value of $80 and a total amount of $100, the contribution value of entity 1 (107A) could be $50, and the contribution value of entity N (107N) could be $30. In an exemplary embodiment, the supplementary value of each of the one or more entities (107A, 107B, ..., 107N) can be calculated using the equations given below:

[0074]

[0075] Therefore, the supplementary value for entity 1 (107A) is $12.5, and the supplementary value for entity N (107N) is $7.5. Those skilled in the art will understand that one or more existing techniques can be used to calculate the supplementary value based on the contribution value. Furthermore, various other factors can be used to calculate the supplementary value, including but not limited to the time taken by one or more entities (107A, 107B, ..., 107N) to respond to a request issued by the guarantee server (106), the amount of contribution made, etc.

[0076] In some non-limiting embodiments or aspects, the comparison module (208) is used to sum the contribution values ​​received from each of the one or more entities (107A, 107B, ..., 107N) and compare the sum of the contribution values ​​with a guarantee value received from the merchant (102). If the sum of the contribution values ​​is equal to the guarantee value, a guarantee message is sent to the merchant (102). If the sum of the contribution values ​​is less than the guarantee value, a message indicating that a guarantee cannot be provided is sent to the merchant (102), and the order is cancelled.

[0077] In some non-limiting embodiments or aspects, the transaction re-initiation module (209) is used to re-initiate the transaction between the user (101) and the merchant (102) after a second predefined time period. The transaction is re-initiated by inserting values ​​into one or more fields in the transaction message of the transaction. These one or more fields indicate that the transaction is being re-initiated after the second predefined time period, where the transaction previously failed due to an error that occurred during transaction processing. Furthermore, the one or more fields in the transaction message include at least one of a Message Type Indicator (MTI), a bitmap, or a data element.

[0078] In some non-limiting embodiments or aspects, the communication module (210) is configured to receive from the merchant (102) at least one of the following: information about the transaction, information about errors that occurred during transaction processing, a guarantee value, and information about the total amount associated with the transaction. Furthermore, the communication module (210) is configured to receive contribution values ​​from one or more entities (107A, 107B, ..., 107N). The communication module (210) is configured to provide a guarantee message to the merchant (102) and provide information about supplementary values ​​to the one or more entities (107A, 107B, ..., 107N). Additionally, the communication module (210) is configured to send transaction-related information to a gateway (103) and receive the transaction status from the gateway (103).

[0079] Figure 3 A flowchart is shown illustrating method steps for fulfilling an order request according to some non-limiting embodiments or aspects of this disclosure. The order in which methods 300 are described is not to be construed as limiting, and the methods can be implemented by combining any number of the described method blocks in any order. Furthermore, individual blocks can be removed from the methods without departing from the spirit and scope of the subject matter described herein. Moreover, the methods can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0080] In some non-limiting embodiments or aspects, a user (101) may initiate a payment transaction with a merchant (102) in response to an order request. The merchant (102) may be at least one of a store, an e-commerce application, etc., including a POS device connected to the merchant (102). The order request issued by the user (101) may be at least one of purchasing one or more goods, requesting one or more services, etc. The payment transaction may be initiated using at least one of card transactions, archived card transactions, etc., as indicated by the message flow (401), such as... Figure 4 As shown in the diagram. The transaction is sent via gateway (103) to the acquiring bank associated with the merchant (102), whereby the acquiring bank further requests the issuing server (105) to authorize and / or authenticate the transaction via gateway (103) and directory server (104). Furthermore, the issuing server (105) verifies the transaction by verifying at least one of the following: card details, billing address, card verification value (CVV) number, etc. Based on the verification, the issuing server (105) approves or rejects the transaction and may send an appropriate success or failure message to the merchant (102) via directory server (104) and gateway (103). The failure message may include the reason for rejecting the transaction and at least one of the error codes. Upon receiving a failure message, the merchant (102) may request a guarantee server (106) to provide a guarantee for a portion of the total amount associated with the transaction or one of the total amount.

[0081] refer to Figure 3 In step 301, the server (106) is ensured to receive information about the transaction between the user (101) and the merchant (102), as well as information about errors occurring during the processing of the transaction. Errors occurring during transaction processing include at least one of message failures, hardware failures, and network failures, such as... Figure 4 As shown in the diagram. Message failures may include authorization rejection for a transaction message, settlement rejection for a transaction message, etc. Hardware failures may include the inoperability of one or more hardware components, such as routers, network switches, servers, etc. Network failures may include connectivity problems associated with the merchant (102), gateway (103), directory server (104), and issuer server (105). For example, due to a network failure, a response to a transaction from the issuer server (105) may fail to be delivered to the directory server (104). In another example, the merchant (102) may receive information about an error indicating "limit exceeded" with error code "2002".

[0082] In some non-limiting embodiments or aspects, errors in transaction processing may occur for various reasons, including but not limited to: reaching card limits or insufficient funds, the total amount associated with the transaction exceeding the maximum allowed amount for a single transaction, reaching the maximum allowed number of transactions within a time period, the card not being allowed to accept transactions from online sources, international transactions not being permitted, the card not being authorized for transactions for the categorized mail / telephone order type, invalid expiry date, invalid card number, invalid billing address, etc. The server (106) is guaranteed to store the transaction information for re-initiating the transaction after a second predefined time period.

[0083] refer to Figure 3 In step 302, the guarantee server (106) receives from the merchant (102) an indication of a portion of the total amount or a guarantee value of the total amount associated with the transaction in order to fulfill the user's (101) order request. The merchant (102) sends the guarantee value to the guarantee server (106) after determining an error that occurred while processing the transaction, as indicated by the message stream (402), such as... Figure 4 As shown in the diagram. For example, if the total amount associated with a transaction is $500, the guarantee server (106) may receive a guarantee value of $450 from the merchant (102), which indicates that the merchant (102) is willing to fulfill the user's (101) order request upon receiving a guarantee or warranty for the guarantee value. Continue to refer to Figure 3 In step 303, the guarantee server (106) requests one or more entities (107A, 107B, ..., 107N) to provide at least one of the partial or full values ​​of the guarantee value received from the merchant (102).

[0084] In some non-limiting embodiments or aspects, it is guaranteed that the server (106) can share information about transactions and errors that occur during transaction processing with one or more entities (107A, 107B, ..., 107N), as indicated by message flows (403A, 403B, ..., 403N), such as Figure 4 As shown in the diagram. For example, after sharing information about the transaction and the errors associated with the transaction, the guarantee server (106) requests one or more entities (107A, 107B, ..., 107N) to provide a guarantee of $450, where the total amount associated with the transaction is $500.

[0085] In step 304, in response to the request, the server (106) is guaranteed to receive contribution values ​​from each of one or more entities (107A, 107B, ..., 107N), as indicated by the message flow (403A, 403B, ..., 403N), such as Figure 4 As shown, the contribution value is one of the portion or all of the guarantee value. The contribution value of each of one or more entities (107A, 107B, ..., 107N) is determined using a risk level obtained from one or more parameters associated with at least one of the user (101), the merchant (102), and the order request. The one or more parameters include at least one of the following: user information, BIN, transaction logs, merchant information, order request details, past transactions of the user (101), past transactions of the merchant (102), or any combination thereof.

[0086] In some non-limiting embodiments or aspects, each of one or more entities (107A, 107B, ..., 107N) may use an artificial intelligence (AI)-based learning algorithm to determine the risk level of a transaction based on one or more parameters associated with at least one of the user (101), the merchant (102), information about the transaction, errors occurring during transaction processing, and the order request. Based on the determined risk level, each of the one or more entities (107A, 107B, ..., 107N) may determine a contribution value.

[0087] In some non-limiting embodiments or aspects, the risk level determined for a transaction may be classified as a safe transaction, a low-risk transaction, a medium-risk transaction, a high-risk transaction, and a very high-risk transaction based on a risk percentage. For example, a risk percentage of 10% may be classified as a safe transaction, while a risk percentage of 85% may be classified as a high-risk transaction. Furthermore, the one or more entities (107A, 107B, ..., 107N) may determine a contribution value based on the determined risk level. For example, entity 1 (107A) may contribute $20 based on a determined risk level of 14%, while entity N (107N) may contribute $0 based on a determined risk level of 90%, and so on. For example, for a guarantee value of $450 and a total amount of $500 associated with the transaction, the guarantee server (106) may receive a contribution value of $100 from entity 1 (107A), a contribution value of $50 from entity 2 (107B), and a contribution value of $300 from entity N (107N) based on the determined risk level.

[0088] In some non-limiting embodiments or aspects, the guarantee server (106) may wait for responses to requests from one or more entities (107A, 107B, ..., 107N) for a first predefined time period. For example, the predefined time period may be set to 4 minutes from the timestamp when the request is sent to one or more entities (107A, 107B, ..., 107N). After the first predefined time period, when a response to the request is received from one or more entities (107A, 107B, ..., 107N), the guarantee server (106) may reject the response. Furthermore, the guarantee server (106) may reject responses from the one or more entities (107A, 107B, ..., 107N) when it receives a sum of contribution values ​​equal to the guarantee value within the first predefined time period.

[0089] refer to Figure 3 In step 305, the guarantee server (106) provides the merchant (102) with a guarantee message indicating successful payment to fulfill the user's (101) order request when it determines that the total contribution value received from one or more entities (107A, 107B, ..., 107N) has reached the guarantee value.

[0090] The guarantee server (106) determines the sum of the contribution values ​​received from each of one or more entities (107A, 107B, ..., 107N). The total contribution value received from one or more entities (107A, 107B, ..., 107N) is compared with the guarantee value requested by the merchant (102). When the total contribution value equals the guarantee value, the guarantee server (106) sends a guarantee message to the merchant (102), as indicated by the message flow (402). Upon receiving the guarantee message, the merchant (102) fulfills or completes the user's (101) order request. When the total contribution value is less than the guarantee value, the guarantee server (106) sends a message to the merchant (102) indicating that it cannot provide a guarantee or warranty for the requested guarantee value. Furthermore, the merchant (102) may reject the user's (101) order request. The merchant (102) may require the user (101) to initiate a new payment transaction to fulfill the order request.

[0091] Figure 5 A flowchart is shown illustrating method steps for re-initiating a transaction between a user (101) and a merchant (102) according to some non-limiting embodiments or aspects. The order in which method 500 is described is not to be construed as limiting, and the method can be implemented by combining any number of the described method blocks in any order. Furthermore, individual blocks can be removed from the method without departing from the scope of the subject matter described herein. Moreover, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0092] In step 501, if an error occurs while processing a transaction between the user (101) and the merchant (102) and it is ensured that the server (106) has fulfilled the order request associated with the transaction, after receiving information about the transaction, it is ensured that the server (106) re-initiates the stored transaction via the gateway (103) after a second predefined time period, as indicated by the message flow (601). Figure 6 As shown in the diagram, the guarantee server (106) fulfills the user's (101) order request by determining, providing, and / or transmitting a guarantee or warranty for the value of the guarantee requested by the merchant (102).

[0093] In some non-limiting embodiments or aspects, re-initiating the transaction includes inserting a value into one or more fields of the transaction message of the transaction, thereby indicating that the transaction be re-initiated after a second predefined time period, wherein the transaction failed due to an error that occurred while processing the transaction. Furthermore, one or more fields in the transaction message include at least one of a Message Type Indicator (MTI), a bitmap, or a data element. In some non-limiting embodiments or aspects, the server (106) ensures that the server (106), on behalf of the merchant (102), provides the re-initiated transaction to the issuer server (105) via a gateway (103) and a directory server (104) for authentication and / or authorization to complete the transaction.

[0094] In step 502, the server (106) is ensured to receive a response to the initiated transaction from the issuer server (105) via the directory server (104) and gateway (103), as indicated by the message flow (601), such as Figure 6 As shown, the response includes at least one of a success or failure message. For example, if the error that occurs during transaction processing is "maximum number of transactions allowed in a time period has been reached," then re-initiating the transaction after a second predefined time period can result in successful completion of the transaction. In another example, if the error that occurs during transaction processing is "total amount associated with the transaction exceeds the maximum amount allowed in a single transaction," then re-initiating the transaction at a later point in time, where the user (101) has requested the issuing server (105) to increase the credit limit associated with the user's (101) card, can result in successful completion of the transaction.

[0095] In step 503, upon receiving a success message, the assurance server (106) receives from the merchant (102) and / or determines, based on available information, the total amount associated with the transaction between the user (101) and the merchant (102), as indicated by the message flow (602). In some non-limiting embodiments or aspects, the assurance server (106) receives a success message from the issuing server (105) regarding the initiated transaction. Furthermore, after the merchant (102) receives the total amount associated with the transaction from the issuing server (105) after the settlement process, the assurance server (106) can receive the total amount from the merchant (102).

[0096] In step 504, as Figure 6The message streams shown (603A, 603B, ..., 603N) indicate that the guarantee server (106) allocates contribution values ​​and supplementary values ​​based on contribution values ​​from the total amount to each of one or more entities (107A, 107B, ..., 107N), wherein the contribution value of the one or more entities (107A, 107B, ..., 107N) is at least one of the parts or all of the guarantee value, wherein the guarantee value is a part of the total amount associated with the transaction.

[0097] In some non-limiting embodiments or aspects, the assurance server (106) may use equation (1) to determine the supplementary value. For example, if the assurance value is $450, the total amount associated with the transaction is $500, the contribution value of entity 1 (107A) is $100, the contribution value of entity 2 (107B) is $50, and the contribution value of entity N (107N) is $300. The assurance server (106) assigns the contribution value and the supplementary value determined using equation (1) to each of one or more entities (107A, 107B, ..., 107N). The assurance server (106) provides entity 1 (107A) with a contribution value of $100 and a determined supplementary value of $11.11, entity 2 (107B) with a contribution value of $50 and a determined supplementary value of $5.55, and entity N (107N) with a contribution value of $300 and a determined supplementary value of $33.33.

[0098] In step 505, upon receiving a failure message, the server (106) is guaranteed to perform at least one of the following: initiate a transaction between the user (101) and the merchant (102) after a second predefined time period, or abandon the transaction, as indicated by the message stream (601), such as Figure 6 As shown in the diagram. For example, if the error message is "card limit reached" and the user (101) has requested the issuing server (105) to increase the credit limit, the increased credit limit will be reflected after 30 minutes. It is guaranteed that if the server (106) initiates a transaction within 30 minutes, it may receive a failure message, but if it initiates a transaction after 30 minutes, the transaction will be successfully completed. In some non-limiting embodiments or aspects, the transaction is discarded after initiating a transaction for a predefined value and receiving a failure message. For example, it is guaranteed that the server (106) discards the transaction after initiating 10 transactions and receiving a failure message in each of those 10 initiations.

[0099] Therefore, the guarantee server (106) implements methods for fulfilling the order requests of the user (101). The guarantee server (106) provides a guarantee or warranty for the guaranteed value requested by the merchant (102) in near real-time or for a shorter duration, such as 10 minutes. In addition, one or more entities (107A, 107B, ..., 107N) that provide the contributing value receive a reward of supplementary value. Successful order fulfillment increases the number of transactions for the merchant (102) and provides better customer satisfaction.

[0100] Computer system

[0101] Figure 7 A block diagram of an exemplary computer system (700) for implementing embodiments consistent with this disclosure is shown. In some non-limiting embodiments or aspects, the computer system (700) may be used to implement a method for fulfilling an order request from a user (101). The computer system (700) may include a central processing unit (“CPU” or “processor”) (702). The processor (702) may include at least one data processor for executing program components for dynamic resource allocation at runtime. The processor (702) may include dedicated processing units, 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.

[0102] The processor (702) can be configured 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 employ 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), RF antenna, S-Video, VGA, IEEE 802.1n / 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.

[0103] Using the I / O interface (701), the computer system (700) can communicate with one or more I / O devices. For example, input devices (710) can be antennas, keyboards, mice, joysticks, (infrared) remote controls, cameras, card readers, fax machines, dongles, biometric readers, microphones, touchscreens, touchpads, trackballs, styluses, scanners, storage devices, transceivers, video devices / sources, etc. Output devices (711) can be printers, fax machines, video displays (e.g., cathode ray tube (CRT), liquid crystal displays (LCD), light-emitting diodes (LEDs), plasma displays, plasma display panels (PDP), organic light-emitting diode displays (OLEDs), etc.), audio speakers, etc.

[0104] In some non-limiting embodiments or aspects, the computer system (700) is connected to a service provider via a communication network (709). The processor (702) may be configured to communicate with the communication network (709) via a network interface (703). The network interface (703) may communicate with the communication network (709). The network interface (703) may 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) may include, but is not limited to, direct interconnect, e-commerce networks, peer-to-peer (P2P) networks, local area networks (LANs), wide area networks (WANs), wireless networks (e.g., using Wireless Application Protocol), the Internet, etc. Using a network interface (703) and a communication network (709), the computer system (700) can communicate with one or more service providers.

[0105] In some non-limiting embodiments or aspects, the processor (702) may be arranged to communicate with the memory (705) via a storage interface (704) (e.g., Figure 7 (RAM, ROM, etc., not shown) communication. A storage interface (704) can be connected to a memory (705), including but not limited to memory drives, removable optical disc drives, etc., using connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Electronic Drive (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer System Interface (SCSI), etc. Memory drives may also include drums, disk drives, magneto-optical drives, optical disc drives, redundant arrays of independent optical discs (RAID), solid-state storage devices, solid-state drives, etc.

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

[0107] An operating system (707) facilitates resource management and operation of a computer system (700). Examples of operating systems include, but are not limited to, those mentioned above. OS UNIX-like system distributions (e.g., BERKELEYSOFTWARE) (BSD) OPENBSD, etc. Distirizations (e.g., RED) wait), ( (7 / 8, 10, etc.) OS, etc.

[0108] In some non-limiting embodiments or aspects, the computer system (700) may implement a program component stored in a web browser (not shown). The web browser (not shown) may be a hypertext viewing application, such as... INTERNET Secure web browsing can be provided using protocols such as Hypertext Transfer Protocol Secure (HTTPS), Secure Sockets Layer (SSL), and Transport Layer Security (TLS). Web browsers can use technologies such as AJAX, DHTML, etc. Tools such as application programming interfaces (APIs). In some non-limiting embodiments or aspects, the computer system (700) may implement program components stored in a mail server (not shown). The mail server may be an Internet mail server, for example... The mail server (not shown in the diagram) can use, for example, Dynamic Server Pages (ASP), C++ / C# NET, CGI SCRIPTS PHP Tools such as Internet Message Access Protocol (IMAP) and Messaging Application Programming Interface (MAPI) can be used by mail servers. Communication protocols such as Exchange, Post Office Protocol (POP), and Simple Mail Transfer Protocol (SMTP) are used. In some non-limiting embodiments or aspects, the computer system (700) may implement a program component stored in an email client (not shown). The email client (not shown) may be an email viewing application, such as... MAIL wait.

[0109] Furthermore, one or more computer-readable storage media may be used to implement embodiments according to the invention. A computer-readable storage medium refers to any type of physical memory that can store information or data readable by a processor. Therefore, a computer-readable storage medium can store instructions executable 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, such as non-transient signals. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard disk drives, optical disc (CD) ROMs, digital video discs (DVDs), flash drives, magnetic disks, and any other known physical storage media.

[0110] In some non-limiting embodiments or aspects, the computer system (700) may receive at least one of a guarantee value, transaction information (205), and contribution value from a remote device (712) via a communication network (709).

[0111] Unless otherwise expressly specified, the terms “an embodiment,” “an embodiment,” “multiple embodiments,” “the embodiment,” “the multiple embodiments,” “one or more embodiments,” “some non-limiting embodiments or aspects,” and “an embodiment” mean “one or more (but not all) embodiments of the invention.”

[0112] The description of embodiments having several components communicating with each other does not imply that all of these components are required. Rather, various optional components are described to illustrate various possible embodiments of this disclosure.

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

[0114] Figure 3 and Figure 5 The operations illustrated show certain events occurring in a particular order. In alternative embodiments, some operations may be performed, modified, or removed in a different order. Furthermore, steps may be added to the logic described above, and these steps still conform to the described embodiments. Additionally, the operations described herein may be performed sequentially, or some operations may be processed in parallel. However, operations may be performed by a single processing unit or distributed processing units.

[0115] Finally, the language used in this specification has been chosen primarily for readability and edibility purposes, and not for defining or limiting the subject matter of the invention. Therefore, it is intended that the scope of the invention not be limited by this detailed description, but rather by any claims of the application based thereon. Consequently, the disclosure of embodiments of the invention is intended to be illustrative and not to limit the scope of the invention, which is set forth in the appended claims.

[0116] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The aspects and embodiments disclosed herein are for illustrative purposes and are not intended to be limiting, wherein the true scope and spirit are indicated by the appended claims.

Claims

1. A computer-implemented method, comprising: At least one processor of a guarantee server deployed in the payment processing network receives information about a transaction between a user and a merchant, as well as information about errors that occur during the processing of the transaction, the errors including at least one of the following: message failure, hardware failure, network failure, or any combination thereof; The at least one processor receives from the merchant a guarantee value, which is a portion of the total amount associated with the transaction from the merchant, as an indication for fulfilling the user's order request, wherein the merchant transmits the guarantee value to the guarantee server after becoming aware of the error that occurred while processing the transaction; The at least one processor requests one or more entities to provide at least one of the portion or all of the guarantee value received from the merchant; In response to a request from the one or more entities to provide at least one of the portions or all of the guarantee values ​​received from the merchant, a contribution value is received from each of the one or more entities by the at least one processor, wherein the contribution value is one of the portions or all of the guarantee values; In response to determining that the total contribution values ​​received from the one or more entities have reached the guarantee value, a guarantee message indicating successful payment is transmitted to the merchant via the at least one processor to fulfill the user's order request; as well as The transaction is re-initiated by the at least one processor by copying the transaction and sending it to the issuer server in the payment processing network; The guaranteed value indicates the minimum amount that the merchant will receive from the one or more entities when the transaction is resubmitted for authentication and / or authorization after a second predefined time period following a transaction failure or rejection by the issuing server.

2. The method of claim 1, wherein the one or more entities include at least one of financial institutions and individuals.

3. The method of claim 1, wherein the response to the request is received from the one or more entities within a first predefined time period.

4. The method of claim 1, wherein responses to the request from the one or more entities are rejected after a first predefined time period.

5. The method of claim 1, wherein the user's order request is rejected when it is determined that the contribution value received from the one or more entities is not equal to the guarantee value.

6. The method of claim 1, wherein the at least one processor, the merchant, and the one or more entities are connected via a communication network.

7. The method of claim 1, wherein a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: the user, the merchant, the order request, or any combination thereof.

8. The method of claim 7, wherein the one or more parameters include at least one of the following: user information, bank identification number (BIN), transaction log information, merchant information, details of the order request, the user's past transactions, the merchant's past transactions, or any combination thereof.

9. A guarantee server, deployed in a payment processing network, comprising: At least one processor; as well as A memory communicatively coupled to the at least one processor, wherein the memory stores processor instructions that, when executed, cause the at least one processor to: Receive information about transactions between users and merchants, as well as information about errors that occurred while processing the transactions, the errors including at least one of the following: message failure, hardware failure, network failure, or any combination thereof; The merchant receives a guarantee value, which is a portion of the total amount associated with the transaction from the merchant, as an indication to fulfill the user's order request, wherein the merchant transmits the guarantee value to the guarantee server after becoming aware of the error that occurred while processing the transaction. Request one or more entities to provide at least one of the portion or all of the guarantee value received from the merchant; In response to the request, a contribution value is received from each of the one or more entities, wherein the contribution value is one of the portion or all of the guaranteed value; In response to determining that the total contribution value received from the one or more entities has reached the guarantee value, a guarantee message indicating successful payment is sent to the merchant to fulfill the user's order request; as well as The transaction is re-initiated by copying the transaction and sending it to the issuer server in the payment processing network; The guaranteed value indicates the minimum amount that the merchant will receive from the one or more entities when the transaction is resubmitted for authentication and / or authorization after a second predefined time period following a transaction failure or rejection by the issuing server.

10. The guarantee server of claim 9, wherein the one or more entities include at least one of financial institutions and individuals.

11. The guarantee server of claim 9, wherein the at least one processor is configured to receive the response to the request from the one or more entities within a first predefined time period.

12. The guarantee server of claim 9, wherein the at least one processor is configured to reject the response to the request from the one or more entities after a first predefined time period.

13. The guarantee server of claim 9, wherein the at least one processor is configured to send a message indicating that the contribution value received from the one or more entities is not equal to the guarantee value to the merchant, so that the merchant rejects the user's order request.

14. The guarantee server of claim 9, wherein a risk level is used to determine the contribution value from each of the one or more entities, the risk level being obtained from one or more parameters associated with at least one of the following: the user, the merchant, the order request, or any combination thereof.

15. A computer-implemented method, comprising: When an error occurs while processing a transaction between a user and a merchant and the guarantee server has fulfilled the order associated with the transaction, the transaction is re-initiated by at least one processor of the guarantee server deployed in the payment processing network after receiving information about the transaction, wherein the error includes at least one of the following: message failure, hardware failure, network failure, or any combination thereof; In response to receiving a success message: receiving or determining, via at least one processor, the total amount associated with the transaction between the user and the merchant, and via at least one processor, allocating a contribution value and a supplementary value based on the contribution value from the total amount to each of the one or more entities, wherein the contribution value of the one or more entities is at least one of a portion or all of a guarantee value, wherein the guarantee value is a portion of the total amount associated with the transaction; and In response to receiving a failure message, at least one of the following is performed by at least one processor: re-initiating the transaction between the user and the merchant after a second predefined time period, and discarding the transaction; Re-initiating the transaction includes copying the transaction and sending it to the issuer server in the payment processing network; The guaranteed value indicates the minimum amount that the merchant will receive from the one or more entities when the transaction is resubmitted for authentication and / or authorization after a second predefined time period following a transaction failure or rejection by the issuing server.

16. The method of claim 15, wherein the re-initiated transaction is discarded after the transaction is initiated for a predefined value and the failure message is received.

17. The method of claim 15, wherein re-initiating the transaction comprises inserting a value into one or more fields of the transaction message of the re-initiated transaction by at least one processor, thereby indicating that the transaction is re-initiated after the second predefined time period, and wherein the re-initiated transaction failed due to the error that occurred while processing the transaction.

18. The method of claim 15, wherein the one or more fields in the transaction message include at least one of the following: a message type indicator (MTI), a bitmap, a data element, or any combination thereof.

Images