The present disclosure generally relates to networked computing system and in particular related to electronic-transaction systems.
BACKGROUND TO THE INVENTION:
[0002] With the development of communication and technology, digital devices such as computers and smartphones are being widely used in various-fields. In particular, the computers, smartphones and the Internet are increasingly being used to conduct various transactions among the masses. Examples of such transactions includes buying and selling of goods and services either online or offline. Hence, various example transaction related applications such as financial-applications have been developed for point of sale terminals and smartphones to improve the convenience of the consumers as well as the merchants.
[0003] Considering the distributed computing systems operating in a networking environment, transaction between any two network nodes or terminals requires authorization or processing by a third node. In such a scenario, while one of the two network nodes would have successfully discharged its transaction as per a third node, non-performance of 'not so significant' procedural tasks by the other transacting network node due to network error or propagation delay appears to indicate an overall transaction-failure and cause or require the two nodes to transact once more, thereby leading to unnecessary overhead on the part of transacting parties. The previous transaction that failed at one of the nodes might also need to be reversed, resulting in additional overhead.
[0004] Typically, considering an example of an offline financial transaction, the consumer picks up one or more desired products and approaches the point of sale (POS) terminal to complete the transaction. The POS terminal generally comprises a computer that runs the POS software, a barcode scanner, a card reader for processing the payment made by debit or credit card and a receipt printer for printing a proof of payment and transaction. An operator of the POS terminal or a cashier generates an invoice of the one or more products and requests the consumer to make the payment. The consumer may make the payment using one of credit/debit card, payment wallet, internet banking, etc. In the card based payment, the card reader reads the information from the magnetic strip/chip on the card including card holder name, card number, transaction amount, expiry date etc. Further, the card reader

records the name of the merchant and the date and time of transaction. Such information is transferred to an acquirer bank's server which in turn transfers to a card issuing bank's server via the payment processing networks for authorization. Upon receiving the information, the card issuing bank's server validates the same and either accepts or rejects the authorization request. Further, the card issuing bank's server communicates the status of the payment to the acquirer bank's server and hence to the card reader. If the authorization request is approved, the card reader prints a receipt indicating successful payment.
[0005] In the aforesaid process, the card reader may fail to print the receipt even though the card issuing bank's server accepts the authorization request, the reason being, network errors, response time delay, etc. In such situations, a payment reversal is carried out by one of a several methods by the cardholder, merchant, acquiring or issuing bank, and hence the transaction will be incomplete even though the payment was successful.
[0006] On the other hand, the consumer may make the payment through one of the payment wallets or online banking services using his smartphone. In such a scenario, the payment confirmation is received on the smartphone and consumer has to show the same to the cashier to complete the transaction. However, the cashier cannot verify the payment and hence such method is unreliable.
[0007] Accordingly, there lies at least a need to evolve an advanced electronic transaction system to render accurate status information in real-time.
[0008] More specifically, there lies at least a need to evolve an advanced electronic transaction system to render the status information and prevent the transacting parties from conducting repeated transactions.
SUMMARY OF THE INVENTION:
[0009] This summary is provided to introduce a selection of concepts in a simple manner that are further described in the detailed description of the disclosure. This summary is not intended to identify key or essential inventive concepts of the subject matter nor is it intended for determining the scope of the disclosure.
[00010] In an embodiment, the present subject matter describes a method in at least
one networked computing device for determining status of a user-executed transaction. The

method comprises receiving a transaction-related information by a transceiver from at least one of a point of sale (POS) device or a mobile-device. A transaction server logs a transaction event based on the transaction-related information. Further, the transaction server interacts with an institutional server for recording a processing-status of the transaction event in real-time. Such status is at least one of completion, failure and pending status, etc with respect to the transaction event. A verification-token is communicated by the transceiver based on the transaction event to the mobile device associated with the transacting user. Further, a status of the transaction is determined by the transaction-server upon receiving the verification token from the mobile device via the POS device. Thereafter, the determined status is communicated to the POS device.
[00011] In an implementation, the present subject matter discloses a system and method for payment verification using one time verification token in an offline transaction. In some embodiments, the method comprises the steps of, (a) receiving, by a transaction server, payment information from one of a POS device associated with a merchant or from a user device associated with a transacting user/consumer, wherein the payment information comprises one or more of an amount, card information, and contact number, merchant information, transaction information, (b) generating and recording a payment transaction event, wherein the payment transaction event comprises payment information received and a verification token for the payment transaction, (c) processing the payment and recording status of processing in the payment transaction event, wherein the status may include one of payment complete status, payment failed status or payment pending status, (d) communicating the verification token to the user device associated with the transacting user, (e) receiving the verification token from POS terminal associated with the merchant, (f) determining the status of the payment associated with the verification token, and (f) communicating the status of the payment to the POS terminal associated with the merchant.
[00012] To further clarify advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying figures.

BRIEF DESCRIPTION OF THE FIGURES:
[00013] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
[00014] The disclosure will be described and explained with additional specificity and
detail with the accompanying figures in which:
[00015] Figure 1 illustrates method steps, in accordance with the embodiment of the
present subject matter;
[00016] Figure 2 illustrates a system, in accordance with the embodiment of the
present subject matter;
[00017] Figure 3 illustrates an example payment transaction server operating in a
networking environment in accordance with an embodiment of the present subject matter;
[00018] Figure 4 illustrates a block diagram of the example payment transaction server
of Fig. 3 in accordance with an embodiment of the present subject matter.
[00019] Figure 5 shows an example computing-device based implementation of the
system as depicted in Fig. 2, in accordance with the embodiment of the present subject matter
[00020] Further, persons skilled in the art to which this disclosure belongs will
appreciate that elements in the figures are illustrated for simplicity and may not have been necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
DESCRIPTION OF THE INVENTION:
[00021] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications to the disclosure, and such further applications of the principles of the disclosure as described

herein being contemplated as would normally occur to one skilled in the art to which the disclosure relates are deemed to be a part of this disclosure.
[00022] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.
[00023] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or a method. Similarly, one or more devices or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, other sub-systems, other elements, other structures, other components, additional devices, additional sub-systems, additional elements, additional structures, or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
[00024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.
[00025] Embodiments of the present disclosure will be described below in detail with reference to the accompanying figures.
[00026] The present disclosure relates to a system and method for payment verification using one time verification token (hereafter referred as v-token) in an offline transaction. Typically during an offline transaction, that is, during a transaction at a point of sale (POS) terminal, a consumer may opt for one of the payment modes such as credit/debit card, payment wallets, online banking services, etc. Considering the online payment, the consumer enters the amount to be paid and enters the password, if any on their mobile device. Upon entering the password, the payment information is communicated to a payment transaction server, wherein the payment information comprises one or more of an amount, card information, contact number, merchant information, billing information, etc. Upon receiving

the payment information, the payment transaction server generates a payment transaction event and records the same in a payment database. Further, the payment transaction server generates a v-token for the particular transaction and records the same in the payment transaction event. Further, the payment transaction server processes the payment and records the status of processing in the payment transaction event, wherein the status may include one of payment complete status, payment failure status or payment pending status. It has to be noted that the payment may be processed in any known way by interacting with an acquiring bank's server and a card issuing bank's server, and the status of the processing is recorded in the payment transaction event, hence in the payment database associated with the payment transaction server. Then the payment transaction server communicates verification token or v-token to a user device associated with the consumer. In some implementation, the v-token may be communicated before initiating or while initiating the payment process. The consumer may then share the v-token with the cashier for payment verification. The cashier may then enter the v-token in a dedicated portal in the POS terminal to communicate the v-token to the payment transaction server. Then the payment transaction server fetches the status of the processing associated with that particular v-token and communicates the payment status to the POS terminal. Hence, the cashier may verify the payment status before handing over the products to the consumer.
[00027] Fig. 1 illustrates a method implemented in at least one networked computing
device for determining status of a user-executed transaction. The method comprises receiving (step 102) a transaction-related information by a transceiver from at least one of a point of sale (POS) device or a mobile-device. The transaction-related information comprises one or more of an amount, payment instrument information, the user's contact-number, merchant-information. The mobile device comprises a mobile computing device associated with a user and configured to execute at least one of: a payment wallet application, a display for rendering QR code, a capability to transmit sound alerts, a capability to transmit data wirelessly over a protocol defined by one or more of Bluetooth / BLE / WiFi, NFC, Infra red etc.
[00028] Further, the method comprises logging (step 104), by a transaction server, a
transaction event based on the transaction-related information. The transaction-event corresponds to payment related event comprising the payment information as received.

[00029] Further, the method comprises recording (step 106) by the transaction server a
processing-status of the transaction event in real-time. For such purposes, the transaction server interacts with an institutional-server (e.g. a financial institution) to gather said status. The processing status is at- least one of completion, failure and pending status with respect to the transaction event. In an example, the processing status communicated from the institutional server is at least one of: payment complete status, payment-failed status or payment-pending status.
[00030] Further, the method comprises communicating (step 108) by the transceiver a
verification-token based on the transaction event to the mobile device associated with the transacting user. The verification-token is encoded as a machine readable code by the transaction server (also referred as a payment transaction server in subsequent figures) and communicated to the mobile device. In other implementation, the verification token as encoded may be a human readable code (e.g. numeric or alphanumeric). Unlike the machine readable, the human readable code may be communicated as a display message or audio message to the mobile device. Example of the machine readable code may be a barcode, QR code, steganographic code. Examples of human readable code may include numeric or alphanumeric code such as a one-time password (OTP).
[00031] Further, the method comprises the transaction server determining (step 109) a
status of the transaction upon receiving the verification token from the mobile device via the POS device. More specifically, the verification code in respect of the step 108 is received back by the transaction-server from the POS device. Based thereupon, the status as determined by the transaction server is communicated back to the POS device.
[00032] Fig. 2 illustrates a detailed internal-construction of a system 200 in accordance
with the embodiment of the present invention. The system 200 includes a receiving module 202 that performs the step 102, a processing module 204 that performs that step 104 and 106, a communication module 206 that performs the step 108, and a status determination module 208 that perform the step 109. Likewise, there may be a miscellaneous module 209 within the system 200 that facilitate operational-interconnection among the modules 202 till 208 and perform other ancillary-functions.
[00033] Figure 3 illustrates an exemplary system 300 for payment verification in
accordance with an embodiment of the present disclosure. As shown, the system 100

comprises a POS device/terminal 105, a user device associated with a user 115, a payment transaction server 120 corresponding to the system 200, one or more financial institution servers 125, and a communication network 130. In one implementation, the POS device 105 and the user device 110 are communicatively connected to the payment transaction server 120 via the communication network 130. Further, the payment transaction server 120 and the one or more financial institution servers 125 are communicatively connected via the communication network 130.
[00034] The POS device 105 may be a general purpose computer or a special purpose computer physically located at a check-out lane in a store/retail environment. That is, the POS device 105 may be a retail or wholesale computer, which may be embodied as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant or other computing devices. Hence, the POS device 105 may include one or more processors, associated processing modules, interfaces (for example, a scanner, keyboard, display monitor, network interface modules or the like), and storage devices communicatively interconnected to one another through one or more communication means or channels for processing sales data, for calculating the amount owed by a consumer and generating receipt for a transaction. Further, the POS device 105 may be coupled with one or more payment devices such as card readers for receiving payments from consumers. Typically, the POS device 105 may be any known POS device capable of conducting sales transactions and generating the receipts for the transactions, wherein the receipts comprises content relating to the transactions. In one embodiment of the present disclosure, the POS device 105 comprises a dedicated application using which the cashier/merchant may communicate with the payment transaction server 120 for verifying the payment. The manner in which the POS terminal functions in order to verify the payment transaction is discussed in detail further below in the description.
[00035] The user device 110 may be any mobile computing device that often accompanies their users to perform daily activities. By way of example, the user device 110 may include portable computing device such as a smartphone, tablet, a personal data assistant (PDA), and the like having communication capabilities. The user device 110 may communicate with the payment transaction server 120 through the communication network 130 in one or more example ways such as wired, wireless connections. The user device 110 may comprise one or more payment wallet applications (e.g. PhonePe™) that enables the users to execute the payments for the transactions.

[00036] The financial institution servers 125 as described herein refers to the bank's server which may include consumer's card issuing bank's server and acquirer bank's server, that is, bank server associated with the merchant, typically where the authentication and the payment transaction takes place.
[00037] The communication network 130 may be a wireless network or a wired network or a combination thereof. Wireless network may include long range wireless radio, wireless personal area network (WPAN), wireless local area network (WLAN), mobile data communications such as 3G, 4G or any other similar technologies. The communication network 130 may be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The communication network 130 may either be a dedicated network or a shared network. The shared network 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), and the like. Further the communication network 130 may include a variety of network devices, including routers, bridges, servers, modems, computing devices, storage devices, and the like. In one implementation, the communication network 130 is internet which enables communication between one or more elements of the system 100 as shown.
[00038] The payment transaction server 120 or the system 200 may include, for example, a computer server or a network of computers or a virtual server which provides functionalities or services for other programs or devices such as for the user device 110 and to merchant devices, that is the POS device 105. In one implementation, the payment transaction server 120 is a cloud server comprising one or more processors, associated processing modules, interfaces and storage devices communicatively interconnected to one another through one or more communication means for communicating information. The storage associated with the payment transaction server 120 may include volatile and non¬volatile memory devices for storing information and instructions to be executed by the one or more processors and for storing temporary variables or other intermediate information during processing. In one implementation, the payment transaction server 120 is configured to record the payment transaction information, wherein the payment transaction information may include but not limited to payment information received from the POS device 105 or the user device 110, payment transaction status and a v-token for the transaction.

[00039] The manner in which the system 100 operates to enable the merchant to verify the payment transaction is further disclosed in detail referring to Figure 4 below.
[00040] Figure 4 is a block diagram of an example payment transaction server 120 or the system 200 of Fig. 2, in accordance with an embodiment of the present disclosure. As shown, the payment transaction server 120 comprises a communication module 205 which represents a combination of the receiver module 202 and a communication module 206 referred in Fig. 2. A payment processor 210 corresponds to the processing module 204. A combination of a v-token generation module 215 and a status determination module 220 corresponds to the status determination module 208 of Fig. 2. A payment database 225 corresponds to miscellaneous or other module 209 of Fig. 2. As may be understood, the payment transaction server 120 may include one or more additional elements such as memory units, processors, etc., for functioning of the server as well known in the art and as later illustrated with respect to Fig. 5.
[00041] As described, during the transaction at the POS terminal, the consumer may opt for offline payment modes such as credit/debit card. In other implementation, the consumer may opt for online payment mode such as, payment wallets unified payment interface (UPI), online banking services, etc. If the consumer initiates the 'online payment' using the user device 110, the user device 110 communicates the payment information to the payment transaction server 120, wherein the payment information may include one or more of the amount, consumer-profile information (e.g. consumer designated QR code) merchant information, transaction information such as date and time, etc. In an example of the 'online payment', the consumer executes the payment using user device 110 by means of a payment wallet application or UPI. In the case of offline payment execution, which may be executed through swiping of electronic card (e.g. credit/debit/ATM card), the payment information as communicated to the payment transaction server 120 may include one or more of the amount, card details, card pin, merchant information, transaction information such as date and time, etc.
[00042] The communication module 205 receives the payment information 230 sent from one or the POS device 105 or the user device 110 and communicates the same to the payment processor 210 for processing. Such an operation corresponds to the step 102 of Fig. 1.

[00043] In one embodiment of the present disclosure, the payment processor 210 generates a payment transaction event in the payment database 225 and communicates the payment information to the financial institution server 125 for authentication and processing. As well known in the art, the consumer's card issuing server (for example a first financial institution server) authenticates the user, validates the payment information, either accepts or rejects the payment transaction and communicates the status to the acquirer bank's server (for example a second financial institution server). Such an operation corresponds to the step 104 of Fig. 1.
[00044] In one embodiment of the present disclosure, the payment processor 210 fetches the status of processing from one of the financial institution server 125, wherein the status may include one of the payment complete status, payment failed status, or payment pending status, and records the v-token in the payment transaction event in the payment database 225. Such an operation corresponds to the step 106 of Fig. 1.
[00045] In one embodiment of the present disclosure, the payment processor 210 triggers the v-token generation module 215 to generate a v-token for the payment transaction. In a preferred embodiment of the present disclosure, the payment processor 210 triggers the v-token generation module 215 while generating the payment transaction event. The generated v-token is recorded in the payment transaction event and the same is communicated to the user device 110 through the communication module 205 as shown. Such operation corresponds to the step 108 of Fig. 1.
[00046] In one embodiment of the present disclosure and as continuation to the step 108, the v-token may be communicated as a message or may be encoded as a machine readable code and communicated to the user device 110, which is typically displayed on the user device 110 through the application. In other example, the v-token may be the human readable code as discussed in preceding description.
[00047] Upon receiving the v-token 235 on the user device 110, the user 115 may share the same with the cashier/merchant holding the POS device 105, and the cashier may use the same for payment verification. If the v-token is received as the message (i.e. OTP message), then the user may show the same to the cashiers, else, if the v-token is received in the form of a machine readable code, then the cashier may use QR code scanner or a barcode scanner to scan/read the v-token. As described, in one embodiment of the present disclosure, the cashier

may input the v-token 235 to the payment transaction server 120 using a dedicated application installed in the POS device 105. Alternatively, in a preferred embodiment, the cashier may input the v-token 235 using a dedicated portal associated with the payment transaction server 120. If the v-token is scanned using one of the QR code or barcode reader, then the same is communicated to the payment transaction server 120.
[00048] The communication module 205 receives the v-token 235 from the POS device 105 and communicates the same to the status determination module 220. In one embodiment, the status determination module 220 fetches the payment status associated with the v-token 235 from the payment database 225, wherein the payment status may be one of the payment complete status, payment failure status or the payment pending status, and the same is communicated back to the POS device 105. Hence, the merchant may verify the payment status during the transaction to make sure that the payment is complete before handing over the products to the consumer. Such an operation corresponds to the step 109 of Fig. 1.
[00049] Figure 5 shows yet another exemplary implementation in accordance with the embodiment of the invention, and yet another typical hardware configuration of the system 200, 120 in the form of a computer-system 500. The computer system 500 can include a set of instructions that can be executed to cause the computer system 500 to perform any one or more of the methods disclosed. The computer system 500 may operate as a standalone-device or may be connected, e.g., using a network, to other computer systems or peripheral devices.
[00050] In a networked deployment, the computer system 500 may operate in the capacity of a server or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The computer system 500 can also be implemented as or incorporated across various devices, such as a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single computer system 500 is illustrated, the term "system" shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.

[00051] The computer system 500 may include a processor 502 e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor 502 may be a component in a variety of systems. For example, the processor 502 may be part of a standard personal computer or a workstation. The processor 502 may be one or more general processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analysing and processing data. The processor 502 may implement a software program, such as code generated manually (i.e., programmed).
[00052] The computer system 500 may include a memory 504, such as a memory 504 that can communicate via a bus 504. The memory 504 may include, but is not limited to computer readable storage media such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 504 includes a cache or random access memory for the processor 502. In alternative examples, the memory 504 is separate from the processor 502, such as a cache memory of a processor, the system memory, or other memory. The memory 504 may be an external storage device or database for storing data. The memory 504 is operable to store instructions executable by the processor 502. The functions, acts or tasks illustrated in the figures or described may be performed by the programmed processor 502 for executing the instructions stored in the memory 504. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firm-ware, micro-code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.
[00053] As shown, the computer system 500 may or may not further include a display unit 510, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display 510 may act as an interface for the user to see the functioning of the processor 502, or

specifically as an interface with the software stored in the memory 504 or in the drive unit 516.
[00054] Additionally, the computer system 500 may include an input device 512 configured to allow a user to interact with any of the components of system 500. The computer system 500 may also include a disk or optical drive unit 516. The disk drive unit 516 may include a computer-readable medium 522 in which one or more sets of instructions 524, e.g. software, can be embedded. Further, the instructions 524 may embody one or more of the methods or logic as described. In a particular example, the instructions 524 may reside completely, or at least partially, within the memory 504 or within the processor 502 during execution by the computer system 500.
[00055] The present invention contemplates a computer-readable medium that includes instructions 524 or receives and executes instructions 524 responsive to a propagated signal so that a device connected to a network 526 can communicate voice, video, audio, images or any other data over the network 526. Further, the instructions 524 may be transmitted or received over the network 526 via a communication port or interface 520 or using a bus 508. The communication port or interface 520 may be a part of the processor 502 or may be a separate component. The communication port 520 may be created in software or may be a physical connection in hardware. The communication port 520 may be configured to connect with a network 526, external media, the display 510, or any other components in system 500, or combinations thereof. The connection with the network 526 may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed later. Likewise, the additional connections with other components of the system 500 may be physical connections or may be established wirelessly. The network 526 may alternatively be directly connected to the bus 508.
[00056] The network 526 may include wired networks, wireless networks, Ethernet AVB networks, or combinations thereof. The wireless network may be a cellular telephone network, an 802.11, 802.16, 802.20, 802.1Q or WiMax network. Further, the network 526 may be a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols. The system is not limited to operation with any particular standards and protocols. For example,

standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) may be used.
[00057] The system disclosed in the present disclosure provides a hassle free payment verification process and eliminates undesired payment reversals that are occurring as a result of a failure to print the receipt, failure to receive acknowledgment from bank servers, etc. during the transaction. Further, the system and method disclosed in the present disclosure brings predictability/speed in the entire flow for payment closure to both the consumer as well as merchant/cashier.
[00058] Overall, the present subject matter provides an advanced electronic transaction system to render accurate status information in real-time. More specifically, the present electronic transaction system is able to prevent the transacting parties from undergoing repeated transactions by render the status information in real-time with efficiency.
[00059] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.
[00060] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.
[00061] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[00062] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.
[00063] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible.

WE CLAIM:

1.A method implemented in at least one networked computing device for determining status
of a user-executed transaction, said method comprising:
a) receiving (step 102) a transaction-related information by a transceiver from at least
one of a point of sale (POS) device or a mobile-device;
b) logging (step 104) by a transaction server a transaction event based on the transaction-related information;
c) recording (step 106), by the transaction server interacting with an institutional server, a processing-status of the transaction event in real-time, wherein the status is at least one of completion, failure and pending status with respect to the transaction event;
d) communicating (step 108) by the transceiver a verification-token based on the transaction event to the mobile device associated with the transacting user; and
e) determining (step 109) a status of the transaction by the transaction server upon receiving the verification token from the mobile device via the POS device and thereby communicating the status to the POS device.

2. The method as claimed in claim 1, wherein the transaction information comprises one or more of an amount, payment instrument information, the user's contact-number, merchant information..
3. The method as claimed in claim 1, wherein the mobile device comprises a mobile computing device associated with a user and configured to execute at least one of:
a payment wallet application;
a display for rendering QR code;
a capability to transmit sound;
a capability to transmit data wirelessly over a protocol defined by one or more of Bluetooth / BLE / WiFi
4. The method as claimed in claim 1, wherein the transaction-event corresponds to
payment related event comprising the payment information as received.

5. The method as claimed in claim 1, wherein the processing status communicated from the institutional server is at least one of: payment complete status, payment-failed status or payment-pending status.
6. The method as claimed in claim 1, wherein the verification-token is encoded as a machine readable code or a human readable code by the transaction server and communicated to the mobile device
7. The method as claimed in claim 6, wherein the verification code is received back by the transaction server from the POS device
8. The method as claimed in claims 1 and 5, wherein the status of the transaction is determined by the transaction server upon receiving back the verification code from the POS device.
9. A system (200) operating in a networking environment (300) for determining status of a user-executed transaction, said system comprising:
a receiving module (202) for receiving a transaction-related information from at least one of: a point of sale (POS) device or a mobile-device;
a processing module (204) for:
logging a transaction event based on the transaction-related information and thereby;
recording in real-time a processing-status of the transaction event, wherein the status is at least one of completion, failure or pending status with respect to the transaction event;
a communication-module (206) for communicating a verification-token based on the transaction event to the mobile device associated with the transacting user;
and
a status-determination module (208) for determining a status of the transaction upon receiving the verification token from the mobile device via the POS device and thereby communicating the status to the POS device.

10. The system (200) as claimed in claim 9, wherein the receiving module (202) receives the transaction information as one or more of an amount, payment instrument information, the user's contact-number, merchant information.
11. The system (200) as claimed in claim 9, wherein the processing module (204) logs the transaction-event as a payment related event comprising the payment information as received.
12. The system (200) as claimed in claim 9, wherein the processing module (204) captures the processing status as at least one of payment complete status, payment-failed status or payment-pending status.
13. The system (200) as claimed in claim 9, wherein the processing module (204) encodes the verification token as a machine readable code or a human readable code for communication to the mobile device.
14. The system (200) as claimed in claim 13, wherein the receiving module (202) receives back the verification code from the POS device
15. The system (200) as claimed in claim 14, wherein the status of the transaction is determined, by the determination module (208) interacting with the receiving module (202), upon receiving back the verification code from the POS device.