WO2020194239A1

WO2020194239A1 - Method, system and payment terminal for providing reliable communication network for payment transactions

Info

Publication number: WO2020194239A1
Application number: PCT/IB2020/052878
Authority: WO
Inventors: Vaddadi Poorna Chandu; Gaurav Mehrotra
Original assignee: Innoviti Payment Solutions Private Limited
Priority date: 2019-03-26
Filing date: 2020-03-26
Publication date: 2020-10-01

Abstract

Embodiments herein disclose a method, system 100 and payment terminal 102 for providing reliable communication network for payment transactions. The payment terminal 102 is configured to transmit asynchronously, transaction request to a payment gateway 106 through an intermediate sender unit 104 using a first communication session. The intermediate sender unit 104 is implemented using at least one of a message queue and a direct communication. The payment terminal 102 is configured to receive asynchronously transaction response for the transaction request, from the payment gateway 106 through an intermediate receiver unit 108 using the second communication session. The intermediate receiver unit 108 is implemented using at least one of a message queue and a direct communication. The transaction response is generated by the payment gateway 106 upon processing of the transaction request.

Description

TITLE: METHOD, SYSTEM AND PAYMENT TERMINAL FOR PROVIDING RELIABLE COMMUNICATION NETWORK FOR PAYMENT TRANSACTIONS

TECHNICAL FIELD

[0001] The present subject matter relates generally to payment architectures. More particularly, but not exclusively, discloses a method, system, and payment terminal for providing reliable communication network for payment transactions.

BACKGROUND

[0002] In general, electronic payment systems allow users to perform payment transactions with financial institutions or merchants (i.e., peer-to-business payment transactions). The payment transaction may be processed using a point-to-point communication between host and target systems such as payment terminal (or Point of Sale (POS) terminal) and payment gateway respectively. The point-to-point communication between host and target systems may be synchronous communication, by keeping the connection alive between the host and target systems until the response is received from the target system. The synchronous communication may be subjected to intermittent network issues that may occur anywhere across the communication path between the host and target systems. The communication path may involve a multitude of network elements such as firewalls at the target system, the firewall at Internet Service Provider (ISP), a router at ISP, network switches in local area networks, hardware load balancers, and so on, which may have varying network reliability. Further, due to network conditions, several issues may occur, and the issues may be beyond the control of the host and target systems. The delayed or lack of response may be detected due to network issues, that may cause a connection timeout at the target or host systems. Consequently, the connection may be tom down forcefully, and the payment/sale transaction may be lost abruptly. Accordingly, due to the abrupt termination of a transaction by tearing down the live connection, the current state of the transaction may not be known.

[0003] Additionally, depending on the state in which the transaction is abruptly terminated, an amount may be debited twice, which can be a poor experience for the customer and may have additional operational overhead for the financial institutions and payment gateways. For example, the double debit may occur when the transaction has reached a state that the transaction has been approved by the financial institution and the user received a confirmation from the financial institution, but the transaction is terminated before the merchant receives a confirmation. The merchant may bill the customer again, since the merchant may need to receive confirmation of approval from the financial institution regarding the transaction. In cases where there is a debit for the previously terminated transaction, the financial institution may need to track and refund the wrongly debited amount to the customer.

[0004] FIG. 1 illustrates a conventional architecture 10 comprising synchronous communication channel for payment transactions. As depicted in FIG. 1, the payment terminal 20 can be a host and the payment gateway 40 can be the target. Upon request for making a transaction by a user (such as merchant) via the payment terminal 20, the payment terminal 20 initiates a payment transaction using a credit/debit card and so on. A high-level communication flow/paths (1 to 6) involving the payment terminal 20, payment gateway 40, an acquiring financial institution server 60, and an issuing financial institution server 80 is depicted in FIG. 1. The communication paths 1 to 6 may represent the steps in the transaction process and the paths 1, 6 and 2, 5 may require network connectivity and may involve several multitude of network elements. The communication path 3a, 3b, ... and 4a, 4b, .... may also require network connectivity for authenticating and authorizing the transactions, however, under normal conditions there may be minimal network issues due to high reliability of the communication network between the acquiring financial institution server 60 and the issuing financial institution server 80. The segment of communication path 3a, 3b,... to 4a, 4b,... from acquiring financial institution server 60 to issuing financial institution server 80 and back to the acquiring financial institution server 40 may have internal communication and the internal communication may not be known to the payment gateway 40.

[0005] As an example, consider an amount may be debited twice when all the paths 1 through 5 are connected, and the payment is approved by the issuing financial institution server 60, but due to some reason, the path 6 fails and the payment terminal 20 does not receive the response to the transaction request from the payment gateway 40. If the response from the payment gateway 40 is not received, then the transaction may be treated as a failed transaction by the payment terminal 20. Accordingly, with several network elements along the communication paths 1 to 6, including at least one of, but not limited to, the firewall at the payment gateway, firewall at Internet Service Provider (ISP), the router at ISP, network switches in local area networks, hardware load balancers, and so on, it could be difficult to identify an intermittent, randomly repeating, and potentially drifting problem along the communication path. Further, a network congestion anywhere along the communication path at any network element therein, or a delayed response at each network element may add to the payment request timeout at the payment terminal, and that may also lead to debiting the amount twice for a single transaction.

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

SUMMARY

[0007] Disclosed herein is a method of providing a reliable communication network for payment transactions. The method includes transmitting asynchronously, by a payment terminal, a transaction request to a payment gateway through an intermediate sender unit using a first communication session. The intermediate sender unit is implemented using at least one of a message queue and a direct communication. The method includes receiving asynchronously, by the payment terminal, a transaction response for the transaction request, from the payment gateway through an intermediate receiver unit using a second communication session. The intermediate receiver unit implemented using at least one of a message queue and a direct communication.. The transaction response is generated by the payment gateway upon processing of the transaction request.

[0008] Further, the present disclosure includes a payment terminal for providing a reliable communication network for payment transactions, comprising a processor, and a memory communicatively coupled to the processor. The memory stores the processor instructions, which, on execution, causes the processor to transmit asynchronously a transaction request to a payment gateway through an intermediate sender unit using a first communication session. The intermediate sender unit is implemented using at least one of a message queue and a direct communication.. The processor is configured to receive asynchronously, a transaction response for the transaction request, from the payment gateway through an intermediate receiver unit using a second communication session. The intermediate receiver unit is implemented using at least one of a message queue and a direct communication. The transaction response is generated by the payment gateway upon processing of the transaction request.

[0009] Furthermore, the present disclosure includes a method of providing a reliable communication network for payment transactions. The method includes transmitting synchronously, by a payment terminal, a transaction request to a payment gateway using a third communication session. The method includes terminating, by the payment terminal, the third communication session between the payment terminal and the payment gateway upon transmitting the transaction request. The method includes receiving asynchronously, by the payment terminal, a transaction response for the transaction request, from the payment gateway through an intermediate receiver unit using a second communication session. The intermediate receiver unit is implemented using at least one of a message queue and a direct communication.. The transaction response is generated by the payment gateway upon processing of the transaction request.

[0010] Further, the present disclosure includes a payment terminal for providing a reliable communication network for payment transactions, comprising a processor and a memory communicatively coupled to the processor. The memory stores the processor instructions, which, on execution, causes the processor to transmit synchronously a transaction request to a payment gateway using a third communication session. The processor is configured to terminate the third communication session between the payment terminal and the payment gateway upon transmitting the transaction request. The processor is configured to receive asynchronously a transaction response for the transaction request, from the payment gateway through an intermediate receiver unit using a second communication session. The intermediate receiver unit is implemented using at least one of a message queue and a direct communication. The transaction response is generated by the payment gateway upon processing of the transaction request. [0011] Furthermore, the present disclosure includes a system for providing a reliable communication network for payment transactions, comprising a payment terminal, an intermediate sender unit, a payment gateway, and an intermediate receiver unit. The payment terminal is configured to transmit asynchronously a transaction request to a payment gateway through an intermediate sender unit using a first communication session. The intermediate sender is implemented using at least one of a message queue and a direct communication. The payment terminal is configured to receive asynchronously, a transaction response for the transaction request, from the payment gateway through an intermediate receiver unit using a second communication session. The intermediate receiver unit is at least implemented using at least one of a message queue and a direct communication.. Further, the payment gateway is configured to receive asynchronously the transaction request from the payment terminal through the intermediate sender unit using the first communication session. The payment gateway is configured to generate the transaction response upon processing the transaction request. The payment gateway is configured to transmit asynchronously, the transaction response for the transaction request through the intermediate receiver unit using the second communication session.

[0012] The foregoing summary is illustrative only and is not intended to be in any way limiting.

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 ACCOMPANYING DIAGRAMS

[0013] 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 disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which: [0014] FIG. 1 illustrates a conventional architecture comprising synchronous communication channel for payment transactions;

[0015] FIG. 2A illustrates a block diagram of a system for providing reliable communication network for payment transaction in accordance with some embodiments of the present disclosure;

[0016] FIG. 2B illustrates a detailed block diagram of a payment terminal for providing reliable communication network for payment transaction in accordance with some embodiments of the present disclosure;

[0017] FIG. 3A illustrates an exemplary architecture for providing reliable communication network for payment transaction using a fully asynchronous communication channel in accordance with some embodiments of the present disclosure;

[0018] FIG. 3B illustrates an exemplary architecture for providing reliable communication network for payment transaction using a combination of synchronous and asynchronous communication channel in accordance with some embodiments of the present disclosure;

[0019] FIG. 4A is a flowchart depicting a method of providing a reliable communication network for payment transaction using a fully asynchronous communication channel in accordance with some embodiments of the present disclosure;

[0020] FIG. 4B is a flowchart depicting a method of providing a reliable communication network for payment transaction using a combination of synchronous and asynchronous communication channel in accordance with some embodiments of the present disclosure; and

[0021] FIG. 5 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

[0022] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer-readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION

[0023] In the present document, the word "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.

[0024] While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure.

[0025] The terms“comprises”,“comprising”,“includes” or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that includes a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by“comprises... a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0026] Disclosed herein are method, system and a payment terminal for providing reliable communication networks for payment transaction. The system may provide an asynchronous communication channel between the payment terminal and a payment gateway for transmitting transaction requests and receiving transaction response. Further, the system may also provide an implicit asynchronous channel (or synchronous) channel for transmitting the transaction request to the payment gateway and an explicit asynchronous channel for receiving the transaction response from the payment gateway. The asynchronous channel may minimize payment failure for payment transactions due to the network failure between the payment terminal and the payment gateway.

[0027] The asynchronous communication channel between the payment terminal and the payment gateway may be achieved using a shorter connection by adding an intermediate sender unit/receiver unit between the payment terminal and the payment gateway. The intermediate sender unit/receiver unit eliminates the need for long communication sessions between the payment terminal and the payment gateway, to be kept live over the communication network. The intermediate sender unit/receiver unit may be implemented using an electronic message queue system. In particular, one or more embodiments provide integration of message queues with the payment transaction system that increase the speed and reliability of processing the payments. Specifically, due to the integrated message queues with the payment transaction system, the intermediate sender/receiver unit can process payment transactions between the payment terminal and the payment gateway using different message queues for the transaction request and the transaction response. For example, the intermediate sender unit/receiver unit can send and receive the payment transactions using a transaction request queue and a transaction response queue respectively. By providing separate queues for processing payments and receiving responses for the processed payments, the system can quickly process payment transactions and receive response for transaction response in parallel.

[0028] The system can process updates (e.g., payment initiation, cancellation, or modification) to the payments using the queue associated with the intermediate sender/receiver unit so that the system can keep track of the updates and push the updates to the payment terminal promptly. Further, the transaction request and transaction response specific queues can improve the reliability of the communication network. For instance, if the payment terminal or the payment gateway temporarily loses connectivity to the communication network, then the intermediate sender/receiver unit can store the transaction request/response and provide to the payment gateway /terminal respectively when the connectivity to the communication network is regained.

[0029] As used herein, the term“message” or“messages” or“message queues” or“queues” refer to any form of electronic communication between two or more computing devices. The message can be a data transported between the payment terminal and the payment gateway. An example of a message can be a message to start processing a task, the message could include information about a finished task, or a plain message. As used herein, the term“queue” refers to a communications medium that temporarily stores data sent to, and received from, payment terminal and payment gateway respectively. The queue can store new message data or message update data in a sequence in which the data arrives (e.g., by sequence ID), according to corresponding identifiers for the payment transactions, or according to other suitable types of storage methods. Further, the queue can be a line of tasks waiting to be handled, starting at the beginning of the line and processing it in sequential order. Accordingly, the message queue can be a queue of messages exchanged between the payment terminal and the payment gateway. The message queue includes a sequence of work/task objects that are waiting to be processed. The message queue facilitates the asynchronous communication channel, wherein the message is pushed onto the message queue (i.e. intermediate sender/receiver unit) and does not require an immediate transaction response within a connection time out period or within a same communication session. The transaction response or the status of the transaction may be received from the payment gateway via the intermediate receiver unit in a different communication session, within a predefined time (i.e. not connection timeout). Accordingly, based on handling the messages, the asynchronous communication channel decouples the payment terminal from the payment gateway, so that the payment terminal and the payment gateway may not need to interact with the message queues or with each other at the same time. As an example, either of the payment terminal and the payment gateway may not communicate with each other in a single communication session at the same time, due to the incorporation of the intermediate sender/receiver unit between the payment terminal and the payment gateway. The payment terminal/gateway tears the connection between the intermediate sender/receiver unit respectively, once the message is pushed to the intermediate sender/receiver unit and polls the intermediate sender/receiver unit respectively in consecutive different communication sessions or simultaneously using different communication session. The message/topic can be data such as transaction request/response, transported between the payment terminal and the payment gateway. The data can be sent together in the form of the queue or can be sent individually to the recipients to process the payment transaction. The topic can be the header/heading of the message for the transaction request/response. In addition, the term“transaction request” or“transaction response” may refer to a message that includes payment information that allows the payment terminal to initiate a payment transaction or receive status of the payment transaction respectively. For example, a payment request can include a payment amount, a sender, a recipient, a payment method, and so on. Further, a payment response can include an authentication/authorization failure, an amount debited, a transaction success/failure, and so on.

[0030] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

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

[0032] FIG. 2A illustrates a block diagram of a system 100 for providing a reliable communication network for payment transactions in accordance with some embodiments of the present disclosure.

[0033] The system 100 includes a payment terminal 102, an intermediate sender unit 104, a payment gateway 106, and an intermediate receiver unit 108. In an embodiment, the payment terminal 102 may be operated by a user/merchant. In an embodiment, the payment terminal 102 and intermediate sender unit 104 may be associated with the payment gateway 106 via a communication network (not shown in fig.). In an embodiment, the payment gateway 106 and the intermediate receiver unit 108 may be associated with the payment terminal 102 via a communication network (not shown in fig.). The communication network may be at least one of wired communication network and a wireless communication network. In an embodiment, the payment terminal 102 may be associated with a merchant or the like and include one or more applications to facilitate transactions and to generate an invoice for at least one item/service/purchase in a retail establishment. Further, the payment terminal 102 may include a plurality of hardware components such as at least one of, but not limited to a processor 110, an Input/Output (I/O) interface 112, and a memory 114, and so on. As an example, the payment terminal 102 can be at least one of, but not limited to, a card swiping machine, a payment machine, a card terminal, a Point of Sale (POS) terminal, an Electronic Data Capture (EDC) device, and so on. Further, the payment gateway 106 may facilitate the payment transaction by the transfer of information between the payment terminal 102 and an acquiring financial institution (not shown in FIG. 2A). The payment gateway 106 may be implemented using at least one of, but not limited to, a server, a payment server, a remote server, a cloud-based server, a client-server, and so on. Further, the payment gateway 106 may also include a plurality of hardware components such as at least one of, but not limited to a processor, an input/output (I/O) interface, and a memory (not shown in FIG. 2A), and so on. In an embodiment, the system 100 may also include a display for displaying transaction information and other display data. Each retail establishment may be equipped with the payment terminal 102 to facilitate retail transactions. Furthermore, the payment terminal 102 may be configured to receive transaction requests from the merchant and then forward it to the payment gateway 106. The payment terminal 102, in response, receives a transaction response from the payment gateway 106. However, the transaction request and the transaction response may be received by the intermediate sender unit 104 and the intermediate receiver unit 108 from the payment terminal 102 and the payment gateway 106 respectively.

[0034] In an embodiment, the intermediate sender unit 104 and the intermediate receiver unit 108 may be a message queue or a direct communication -based intermediate communication channel between the payment terminal 102 and the payment gateway 106 respectively. The intermediate sender unit 104 and the intermediate receiver unit 108 temporarily store the messages related to the transaction request and the transaction response respectively. Each of the message queues can store messages and updates according to sequence IDs. In an example, the message threads or payment transactions are optionally ordered by recency, so if a thread or transaction changes, the thread or transaction can be moved to the top of the respective queue by updating the sequence ID. Thus, as a change or update to a thread or transaction occurs, the queue can increase the sequence ID for the update/change. Further, the payment terminal 102 disconnects with the intermediate sender unit 104 after transmitting the transaction request. And the transaction response may be obtained from the intermediate receiver unit 108 in the intermediate communication channel, by polling the intermediate receiver unit 108.

[0035] In an embodiment, the payment terminal 102 or the payment gateway 106 can identify related messages (e.g., a message indicating a payment response or a payment transaction, respectively) within a messaging thread of the intermediate receiver unit 108 or the intermediate sender unit 104 respectively. Thus, the payment terminal 102 can send a message/topic via the intermediate sender unit 102 to the payment gateway 106 regarding the transaction request. Upon receiving the status of the payment, the payment gateway 106 can send a message/topic via the intermediate receiver unit 108 regarding the transaction response. Also, the transaction request/response may be transmitted as a transaction information (or as message) individually as a direct communication, without forming a message queue, to the payment gateway 106 or the payment terminal 102 respectively.

[0036] In an embodiment, the payment terminal 102 is configured to transmit asynchronously, the transaction request to the payment gateway 106 through the intermediate sender unit 104 using a first communication session. The first communication session can be a connection used for transmitting the transaction request to the intermediate sender unit 104. The intermediate sender unit 104 can be implemented using at least one of a message queue and a direct communication . The message can be a form of electronic communication between two or more computing devices such as the payment terminal 102 and payment gateway 106, that pass the data from intermediate sender unit 104 to the respective recipients such as payment gateway 106. As an example, the message may include the information that is needed to trigger the payment process. Further, the payment terminal 102 is configured to receive asynchronously, a transaction response for the transaction request, from the payment gateway 106 through the intermediate receiver unit 108 using a second communication session. The second communication session is a connection used for receiving the transaction response from the intermediate receiver unit 108 by the payment terminal 102. The intermediate receiver unit 108 is implemented using at least one of a message queue and a direct communication. Further, the transaction response is generated by the payment gateway 106 upon processing of the transaction request. The first communication session is terminated between the payment terminal 102 and the intermediate sender unit 104 upon asynchronously transmitting the transaction request. Further, the payment terminal 102 is switched to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit 108 upon transmitting the transaction request.

[0037] In an embodiment, the payment gateway 106 is configured to receive asynchronously the transaction request from the payment terminal 102 through the intermediate sender unit 104 using the first communication session. Further, the payment gateway 106 is configured to generate the transaction response upon processing the transaction request. The payment gateway 106 is configured to transmit asynchronously, the transaction response for the transaction request through the intermediate receiver unit 108 using the second communication session.

[0038] In an embodiment, the intermediate sender unit 104 is polled by the payment gateway

106, for the transaction request using a first intermediate communication session at predefined time intervals, and the intermediate receiver unit 108 is polled by the payment terminal 102, for the transaction response using a second intermediate communication session at predefined time intervals. The predefined time intervals can be, for example, every 5 seconds or 10 seconds (or based on requirement of the payment terminal 102) within a predefined time. The predefined time can be a period for each payment transaction, for example, 180-200 seconds. The first and second intermediate communication sessions may be temporary connections used for polling the transaction request and the transaction response, by the payment gateway 106 and the payment terminal 102 respectively. In an embodiment, the second intermediate communication session is terminated between the payment terminal 102 and the intermediate receiver unit 108 upon each polling for the transaction response. Further, the first intermediate communication session is terminated between the payment gateway 106 and the intermediate sender unit 108 upon each polling for the transaction request.

[0039] FIG. 2B illustrates a detailed block diagram of the payment terminal 102 for providing a reliable communication network for payment transactions in accordance with some embodiments of the present disclosure. [0040] In some implementations, the payment terminal 102 may include data 202 and modules 204. As an example, the data 202 is stored in the memory 114 configured in the payment terminal 102 as shown in the FIG. 2B. In one embodiment, the data 202 may include transaction request data 206, transaction response data 208, message queue data 210, and other data 212.

[0041] In an embodiment, the data 202 may be stored in the memory 114 in the form of various data structures. Additionally, the data 202 can be organized using data models, such as relational or hierarchical data models. The other data 212 may store data, including temporary data and temporary files, generated by the modules 204 for performing the various functions of the payment terminal 102.

[0042] In an embodiment, the data 202 stored in the memory 114 may be processed by the modules 204 of the payment terminal 102. The modules 204 may be stored within the memory 114. In an example, the modules 204 communicatively coupled to the processor 110 configured in the payment terminal 102, may also be present outside the memory 114 as shown in FIG. 2B and implemented as hardware. As used herein, the term modules refer to an application-specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

[0043] In an embodiment, the modules 204 may include at least one of, for example, an asynchronous transaction request transmission module 222, an asynchronous transaction response reception module 224, a transaction response polling module 226, a synchronous transaction request transmission module 228, a communication session termination module 230, and other modules 232. The other modules 232 may be used to perform various miscellaneous functionalities of the payment terminal 102. It will be appreciated that such aforementioned modules 204 may be represented as a single module or a combination of different modules.

[0044] In an embodiment, the asynchronous transaction request transmission module 222 may be configured to transmit asynchronously the transaction request to the payment gateway 106 through the intermediate sender unit 104 using the first communication session. The transaction request includes transaction request data 206. The intermediate sender unit 104 may be implemented using at least one of a message queue and a direct communication. The communication session termination module 230 is configured to terminate the first communication session between the payment terminal 102 and the intermediate sender unit 104 upon asynchronously transmitting the transaction request. Further, the payment terminal 102 is switched to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit 108 upon transmitting the transaction request. Further, the asynchronous transaction response reception module 224 is configured to receive asynchronously the transaction response for the transaction request, from the payment gateway 106 through the intermediate receiver unit 108 using the second communication session. The transaction response data 208 includes the transaction response. The intermediate receiver unit 108 is implemented using at least one of a message queue and a direct communication. The message queue data 210 includes the messages/topics. Further, the transaction response is generated by the payment gateway 104 upon processing of the transaction request. The asynchronous transmission of the transaction request to the payment gateway 106 and asynchronous reception of the transaction response from the payment gateway 106 is depicted in the FIG. 3A. As depicted in FIG. 3 A, at a path 1, the transaction request is transmitted from the payment terminal 102 to the intermediate sender unit 104. Further, at a path 2, the intermediate sender unit 104 may push/transmit the transaction request to the payment gateway 106 or the payment gateway 106 may poll the transaction request from the intermediate sender unit 104. At a path 3, the payment gateway 106 may transmit the transaction request to an acquiring financial institution server 302 for approval of the payment transaction. Further, at a path 4, the acquiring financial institution server 302 may transmit the approval request corresponding to the transaction request to an issuing financial institution server 304. At path 5, the acquiring financial institution server 302 may receive a status update corresponding to the approval request from the issuing financial institution server 304, regarding the transfer of funds, in response to the transaction request. At a path 6, the status is transmitted to the payment gateway 106 from the acquiring financial institution server 302. At a path 7, the payment gateway 106 may transmit the transaction response corresponding to the status, to the intermediate receiver unit 108. At a path 8, the intermediate receiver unit 108 may push/transmit the transaction response to the payment terminal 102 or the payment terminal 102 may poll the transaction response from the intermediate receiver unit 108. As an example, a protocol such as Representational State Transfer - Application Program Interface (REST - API) over Hypertext Transfer Protocol Secure (HTTPS) may be used in the intermediate sender unit 104 and the intermediate receiver unit 108 to ensure the integrity, security, and completeness of the transfer of transaction request and the transaction response over the intermediate sender unit 104 and the intermediate receiver unit 108.

[0045] In an embodiment, the transaction response polling module 226 is configured to poll the intermediate receiver unit 108 for the transaction response using the second intermediate communication session at predefined time intervals. Further, the intermediate sender unit 104 is polled for the transaction request using the first intermediate communication session, by the payment gateway 106 at predefined time intervals. The communication session termination module 230 is configured to terminate the second intermediate communication session between the payment terminal 102 and the intermediate receiver unit 108 upon each polling for the transaction response. Further, the first intermediate communication session between the payment gateway 106 and the intermediate sender unit 108 is terminated upon each polling for the transaction request.

[0046] In an embodiment, the synchronous transaction request transmission module 228 is configured to transmit synchronously a transaction request to the payment gateway 106 using a third communication session. The third communication session can be a connection used for transmitting the transaction request to the payment gateway 106. The synchronous transmission of the transaction request from the payment terminal 102 to the payment gateway 106 is depicted in the FIG. 3B. As depicted in FIG. 3B, at path 1, the transaction request is transmitted from the payment terminal 102 to the payment gateway 106. At a path 2, the payment gateway 106 may transmit the transaction request to an acquiring financial institution server 302 for approval of the payment transaction. Further, at a path 3, the acquiring financial institution server 302 transmits the approval request corresponding to the transaction request to an issuing financial institution server 304. At a path 4, the acquiring financial institution server 302 may receive a status update corresponding to the approval request from the issuing financial institution server 304, regarding the transfer of funds, in response to the transaction request. At a path 5, the status is transmitted to the payment gateway 106 from the acquiring financial institution server 302. At a path 6, the payment gateway 106 may transmit the transaction response corresponding to the status, to the intermediate receiver unit 108. At a path 7, the intermediate receiver unit 108 may push/transmit the transaction response to the payment terminal 102 or the payment terminal 102 may poll the transaction response from the intermediate receiver unit 108. In an embodiment, the communication session termination module 230 is configured to terminate the third communication session between the payment terminal 102 and the payment gateway 106 upon transmitting the transaction request. The termination of the third communication session depicts that the third communication is an implicit asynchronous transmission of the transaction request, where the connection is not kept alive until the transaction response is received by the payment terminal 102. The asynchronous transaction response reception module 224 is configured to receive asynchronously a transaction response for the transaction request, from the payment gateway 106 through the intermediate receiver unit 108 using a second communication session. The transaction response is generated by the payment gateway 106 upon processing of the transaction request. The transaction response polling module 226 is configured to poll the intermediate receiver unit 108 for the transaction response using the second intermediate communication session at predefined time intervals. Further, the communication session termination module 230 is configured to terminate the second intermediate communication session between the payment terminal 102 and the intermediate receiver unit 108 upon each polling for the transaction response. The payment terminal is switched to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit 108 upon transmitting the transaction request.

[0047] FIG. 4A is a flowchart depicting a method 400a of providing a reliable communication network for payment transactions using a fully asynchronous communication channel in accordance with some embodiments of the present disclosure.

[0048] As illustrated in FIG. 4A, the method 400a includes one or more blocks illustrating a method of providing a reliable communication network for payment transaction. The method 400a may be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types.

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

[0050] At block 402, the method may include transmitting asynchronously, by the processor

110, a transaction request to the payment gateway 106 through the intermediate sender unit 104 using a first communication session. The intermediate sender unit is implemented using at least one of a message queue and a direct communication. At block 404, the method may include receiving asynchronously, by the processor 110, a transaction response for the transaction request, from the payment gateway 106 through the intermediate receiver unit 108 using a second communication session. The intermediate receiver unit is implemented using at least one of a message queue and a direct communication. The transaction response is generated by the payment gateway 106 upon processing of the transaction request by the issuing financial institution server 304.

[0051] FIG. 4B is a flowchart depicting a method 400b of providing a reliable communication network for payment transactions using a combination of synchronous and asynchronous communication channels in accordance with some embodiments of the present disclosure.

[0052] As illustrated in FIG. 4B, the method 400b includes one or more blocks illustrating a method of providing a reliable communication network for payment transactions using a combination of synchronous and asynchronous communication channel. The method 400b may be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types. [0053] The order in which the method 400b is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400b. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 400b can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0054] At block 412, the method may include transmitting synchronously, by the processor

110, a transaction request to the payment gateway 106 using a third communication session. At block 414, the method may include terminating, by the processor 110, the third communication session between the payment terminal 102 and the payment gateway 106 upon transmitting the transaction request. The termination of the third communication session depicts that the third communication is an implicit asynchronous transmission of the transaction request, where the connection is not kept alive until the transaction response is received by the payment terminal 102. At block 416, the method may include receiving asynchronously, by the processor 110, a transaction response for the transaction request, from the payment gateway 106 through the intermediate receiver unit 108 using a second communication session. The intermediate receiver unit 108 is implemented using at least one of a message queue and a direct communication. The transaction response is generated by the payment gateway 106 upon processing of the transaction request by the issuing financial institution server 304.

[0055] FIG. 5 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

[0056] In an embodiment, FIG. 5 illustrates a block diagram of an exemplary computer system

500 for implementing embodiments consistent with the present invention. In an embodiment, the computer system 500 can be a payment terminal 102 that is used for providing reliable communication network for payment transactions. The computer system 500 may include a central processing unit (“CPU” or“processor”) 502. The processor 502 may include at least one data processor for executing program components for executing user or system-generated business processes. A user may include a person, a person using a device such as those included in this invention, or such a device itself. The processor 502 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.

[0057] The processor 502 may be disposed in communication with input devices 511 and output devices 512 via I/O interface 501. The I/O interface 501 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE- 1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S -Video, Video Graphics Array (VGA), IEEE 802. n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc.

[0058] Using the I/O interface 501, the computer system 500 may communicate with input devices 511 and output devices 512.

[0059] In some embodiments, the processor 502 may be disposed in communication with a communication network 509 via a network interface 503. The network interface 503 may communicate with the communication network 509. The network interface 503 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.1 la/b/g/n/x, etc. Using the network interface 503 and the communication network 509, the computer system 500 may communicate with a payment gateway 106 via an intermediate sender unit 104 and the payment gateway 106 may communicate with the computer system 500 via an intermediate receiver unit 108. The communication network 509 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 509 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 509 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In an embodiment, the processor 502 may be disposed in communication with a memory 505 (e.g., RAM, ROM, etc. not shown in FIG. 5) via a storage interface 504. The storage interface 504 may connect to memory 505 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

[0060] The memory 505 may store a collection of program or database components, including, without limitation, a user interface 506, an operating system 507, a web browser 508, etc. In some embodiments, the computer system 500 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase.

[0061] Operating system 507 may facilitate resource management and operation of the computer system 500. Examples of operating systems include, without limitation, APPLE^® MACINTOSH^® OS X^®, UNIX^®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION^® (BSD), FREEBSD^®, NETBSD^®, OPENBSD, etc.), LINUX^® DISTRIBUTIONS (E.G., RED HAT^®, UBUNTU^®, KUBUNTU^®, etc.), IBM^®OS/2^®, MICROSOFT^® WINDOWS^® (XP^®, VISTA^®/7/8, 10 etc.), APPLE^® IOS^®, GOOGLE™ ANDROID™, BLACKBERRY^® OS, or the like. User interface 506 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to computer system 500, such as cursors, icons, checkboxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple^® Macintosh^® operating systems’ Aqua^®, IBM^® OS/2^®, Microsoft^® Windows^® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX^®, Java^®, Javascript^®, AJAX, HTML, Adobe^® Flash^®, etc.), or the like.

[0062] Computer system 500 may implement a web browser 508 stored-program components.

Web browser 508 may be a hypertext viewing application, such as MICROSOFT^® INTERNET EXPLORER^®, GOOGLE™ CHROME™, MOZILLA^® FIREFOX^®, APPLE^® SAFARI^®, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browsers 508 may utilize facilities such as AJAX, DHTML, ADOBE^® FLASH^®, JAVASCRIPT^®, JAVA^®, Application Programming Interfaces (APIs), etc. Computer system 500 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as ASP, ACTIVEX^®, ANSI^® C++/C#, MICROSOFT^®,. NET, CGI SCRIPTS, JAVA^®, JAVASCRIPT^®, PERL^®, PHP, PYTHON^®, WEBOBJECTS^®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT^® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 500 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE^® MAIL, MICROSOFT^® ENTOURAGE^®, MICROSOFT^® OUTLOOK^®, MOZILLA^® THUNDERBIRD^®, etc.

[0063] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) 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, i.e., non- transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media. Advantages of the present disclosure.

[0064] Embodiments herein provide an asynchronous channel to minimize payment failures for payment transactions due to the network failure between the payment terminal and the payment gateway.

[0065] Embodiments herein provide the intermediate sender unit/receiver unit to eliminate the need for long communication sessions between the payment terminal and the payment gateway, to be kept live over the communication network.

[0066] Embodiments herein process updates (e.g., payment initiation, cancellation, or modification) to the payments using the corresponding queues, so that the intermediate receiver unit can keep track of the updates and push the updates to the payment terminal promptly.

[0067] Embodiments herein provide the transaction request and transaction response specific queues, for improving the reliability of the communication network. For instance, if the payment terminal or the payment gateway temporarily loses connectivity to the communication network, then the intermediate sender/receiver unit can store the transaction request/response and provide it to the payment gateway/terminal respectively when the connectivity to the communication network is regained.

[0068] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), 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 instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality /features. Thus, other embodiments of the invention need not include the device itself. [0069] The specification has described a method and a system for performing context-based application disablement on an electronic device. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms“a,”“an,” and“the” include plural references unless the context clearly dictates otherwise.

[0070] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

We claim:

1. A method of providing a reliable communication network for payment transactions, comprising: transmitting asynchronously, by a payment terminal (102), a transaction request to a payment gateway (106) through an intermediate sender unit (104) using a first communication session, wherein the intermediate sender unit (104) is implemented using at least one of a message queue and a direct communication; and

receiving asynchronously, by the payment terminal (102), a transaction response for the transaction request, from the payment gateway (106) through an intermediate receiver unit (108) using a second communication session, wherein the intermediate receiver unit (108) is implemented using at least one of a message queue and a direct communication, and wherein the transaction response is generated by the payment gateway (106) upon processing of the transaction request.

2. The method as claimed in claim 1, further comprising: polling the intermediate sender unit (104) for the transaction request using a first intermediate communication session and polling the intermediate receiver unit (108) for the transaction response using a second intermediate communication session, by the payment gateway (106) and the payment terminal (102) respectively at predefined time intervals.

3. The method as claimed in claim 2, further comprising terminating the second intermediate communication session between the payment terminal (102) and the intermediate receiver unit (108) upon each polling for the transaction response.

4. The method as claimed in claim 2, further comprising terminating the first intermediate communication session between the payment gateway (106) and the intermediate sender unit (104) upon each polling for the transaction request.

5. The method as claimed in claim 1, further comprising terminating the first communication session between the payment terminal (102) and the intermediate sender unit (104) upon asynchronously transmitting the transaction request.

6. The method as claimed in claim 1, wherein the payment terminal (102) is switched to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit (108) upon transmitting the transaction request.

7. A payment terminal (102) for providing reliable communication network for payment transactions, comprising:

a processor (110); and

a memory (114) communicatively coupled to the processor (110), wherein the memory (114) stores the processor instructions, which, on execution, causes the processor (110) to: transmit asynchronously a transaction request to a payment gateway (106) through an intermediate sender unit (104) using a first communication session, wherein the intermediate sender unit (104) is implemented using at least one of a message queue and a direct communication; and

receive asynchronously, a transaction response for the transaction request, from the payment gateway (106) through an intermediate receiver unit (108) using a second communication session, wherein the intermediate receiver unit (108) is implemented using at least one of a message queue and a direct communication, and wherein the transaction response is generated by the payment gateway (106) upon processing of the transaction request.

8. The payment terminal (102) as claimed in claim 7, wherein the processor is further configured to: poll the intermediate sender unit (104) for the transaction request using a first intermediate communication session and poll the intermediate receiver unit (108) for the transaction response using a second intermediate communication session, by the payment gateway (106) and the payment terminal (102) respectively at predefined time intervals.

9. The payment terminal (102) as claimed in claim 8, wherein the processor is further configured to terminate the second intermediate communication session between the payment terminal (102) and the intermediate receiver unit (108) upon each polling for the transaction response.

10. The payment terminal (102) as claimed in claim 8, wherein the first intermediate communication session is terminated between the payment gateway (106) and the intermediate sender unit (104) upon each polling for the transaction request.

11. The payment terminal (102) as claimed in claim 7, wherein the processor is further configured to terminate the first communication session between the payment terminal (102) and the intermediate sender unit (104) upon asynchronously transmitting the transaction request.

12. The payment terminal (102) as claimed in claim 7, wherein the processor is further configured to switch to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit (108) upon transmitting the transaction request.

13. A method of providing a reliable communication network for payment transactions, comprising: transmitting synchronously, by a payment terminal (102), a transaction request to a payment gateway (106) using a third communication session;

terminating, by the payment terminal (102), the third communication session between the payment terminal (102) and the payment gateway (106) upon transmitting the transaction request; and

14. The method as claimed in claim 13, further comprising: polling, by the payment terminal (102), the intermediate receiver unit (108) for the transaction response using a second intermediate communication session at predefined time intervals.

15. The method as claimed in claim 14, further comprising terminating the second intermediate communication session between the payment terminal (102) and the intermediate receiver unit (108) upon each polling for the transaction response.

16. The method as claimed in claim 13, wherein the payment terminal (102) is switched to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit (108) upon transmitting the transaction request.

17. A payment terminal (102) for providing reliable communication network for payment transactions, comprising:

a processor (110); and

a memory (114) communicatively coupled to the processor (110), wherein the memory (114) stores the processor instructions, which, on execution, causes the processor (110) to: transmit synchronously a transaction request to a payment gateway (106) using a third communication session;

terminate the third communication session between the payment terminal (102) and the payment gateway (106) upon transmitting the transaction request; and

receive asynchronously a transaction response for the transaction request, from the payment gateway (106) through an intermediate receiver unit (108) using a second communication session, wherein the intermediate receiver unit (108) is implemented using at least one of a message queue and a direct communication, and wherein the transaction response is generated by the payment gateway (106) upon processing of the transaction request.

18. The payment terminal (102) as claimed in claim 17, wherein the processor is further configured to: poll the intermediate receiver unit (108) for the transaction response using a second intermediate communication session at predefined time intervals.

19. The payment terminal (102) as claimed in claim 18, wherein the processor is further configured to terminate the second intermediate communication session with the intermediate receiver unit (108) upon each polling for the transaction response.

20. The payment terminal (102) as claimed in claim 17, wherein the processor is further configured to switch to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit (108) upon transmitting the transaction request.

21. A system (100) for providing a reliable communication network for payment transactions, comprising:

a payment terminal (102);

an intermediate sender unit (104);

a payment gateway (106); and

an intermediate receiver unit (108); the payment terminal (102) is configured to: transmit asynchronously a transaction request to a payment gateway (106) through an intermediate sender unit (104) using a first communication session, wherein the intermediate sender is implemented using at least one of a message queue and a direct communication;

receive asynchronously, a transaction response for the transaction request, from the payment gateway (106) through an intermediate receiver unit (108) using a second communication session, wherein the intermediate receiver unit (108) is implemented using at least one of a message queue and a direct communication; and the payment gateway (106) is configured to: receive asynchronously the transaction request from the payment terminal (102) through the intermediate sender unit (104) using the first communication session; generate the transaction response upon processing the transaction request; and transmit asynchronously, the transaction response for the transaction request through the intermediate receiver unit (108) using the second communication session.

22. The system (100) as claimed in claim 21, wherein the payment gateway (106) polls the intermediate sender unit (104) using a first intermediate communication session for the transaction request and the payment terminal (102) polls the intermediate receiver unit (108) using a second intermediate communication session for the transaction response at predefined time intervals.

23. The system (100) as claimed in claim 22, wherein the payment terminal (102) is further configured to terminate the second intermediate communication session with the intermediate receiver unit (108) upon each polling for the transaction response.

24. The system (100) as claimed in claim 22, wherein the payment gateway (106) is further configured to terminate the first intermediate communication session with the intermediate sender unit (104) upon each polling for the transaction request.

25. The system (100) as claimed in claim 21, wherein the payment terminal (102) is further configured to terminate the first communication session between the payment terminal (102) and the intermediate sender unit (104) upon asynchronously transmitting the transaction request.

26. The system (100) as claimed in claim 21, wherein the payment terminal (102) is further configured to switch to a listening mode to asynchronously receive the transaction response from the intermediate receiver unit (108) upon transmitting the transaction request.