Abstract: METHODS AND SYSTEMS FOR PERFORMING A QUICK RESPONSE CODE BASED PAYMENT TRANSACTION Embodiments provide methods and systems for performing a QR code based payment transaction. The method includes receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by the user from a user-interface (UI) associated with the merchant. The method includes receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI. The QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period. Further, a match between the user provided QR code and the merchant provided QR code is determined. The payment transaction is processed upon successful match of the user provided QR code and the merchant provided QR code. FIG. 5
Claims:CLAIMS:
We claim:
1. A computer-implemented method for performing a Quick Response (QR) based payment transaction, the method comprising:
receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by a user from a user-interface (UI) associated with the merchant, the QR code generated based on a random number data;
receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI,
wherein the QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period;
determining, by the server system, a match between the user provided QR code and the merchant provided QR code; and
upon successful match of the user provided QR code and the merchant provided QR code, processing, by the server system, the payment transaction.
2. The method as claimed in claim 1, further comprising:
receiving, by the server system, a user data provided by the user upon registration of the user at a user application in the user device, the user data comprising a user identifier data, a username data and a payment account data of the user; and
storing, by the server system, the user data in a database.
3. The method as claimed in claim 2, further comprising:
receiving, by the server system, a merchant data provided by the merchant upon registration of the merchant at a merchant application in the merchant device, the merchant data comprising a merchant identifier data, merchant name data and a payment account data of the merchant; and
storing, by server system, the merchant data in the database.
4. The method as claimed in claim 3, further comprising:
facilitating, by the server system, a selection of a QR scan option at the user application; and
receiving, by the server system, the user provided QR code via the user application.
5. The method as claimed in claim 4, further comprising:
facilitating, by the server system, a selection of a QR scan option at the merchant application; and
receiving, by the server system, the merchant provided QR code via the user application.
6. The method as claimed in claim 5, wherein determining the match comprises:
decoding, by the server system, the user provided QR code;
decoding, by the server system, the merchant provided QR code; and
determining, by the server system, the match based on identifying a matching random number data between a decoded user provided QR code and a decoded merchant provided QR code.
7. The method as claimed in claim 6, further comprising:
accessing, by the server system, the merchant data from the database upon identifying the merchant based on the matching random number data; and
accessing, by the server system, the user data from the database.
8. The method as claimed in claim 7, further comprising:
sending, by the server system, a payment transaction request for the payment amount to an issuer of the user using the user data and the merchant data;
sending, by the server system, the payment amount to an acquirer of the merchant using the merchant data upon receipt of the payment amount from the issuer; and
notifying, by the server system, a payment settlement between the issuer and the acquirer to the user and the merchant.
9. The method as claimed in claim 1, wherein the UI is a transparent display screen for displaying the QR code with a timer data corresponding to the valid pre-defined threshold time-period, the transparent display screen enables scanning of the QR code from one side of the UI by the user and scanning of the QR code from other side of the UI by the merchant.
10. The method as claimed in claim 9, further comprising:
updating the QR code based on resetting the random number data;
resetting the timer data for an updated QR code; and
displaying the updated QR code with a reset timer data on the UI.
11. The method as claimed in claim 10, wherein resetting the random number data is reset based on one of:
an expiration of the valid pre-defined threshold time-period;
a trigger provided by the merchant for updating the QR code; and
a completion of a successful payment transaction.
12. A server system for performing a Quick Response (QR) based payment transaction, the server system comprising:
a memory comprising stored instructions; and
a processor configured to execute the stored instructions to cause the server system to perform at least in part to:
receive a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by a user from a user-interface (UI) associated with the merchant, the QR code generated based on a random number data;
receive a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning a QR code by the merchant from the UI, wherein the QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period;
determine a match between the user provided QR code and the merchant provided QR code; and
upon successful match of the user provided QR code and the merchant provided QR code, process the payment transaction.
13. The server system as claimed in claim 12, wherein the server system is further caused to perform at least in part to:
receive a user data provided by the user upon registration of the user at a user application in the user device, the user data comprising a user identifier data, a username data and a payment account data of the user; and
store the user data in a database.
14. The server system as claimed in claim 13, wherein the server system is caused to perform at least in part to:
receive a merchant data provided by the merchant upon registration of the merchant at a merchant application in the merchant device, the merchant data comprising a merchant identifier data, a merchant name data and a payment account data of the merchant; and
store the merchant data in the database.
15. The server system as claimed in claim 14, wherein the server system is caused to perform at least in part to:
facilitate a selection of a QR scan option at the user application; and
receive the user provided QR code via the user application.
16. The server system as claimed in claim 15, wherein the server system is further caused to perform at least in part to:
facilitate a selection of a QR scan option at the merchant application; and
receive the merchant provided QR code via the merchant application.
17. The server system as claimed in claim 12, wherein for determining the match, the server system is further caused to perform at least in part to:
decode the user provided QR code;
decode the merchant provided QR code; and
determine the match based on identifying a matching random number data between a decoded user provided QR code and a decoded merchant provided QR code.
18. The server system as claimed in claim 17, wherein the server system is further caused to perform at least in part to:
access a merchant data from a database upon identifying the merchant based on the matching random number data;
access a user data from the database;
send a payment transaction request for the payment amount to an issuer of the user using the user data and the merchant data;
send the payment amount to an acquirer of the merchant using the merchant data upon receipt of the payment amount from the issuer; and
notify a payment settlement between the issuer and the acquirer to the user and the merchant.
19. The server system as claimed in claim 12, wherein the server system is further caused to perform at least in part to:
update the QR code based on resetting the random number data, resetting the random number data based on one of an expiration of the valid pre-defined threshold time-period, a trigger provided by the merchant for updating the QR code and a completion of a successful payment transaction;
reset a timer data for an updated QR code; and
display the updated the QR code with a reset timer data on the UI.
20. A computer-implemented method for performing a Quick Response (QR) based payment transaction, the method comprising:
receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by a user from a user-interface (UI) associated with the merchant, the QR code generated based on a random number data;
receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI,
wherein the QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period;
decoding, by the server system, the user provided QR code and the merchant provided QR code;
determining, by the server system, a match based on identifying a matching random number data between a decoded user provided QR code and a decoded merchant provided QR code; and
processing, by the server system, the payment transaction based on determining the matching random number data. , Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)
1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PERFORMING A QUICK RESPONSE CODE BASED PAYMENT TRANSACTION
2. APPLICANT(S):
(a) Name:
(b) Nationality:
(c) Address:
MASTERCARD INTERNATIONAL INCORPORATED
United States of America
2000 Purchase Street, Purchase, NY 10577, United States of America
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.
4. DESCRIPTION
(See next page)
METHODS AND SYSTEMS FOR PERFORMING A QUICK RESPONSE CODE BASED PAYMENT TRANSACTION
TECHNICAL FIELD
[0001] The present disclosure generally relates to a payment technology and, more particularly to, methods and systems for performing a payment transaction using a dynamic QR code.
BACKGROUND
[0002] With the rise of smart devices, such as smart phones, use of Quick Response (QR) codes in payment transactions has grown rapidly over the past few years. A QR code is a matrix (two-dimensional) bar code with a random pattern of black dotted squares in a white grid. In QR based payments, a QR code is read using an imaging module (e.g., a camera) of the smart devices. The QR code stores a large amount of information corresponding to a payment transaction. For instance, a merchant may provide the QR code to a customer. The merchant may display the QR code in a printed form on a board or a paper or may display on a merchant device. The QR code may embed information, such as details of the merchant and other information related to the payment transaction. The customer scans the QR code using smartphone and proceeds with the payment transaction.
[0003] However, such payment transactions may entail various security risks. For instance, a fraudster may replace a legitimate QR code of the merchant with a malicious QR code to the merchant as well as the customer. The malicious QR code embeds a program virus to trigger malicious action, such as stealing confidential information of the merchant or the customer. The fraudster may replicate the QR code without modifying the original QR code. This increases difficulty in verifying authenticity of the QR code by a human eye. Consequently, the fraudster cheats the merchant into transferring their money into a bank account of the fraudster.
[0004] In view of the above-mentioned problems, there exists a need to devise techniques for providing QR based payment transaction in a safe and secure manner. More specifically, there is need to generate a QR code for the payment transaction, while mitigating chances of frauds and preventing malicious activities.
SUMMARY
[0005] Various embodiments of the present disclosure provide systems and methods for performing a quick payment transaction using QR codes in a safe and secure manner.
[0006] In an embodiment, computer-implemented method for performing a payment transaction is disclosed. The method includes receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by the user from a user-interface (UI) associated with the merchant. The QR code is generated based on a random number data. The method includes receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI. The QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period. The method includes determining, by the server system, a match between the user provided QR code and the merchant provided QR code. The method further includes upon successful match of the user provided QR code and the merchant provided QR code, processing, by the server system, of the payment transaction.
[0007] In another embodiment, a server system for performing a payment transaction is disclosed. The server system includes a memory including stored instructions and a processor configured to execute the stored instructions. The processor is configured to cause the server system to perform at least in part to receive a user provided QR code from a user device for making a payment transaction to a merchant upon scanning the QR code by the user from a user-interface (UI) associated with the merchant. The QR code is generated based on a random number data. The server system is caused to receive a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI. The QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period. The server system is caused to determine a match between the user provided QR code and the merchant provided QR code. The server system is further caused to process the payment transaction upon successful match of the user provided QR code and the merchant provided QR code.
[0008] In yet another embodiment, a computer-implemented method for performing a payment transaction is disclosed. The method includes receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by the user from a user-interface (UI) associated with the merchant. The QR code is generated based on a random number data. The method includes receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI. The QR code is scanned by the user and the merchant within a valid pre-defined threshold time-period. The method includes decoding, by the server system, the user provided QR code and the merchant provided QR code. The method includes determining, by the server system, a matching random number data between the decoded user provided QR code and the decoded merchant provided QR code. The method further includes processing, by the server system, the payment transaction upon determining the matching random number data.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.
BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates an example representation of an environment related to at least some example embodiments of the present disclosure;
[0012] FIG. 2 represents a user interface (UI) displaying a QR code and a timer, in accordance with an example embodiment of the present disclosure;
[0013] FIG. 3 represents a sequence flow diagram for performing a payment transaction using the QR code of FIG. 2, in accordance with another example embodiment of the present disclosure;
[0014] FIG. 4 represents a sequence flow diagram depicting a processing of the payment transaction using the QR code, in accordance with an example embodiment of the present disclosure;
[0015] FIG. 5 shows a flow diagram depicting a method for performing a payment transaction using a QR code, in accordance with another example embodiment of the present disclosure;
[0016] FIG. 6 shows a method flow diagram for performing the payment transaction using the QR code, in accordance with another example embodiment of the present disclosure;
[0017] FIG. 7 is a simplified block diagram of a server system for performing a payment transaction using a QR code, in accordance with an embodiment of the present disclosure;
[0018] FIG. 8 is a simplified block diagram of a payment server for performing the payment transaction, in accordance with an embodiment of the present disclosure;
[0019] FIG. 9 is simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure;
[0020] FIG. 10 is a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0021] FIG. 11 shows a simplified block diagram of a merchant device for example, the merchant device capable of implementing various embodiments of the present disclosure; and
[0022] FIG. 12 shows a simplified block diagram of a user device, for example, a mobile phone capable of implementing the various embodiments.
[0023] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.
DETAILED DESCRIPTION
[0024] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0025] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0026] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0027] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by PayPal®, and the like.
[0028] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0029] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by Mastercard®, VISA®, Discover®, American Express®, etc.
OVERVIEW
[0030] Various example embodiments of the present disclosure provide systems and methods for performing QR based payment transactions that overcome above-mentioned obstacles and provide additional advantages. More specifically, techniques disclosed herein enable performing a QR based payment transaction, without sharing any confidential information of a merchant over the QR code.
[0031] In an embodiment, a dynamic QR code is generated based on a random number that is valid for a pre-defined threshold time-period, such as 30 seconds. The QR code may be generated by a QR code generating module. The QR generator may be embodied in a merchant device or associated with the merchant device. After the generation, the QR code is displayed along with a timer (e.g., 00:30) on a user interface (UI) screen, which is a transparent display screen installed at a merchant’s facility. The timer corresponds to the valid pre-defined threshold time-period. The UI may be connected to the merchant through a wired connection or a wireless connection.
[0032] When a user completes a purchase from the merchant, the user and the merchant scan the QR code from the UI within the valid threshold time-period. The user scans the QR code using a user device that includes a user application for the QR based payment transaction. The merchant also scans the QR code using a merchant device that includes a merchant application for the QR based payment transaction.
[0033] Initially, the user and the merchant are registered at their respective applications in their devices. At the time of registration, the user provides a user data in the user application. The user data includes, but is not limited to, a user identifier, a username, a payment account of the user. Similarly, the merchant provides a merchant data at the merchant application based on the registration. The merchant data includes, but is not limited to, a merchant identifier, a merchant name, a payment account of the merchant.
[0034] At the time of payment, the user and the merchant select a QR scan option at the user application and the merchant application, respectively. After the selection, the QR code is scanned by the user and the merchant using their respective devices. The scanned QR code of the user is provided to a server, such as a payment server via the user application to make a payment transaction to the merchant. The payment server may receive the scanned QR code of the user and the user identifier from the user application. The scanned QR code of the merchant is provided along with a payment amount to the payment server via the merchant application. The merchant application provides the scanned QR code of the merchant and the payment amount along with the merchant identifier to the payment server. After receiving the scanned QR codes, the payment server determines a match between the scanned QR codes of the user and the merchant. After determining the match, the payment server initiates processing of the payment transaction. In an example embodiment, a decoding is performed to determine a match between the user provided scanned QR code and the merchant provided scanned QR code. For example, if payment server receives scanned quick response code1 (QR1),QR2,QR3,QR4, the payment server determines the corresponding random number data such as Rn1, Rn2, Rn1, Rn3 respectively, by decoding the QR1,QR2,QR3 and QR4. In this example, based on the decoding operation, the QR1 and QR3 are matching corresponding to their respective random number data (i.e., QR1 corresponds to Rn1 and QR3 corresponds to Rn1). The payment server accesses the user data and the merchant data (provided at the time of registration) for sending a payment transaction request to an issuer of the user. After receiving the payment amount from the issuer, the payment server then provides the payment amount to an acquirer of the merchant using the merchant data.
[0035] In at least one embodiment, the QR code displayed on the UI is updated based on resetting the random number data. The random number data may be reset based on an expiration of the valid pre-defined threshold time-period, a trigger provided by the merchant for updating the QR code, or a completion of a successful payment transaction. In an example embodiment, a trigger button may be connected to the UI via a wired /wireless connection and/or the like.
[0036] Thus, the dynamic QR code based payment transaction is performed, without sharing any confidential information of the merchant over a QR code. The process of performing the dynamic QR based payment transaction, is further explained in detail with reference to FIGS. 1 to 12.
[0037] FIG. 1 illustrates an example representation of an environment 100 related to at least some example embodiments of the present disclosure. In an illustrative example scenario, a user 102 visits a merchant facility 122 for purchasing items. The merchant facility 122 is equipped with an electronic payment infrastructure that supports QR code based payment for performing financial transactions. An example of the merchant facility 122 may be a restaurant, a hotel, a café, a bookstore, a supermarket, or any service provider of a public/private organization. At the merchant facility 122, a QR code 108 is displayed on a user-interface (UI), such as UI 106. The QR code 108 is displayed for payment transactions of the purchased items by users, such as the user 102. In an example embodiment, the QR code 108 is generated based on a random number. The UI 106 is a transparent screen that enables scanning of the QR code 108 from one side by the user 102 and from the other side by a merchant 110. The QR code 108 is associated with a valid pre-defined threshold time-period, for example, 30 seconds within which both the user 102 and the merchant 110 should scan the QR code 108.
[0038] The user 102 scans the QR code 108 using a user device 104. The user device 104 includes, but is not limited to, a smartphone, a tablet, a laptop, a computer system or any computing device equipped with an image capturing module. In an example embodiment, the user device 104 is equipped with an instance of an application, such as a user application 125. For instance, the user application 125 and its components may be hosted by a payment server 116. The user device 104 can communicate with the payment server 116 via the user application 125 installed in the user device 104 using a network 114. The network 114 may include wired networks, wireless networks and combinations thereof. Some non-limiting examples of the wired networks may include Ethernet, local area networks (LANs), fiber-optic networks, and the like. Some non-limiting examples of the wireless networks may include cellular networks like GSM/3G/4G/5G/LTE/CDMA networks, wireless LANs, Bluetooth, Wi-Fi or Zigbee networks, and the like. An example of the combination of wired and wireless networks may include the Internet.
[0039] The user application 125 is a set of computer executable codes configured to register the user 102 for a QR based payment transaction. At the time of registration, the user 102 provides user data in the user application 125. The user data includes, but is not limited to, a user identifier, a username, a payment account of the user 102, or the like. After the registration, the user data is provided to the payment server 116 via the user application 125. The user data may be stored in a database, such as a database 124. In one example embodiment, the database 124 may be integrated within the payment server 116. In another example embodiment, the database 124 may be associated with the payment server 116.
[0040] Moreover, the user application 125 facilitates a QR scan option that enables the user device 104 to capture and read the QR code 108 displayed on the UI 106. The set of computer executable codes may be stored in a non-transitory computer-readable medium of the user device 104. In some embodiments, the user application 125 is a payment application for facilitating payment transactions from a payer (e.g., the user 102) to the payee (e.g., the merchant 110). The user application 125 may be a mobile application or a web application. The term ‘user application 125’ is interchangeably referred to as ‘application 125’ throughout the disclosure.
[0041] After completing a purchase, the user 102 approaches the merchant 110. The merchant 110 prepares a bill for purchased items of the user 102. The user 102 opens the user application 125 for making a payment transaction of the purchase items. The user 102 selects a QR scan option in the user application 125. After the selection of the QR scan option, the user 102 scans the QR code 108 from the UI 106. The user device 104 provides the scanned QR code 108 of the user 102 to the payment server 116 via the user application 125 using the network 114. The scanned QR code 108 of the user 102 is referred to hereinafter as user provided QR code. In an example embodiment, the application 125 provides the user provided QR code to the payment server 116 along with the user identifier that was provided or set up while the registration.
[0042] In a similar manner, the merchant 110 also scans the QR code 108 using a merchant device 112. The merchant device 112 may include a smartphone, a tablet, a laptop, a computer system or any computing device equipped with an image capturing module. The merchant device 112 is also equipped with a merchant application 130 for the QR based payment transaction. The merchant application 130 and its components may be hosted by the payment server 116. The merchant device 112 communicates with the payment server 116 via the merchant application 130 installed in the merchant device 112 using the network 114. The term ‘merchant application 130’ is interchangeably referred to as ‘application 130’.
[0043] Initially, the merchant 110 is registered at the merchant application 130. When the merchant 110 is registered, the merchant 110 provides a merchant data in the merchant application 130. The merchant data includes, but is not limited to, a merchant identifier, a merchant name, a payment account of the merchant, or the like. The application 130 provides the merchant data to the payment server 116. The merchant data is stored in the database 124.
[0044] After generating the purchase bill for the user 102, the merchant 110 accesses the merchant application 130 and selects a QR scan option in the merchant application 130. The merchant 110 then scans the QR code 108 from the UI 106. After scanning the QR code 108, the merchant 110 enters a payment amount for the payment transaction in the merchant application 130. For instance, if the purchase bill is for Rs 500, then the merchant 110 enters the payment amount as Rs 500 in the merchant application 130. The scanned QR code 108 of the merchant 110 is provided to the payment server 116 via the merchant application 130 using the network 114. The scanned QR code 108 of the merchant 110 and the payment amount are sent to the payment server 116 via the application 130. The scanned QR code 108 of the merchant 110 is referred to hereinafter as "merchant provided QR code". The application 130 sends the merchant provided QR code and the payment amount along with the merchant identifier of the merchant 110 to the payment server 116.
[0045] Further, the payment server 116 determines a match between the user provided QR code and the merchant provided QR code. After determining a successful match, the payment server 116 initiates processing of the payment transaction. The payment server 116 accesses the user data and the merchant data for processing the payment transaction. The payment server 116 sends a payment transaction request for the payment amount (i.e., Rs 500) to an issuer server 118 using the user data. The issuer server 118 is associated with a financial institution normally known as an “issuer bank” or “issuing bank” or simply “issuer”, in which the user 102 may have an account, which issues one or more payment cards, such as a credit card or a debit card.
[0046] The issuer server 118 validates the payment transaction request. After successful validation, the issuer server 118 approves the payment transaction. The payment amount is deducted from the payment account of the user 102. The issuer server 118 sends the payment amount to the payment server 116. The payment server 116 further sends the payment amount to an acquirer server 120 using the merchant data. The acquirer server 120 is associated with a financial institution normally known as “acquirer bank” or “acquiring bank” or simply “acquirer”, in which the merchant 110 may have an account, which issues one or more payment cards, such as a credit card or a debit card.
[0047] In some cases, it may happen that the user 102 may desire to cancel the payment transaction. For instance, the user 102 has scanned the QR code 108 and provided the scanned QR code 108 to the payment server 116. The user 102 informs the merchant 110 to cancel the payment transaction. In such scenario, both the user 102 and the merchant 110 send a cancellation request to the payment server 116 via the application 125 and the application 130, respectively.
[0048] Thus, a QR code based payment transaction may be executed, without having the need to share any personal information of merchants, such as the merchant 110 in the QR code 108. The QR code 108 embeds the random number that is reset based on conditions that are described further with reference to FIG. 2.
[0049] Referring now to FIG. 2, a user interface (UI) 200 displaying a QR code 202 and a timer 204 is shown, in accordance with an example embodiment of the present disclosure. The UI 200 is an example of the UI 106 shown in FIG. 1. The UI 200 is a transparent display screen that enables scanning of the QR code 202 by the user 102 from one side and scanning of the QR code 202 by the merchant 110 from the other side. The QR code 202 is an example of the QR code 108 of FIG. 1. The user 102 and the merchant 110 scan the QR code 202 within a valid pre-defined threshold time period, such as 30 seconds. The timer 204 corresponds to the valid pre-defined threshold time period. For instance, the timer 204 is displayed as “00:30” in FIG. 2. The user 102 and the merchant 110 are required to scan the QR code 202 within 30 seconds. As mentioned earlier in FIG. 1, the QR code 202 is generated based on the random number. In an example embodiment, the random number may include a 20-digit number, for example, ‘33445676778898889988’ that may be generated by the merchant device 112. For instance, in this example, the random number may be generated in 1020 combinations. The merchant device 112 and the UI 200 may be connected with each other via a wired connection (not shown in FIG. 2) or a wireless connection. The wireless connection may be based on a short-range communication technique, such as Bluetooth, Near-Field Communication (NFC) or Infrared connection. The QR code 202 is updated based on resetting the random number. For instance, the merchant device 112 resets the random number as ‘44337656887788988899’. In an example embodiment, the random number is reset based on one of an expiration of the valid pre-defined threshold time-period, a trigger provided by the merchant 110 for updating the QR code, or a completion of a successful payment transaction.
[0050] When the timer 204 expires, the random number embedded in the QR code 202 is reset. In an example embodiment, a sensor in the merchant device 112 may sense the expiration of the timer 204 and triggers the merchant device 112 to update the random number and thereby generates an updated QR code. In some cases, the merchant 110 may provide a trigger input for updating the QR code 202. For instance, the merchant 110 provides the trigger input via a button, such as a trigger button 206 to update the QR code 202. In one illustrative example scenario, the merchant 110 and the user 102 complete a payment transaction using the QR code 202. The merchant 110 pushes the trigger button 206 to display an updated QR code for a new user. The trigger button 206 may be connected to the UI 200 via a wired connection, as shown in FIG. 2, or via a wireless connection, such as Bluetooth, Near-Field Communication (NFC) or Infrared connection. In some other cases, the merchant 110 clicks on the trigger button 206 upon receiving a notification on completion of a successful payment transaction.
[0051] The timer 204 is also reset for the updated QR code. For instance, if the QR code 202 is updated at a timer 00:25 before completion of the threshold time period, then the timer 204 is reset as “00:30”. It shall be noted that the timer 204 is described with respect to a count-down timer as an illustrative example only, and any other variation of timer may be used without limiting the scope of the present disclosure.
[0052] As explained with reference to FIG. 1, the user 102 and the merchant 110 scan the QR code 202 for a payment transaction. The scanned QR code of each of the user 102 and the merchant 110 is sent to the payment server 116 via the user application 125 and the merchant application 130, respectively for performing the payment transaction, which is described next with reference to FIG. 3.
[0053] Referring now to FIG. 3, a sequence flow diagram 300 for performing the payment transaction using the QR code, such as the QR code 202 of FIG. 2 is illustrated, in accordance with an example embodiment of the present disclosure. In an illustrative example scenario, the user 102 purchases items for a payment amount of Rs 500 from the merchant 110. The user 102 and the merchant 110 perform the payment transaction using the QR code 108.
[0054] At 302, the user 102 accesses the user application 125 in the user device 104. At 304, the user 102 selects a QR scan option in the user application 125. At 306, the user 102 scans the QR code 108 after selecting the QR scan option. The QR code 108 is captured within a valid pre-defined threshold time-period of the QR code 108. In an illustrative example scenario, an image capturing module, i.e., a camera of the user device 104 is triggered after the selection of the QR scan option. The user 102 scans the QR code 108 using the camera. At 308, the scanned QR code 108 is provided as a user provided QR code to the payment server 116 via the user application 125. The user application 125 sends the user provided QR code along with a user identifier that was provided by the user 102 in the registration.
[0055] At 310, the merchant 110 accesses the merchant application 130 in the merchant device 112. At 312, the merchant 110 selects a QR scan option in the merchant application 130. At 314, the merchant 110 scans the QR code 108 after selecting the QR scan option. For instance, a camera of the merchant device 130 is triggered after the selection of the QR scan option. The merchant 110 scans the QR code 108 using the camera. At 316, the scanned QR code 108 is provided as a merchant provided QR code to the payment server 116 via the merchant application 130. The application 130 sends the merchant provided QR code using a merchant identifier that was provided by the merchant 110 at the time of registration.
[0056] At 318, the payment server 116 determines a match between the user provided scanned QR code and the merchant provided scanned QR code. The determination of the match is described in detail with reference to FIG. 4.
[0057] At 320, the payment server 116 processes the payment transaction based on determining a successful match of the user provided QR code and the merchant provided QR code. The processing of the payment transaction is further described in detail with reference to FIG. 4.
[0058] Referring now to FIG. 4, a sequence flow diagram 400 depicting the processing of the payment transaction is illustrated, in accordance with an example embodiment of the present disclosure. The payment server 116 accesses QR codes, such as the user provided QR code and the merchant provided QR code for determining and matching QR codes.
[0059] At 402, the payment server 116 decodes the user provided QR code. When the user provided QR code is decoded, a random number (such as, ‘33445676778898889988’) is extracted from the user provided QR code. At 404, the payment server 116 decodes the merchant provided QR code. The payment server 116 extracts a random number (such as, ‘33445676778898889988’) from the merchant provided QR code.
[0060] At 406, the payment server 116 determines a match based on identifying a matching random number (i.e., ‘33445676778898889988’) between the decoded QR code of the user 102 and the decoded QR code of the merchant 110.
[0061] At 408, the payment server 116 accesses the merchant data from the database 124. The merchant data includes a merchant identifier, a merchant name, a payment account of the merchant 110, or the like.
[0062] At 410, the payment server 116 accesses the user data from a database, such as the database 124 of FIG. 1. The user data includes a user identifier, a username, a payment account of the user 102, or the like.
[0063] At 412, the payment server 116 sends a payment transaction request to the issuer server 118 using the user data and merchant data. In an illustrative example scenario, the payment server 116 identifies the issuer server 118 based on the user data and provides information related to the merchant 110 to the issuer server 118 based on the merchant data.
[0064] At 414, the issuer server 118 validates the payment transaction request. The issuer server 118 deducts a payment amount (such as Rs 500) for the payment transaction from the payment account of the user 102. At 416, the issuer server 118 sends the payment amount to the payment server 116. At 418, the payment server 116 sends the payment amount to the acquirer server 120 using the merchant data.
[0065] FIG. 5 shows a flow diagram depicting a method 500 for performing a payment transaction using a QR code, in accordance with another example embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by, for example, the payment server 116 of FIG. 1. Operations of the method 500, and combinations of operation in the method 500, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 500 starts at operation 502.
[0066] At operation 502, the method 500 includes receiving, by a server system associated with a payment network, a user provided QR code from a user device (e.g., the user device 104) for making a payment transaction to a merchant (e.g., the merchant 110) upon scanning a QR code by the user from a user-interface (UI) (e.g., the 106) associated with the merchant. The QR code is generated based on a random number data. The UI is a transparent display screen for displaying the QR code with a timer data (refer FIG. 2). The timer data corresponds to a valid pre-defined threshold time-period. Moreover, the UI enables scanning of the QR code from one side of the UI by the user and scanning of the QR code from other side of the UI by the merchant. In an example embodiment, the user provides a user data upon registration of the user at a user application (e.g., the user application 125 of FIG. 1) in the user device. The user data includes a user identifier data, a username data and a payment account data of the user. The user data is stored in a database, such as the database 124 shown and described in FIG. 1. The user selects a QR scan option in the user application. The user then scans the QR code and sends the user provided QR code via the user application.
[0067] At operation 504, the method 500 includes receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device (e.g., the merchant device 112) for the payment transaction upon scanning the QR code by the merchant from the UI. The QR code is scanned by the user and the merchant within the valid pre-defined threshold time-period. In an example embodiment, the merchant provides a merchant data upon registration of the merchant at a merchant application, such as the merchant application 130 of FIG. 1. The merchant data includes a merchant identifier data, a merchant name data and a payment account data of the merchant. The merchant data is stored in the database (e.g., the database 124). The merchant selects a QR scan option in the merchant application. The merchant scans the QR code and sends the merchant provided QR code via the merchant application (refer FIG. 3). Further, the QR code is updated based on resetting the random number data. In an example embodiment, the random number data is reset based on one of an expiration of the valid pre-defined threshold time-period, a trigger provided by the merchant for updating the QR code and a completion of a successful payment transaction. After updating the QR code, the timer data is reset for the updated QR code. The updated QR code and the reset timer data are displayed on the UI (refer FIG. 2).
[0068] At operation 506, the method 500 includes determining, by the server system, a match between the user provided QR code and the merchant provided QR code. In an embodiment, the match is determined based on identifying a matching random number data between the decoded user provided QR code and the decoded merchant provided QR code (refer FIG. 4).
[0069] At operation 508, the method 500 includes, upon successful match of the user provided QR code and the merchant provided QR code, processing, by the server system, of the payment transaction. In an example embodiment, the merchant data and the user data are accessed from the database for sending a payment transaction request to an issuer of the user. The payment amount is sent to an acquirer of the merchant using the merchant data upon receipt of the payment amount from the issuer. A payment settlement between the issuer and the acquirer is notified to the user and the merchant.
[0070] The sequence of operations of the method 500 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[0071] FIG. 6 shows a flow diagram of a method 600 for performing the payment transaction using the QR code, in accordance with another example embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the payment server 116 of FIG. 1. Operations of the method 600, and combinations of operation in the flow diagram, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 600 starts at operation 602.
[0072] At operation 602, the method 600 includes receiving, by a server system associated with a payment network, a user provided QR code from a user device for making a payment transaction to a merchant upon scanning a QR code by the user from a user-interface (UI) associated with the merchant, the QR code generated based on a random number data.
[0073] At operation 604, the method 600 includes receiving, by the server system, a merchant provided QR code and a payment amount from a merchant device for the payment transaction upon scanning the QR code by the merchant from the UI, wherein the QR code is being scanned by the user and the merchant within a valid pre-defined threshold time-period.
[0074] At operation 606, the method 600 includes decoding, by the server system, the user provided QR code and the merchant provided QR code. When the user provided QR code and the merchant provided QR code are decoded, a random number data is extracted from each QR code (refer FIG. 4).
[0075] At operation 608, the method 600 includes determining, by the server system, a match based on identifying a matching random number between the decoded user provided QR code and the decoded merchant provided QR code.
[0076] At operation 610, the method 600 includes processing, by the server system, the payment transaction based on determining the matching random number.
[0077] The sequence of operations of the method 600 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[0078] FIG. 7 is a simplified block diagram of a server system 700 for performing a payment transaction using a QR code, in accordance with an embodiment of the present disclosure. The server system 700 includes a computer system 702 and a database 704. In an embodiment, the server system 700 is integrated in the payment server 116. The computer system 702 includes at least one processor 706 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 708. The components of the computer system 702 provided herein may not be exhaustive and that the computer system 702 may include more or fewer components than those depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 702 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0079] The processor 706 is operatively coupled to a communication interface 710 such that the server system 700 is capable of communicating with a remote device 712, such as a user device 104, the merchant device 112, the issuer server 118, the acquirer server 120 (shown in FIG. 1) or communicating with any entity connected to the network 114. In an embodiment, the communication interface 710 is configured to receive a user provided QR code from the remote device 712, i.e., the user device 104 for making a payment transaction to a merchant, such as the merchant 110. The user provided QR code is received via a user application, such as the user application 125 of FIG. 1 in the user device 104. The communication interface 710 is also configured to receive a merchant provided QR code and a payment amount for the payment transaction from the remote device 712, i.e., the merchant device 112. The merchant provided QR code is received via a merchant application, such as the merchant application 130 of FIG. 1 in the merchant device 112. In an example embodiment, the server system 700 hosts and manages the user application 125 and the merchant application 130 that are stored in the database 704.
[0080] The communication interface 710 provides the user provided QR code and the merchant provided QR code to the processor 706. The processor 706 determines a match between the user provided QR code and the merchant provided QR code. Further, the processor 706 is configured to process the payment transaction upon determining a successful match between the user provided QR code and the merchant provided QR code.
[0081] The processor 706 is also operatively coupled to the database 704. The database 704 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, the user data and the merchant data. The database 704 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 704 may include a storage area network (SAN) and/or a network attached storage (NAS) system. In some embodiments, the database 704 is integrated within server system 700. For example, the server system 700 may include one or more hard disk drives as the database 704. In other embodiments, the database 704 is external to the server system 700 and may be accessed by the server system 700 using a storage interface 714. The storage interface 714 is any component capable of providing the processor 706 with access to the database 704. The storage interface 714 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing processor 706 with access to the database 704.
[0082] In an embodiment, the processor 706 accesses the user data and the merchant data from the database 704. After accessing the user data and the merchant data, the processor 706 sends a payment transaction request to an issuer of the user 102, such as the issuer server 118 via the communication interface 710. The communication interface 710 receives the payment amount from the issuer server 118 upon validating the payment transaction request. The payment amount is further sent to an acquirer of the merchant 110, such as the acquirer server 120 via the communication interface 710. Without loss of generality, the communication is achieved through Application Program Interface (API) calls.
[0083] FIG. 8 is a simplified block diagram of a payment server 800 for performing the payment transaction, in accordance with an embodiment of the present disclosure. The payment server 800 is an example of a server, such as the payment server 116 of FIG. 1. The payment server 800 may use a network, such as the network 114 of FIG. 1 as a payment network. For instance, the payment network is used as a payment interchange network by the payment server 800, issuer server 900 and acquirer server 1000. Examples of the payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The payment server 800 includes a processing system 802 configured to extract programming instructions from a memory 804 to provide various features of the present disclosure. Further, the payment server 800 includes a communication interface 806, a decoding module 808 and a database 810. The components of the payment server 800 provided herein may not be exhaustive and that the payment server 800 may include more or fewer components than those depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 800 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0084] The processing system 802 is operatively coupled to the communication interface 806 such that the payment server 800 is capable of communicating with a remote device 812, such as a user device 104, the merchant device 112, the issuer server 118, the acquirer server 120 (shown in FIG. 1) or communicating with any entity connected to the network 114 . Via the communication interface 806, the processing system 802 receives the user provided QR code from the remote device 812. For example, the user provided QR code is received via a user application 125 in the remote device 812, i.e., the user device 104. The processing system 802 also receives the merchant provided QR code and a payment amount for the payment transaction from the remote device 812. For instance, the merchant provided QR code is received via a user application 125 in the remote device 812, i.e., the merchant device 112.
[0085] In an embodiment, the communication interface 806 receives a user data upon registration of the user 102 at the user application 125. The user data include, but are not limited to, a user identifier data, a username data, and a payment account data of the user 102. The communication interface 806 also receives a merchant data upon registration of the merchant 110 at the merchant application 130. The merchant data include, but are not limited to, a merchant identifier data, a merchant name data and a payment account data of the merchant 110. The processing system 802 stores the user data and the merchant data at the database 810.
[0086] The database 810 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, the user data and the merchant database. The database 810 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 810 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[0087] After receiving the user provided QR code and the merchant provided QR code, the processing system 802 determines a match between the user provided QR code and the merchant provided QR code. The processing system 802 sends the user provided QR code and the merchant provided QR code to the decoding module 808. In an example embodiment, the decoding module 808 is configured to decode the user provided QR code and the merchant provided QR code. The decoding module 808 extracts a random number data from each of the user provided QR code and the merchant provided QR code after the decoding. The random numbers are provided to the processing system 802 by the decoding module 808. The processing system 802 identifies whether the random numbers are matching.
[0088] After identifying the matching random number, the processing system 802 accesses the user data and the merchant data from the database 810. Via the communication interface 806, the processing system 802 sends a payment transaction request for the payment amount to the remote device 812, i.e., the issuer server 118 using the user data and the merchant data. Further, the processing system 802 sends the payment amount to the acquirer server 120 using the merchant data upon receipt of the payment amount from the issuer server 118.
[0089] FIG. 9 is simplified block diagram of an issuer server 900, in accordance with an embodiment of the present disclosure. The issuer server 900 is an example of the issuer server 118 of FIG. 1, or may be embodied in the issuer server 118. The issuer server 900 is associated with an issuer bank/issuer, in which a user (e.g., the user 102) may have a payment account. The issuer server 900 includes a processing module 902 operatively coupled to a storage module 904 and a communication module 906. The components of the issuer server 900 provided herein may not be exhaustive and that the issuer server 900 may include more or fewer components than those depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 900 may be configured using hardware elements, software elements, firmware elements and/or combination thereof.
[0090] The storage module 904 is configured to store machine executable instructions to be accessed by the processing module 902. Additionally, the storage module 904 stores information related to, contact information of the user 102, bank account number, availability of funds in the account, payment card details, transaction details and/or the like.
[0091] The processing module 902 is configured to communicate with one or more remote devices, such as a remote device 908 using the communication module 906 over a network, such as the network 114 of FIG. 1. An example of the remote device 908 includes the payment server 800 or any other computing systems of the issuer server 900 and the network 114. The communication module 906 is capable of facilitating such operative communication with the remote device 908 and cloud servers using API (Application Program Interface) calls.
[0092] In an embodiment, the communication module 906 receives a payment transaction request from the payment server 800 and provides the payment transaction request to the processing module 902. The processing module 902 validates the payment transaction request. After the validation, a payment amount for the payment transaction is debited from a payment account of the user 102. The processing module 902 sends the payment amount to the payment server 800 via the communication module 906.
[0093] FIG. 10 is a simplified block diagram of an acquirer server 1000, in accordance with an embodiment of the present disclosure. The acquirer server 1000 is an example of the acquirer server 120 of FIG. 1, or may be embodied in the acquirer server 120. The acquirer server 1000 is associated with an acquirer bank/acquirer, in which a merchant (e.g., the merchant 110) may have a payment account. The acquirer server 1000 includes a processing module 1002 operatively coupled to a memory 1004, and a communication module 1006. The components of the acquirer server 1000 provided herein may not be exhaustive and that the acquirer server 1000 may include more or fewer components than those depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 1000 may be configured using hardware elements, software elements, firmware elements and/or combination thereof.
[0094] The memory 1004 is configured to store machine executable instructions to be accessed by the processing module 1002. Additionally, the memory 1004 stores information related to, contact information of the merchant, bank account number of merchant, availability of funds in the account, payment card details, transaction details and/or the like.
[0095] The processing module 1002 is configured to communicate with one or more remote devices, such as a remote device 1008 using the communication module 1006 over a network, such as the network 114 of FIG. 1. An example of the remote device 1008 includes the payment server 800 or any other computing systems of the acquirer server 1000 and the network 114. In an example embodiment, the processing module 1002 receives a payment amount from the payment server 800 via the communication module 1006. The communication module 1006 is capable of facilitating such operative communication with the remote device 1008 and cloud servers using API (Application Program Interface) calls.
[0096] FIG. 11 shows a simplified block diagram of a merchant device 1100 for example, the merchant device 112 capable of implementing the various embodiments of the present disclosure. The merchant device 1100 includes at least one processing module 1102, a memory 1104, a QR code generator 1106, an input/output (I/O) module 1108, a communication module 1110, a merchant application 1112 and a camera module 1114. The components of the merchant device 1100 provided herein may not be exhaustive and the merchant device 1100 may include more or fewer components than those depicted in FIG. 11. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the merchant device 1100 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[0097] The processing module 1102 is configured to execute the executable instructions stored in the memory 1104. In an embodiment, the communication module 1110 also includes an application interface, such as the merchant application 1112. The merchant application 1112 is an example of the merchant application 130 described in FIG. 1. The merchant application 1112 provides a registration of a merchant (e.g., the merchant 110) for the QR based payment transaction. The merchant application 1112 receives a merchant data provided by the merchant 110 and sends the merchant data to the payment server 800 through a network, such as the network 114. The communication module 1110 may also include a network interface that allows communication between the merchant device 1100 and the payment sever 800. The merchant application 1112 also provides a QR scan option to the merchant 110. When the merchant 110 selects the QR scan option, the camera module 1114 of the merchant device 1100 is triggered to capture a QR code, such as the QR code 108 of FIG. 1.
[0098] In an example embodiment, the processing module 1102 communicates with the QR code generator 1106 to generate a QR code that is valid for a pre-defined threshold time-period. In an embodiment, the QR code generator 1106 is configured to generate the QR code based on a random number data. The random number data may be a 20-digit number, that can give combinations of 1020 numbers.
[0099] The QR code generator 1106 provides the generated QR code (e.g., the QR code 202) to the I/O module 1108. In an embodiment, the I/O module 1108 may include mechanisms configured to receive inputs from and provide outputs to the merchant 110. For instance, the I/O module 1108 may include at least one input interface and/or at least one output interface. Examples of the input interface may include, but are not limited to, a keyboard, a mouse, a joystick, a keypad, a touch screen, soft keys, a microphone, and the like. Examples of the output interface may include, but are not limited to, a display screen such as a light emitting diode display, a thin-film transistor (TFT) display, a liquid crystal display, an active-matrix organic light-emitting diode (AMOLED) display, etc.), and the like. In an example embodiment, the output interface is a UI screen, such as the UI 200 of FIG. 2 that displays the QR code generated by the QR code generator 1106.
[00100] The QR code is displayed on the UI 200 along with a timer, such as the timer 204. The timer may be generated by a timer module (not shown in FIG. 11) of the merchant device 1100. The timer corresponds to the valid pre-defined threshold time-period of the QR code. In another example embodiment, the merchant device 1100 and the UI 200 may be connected via the communication module 1110. The communication module 1110 may include a wireless communication interface. For instance, the wireless communication interface may provide a short-range communication with the UI 200 via a Bluetooth, a Near-Field Communication (NFC) or an Infrared communication.
[00101] Further, the QR code generator 1106 is also configured to generate an updated QR code. The QR code generator 1106 resets the random number data in the QR code. The reset random number data is embedded in the QR code for generating the updated QR code. In an example embodiment, the random number data is reset based on one of an expiration of the pre-defined threshold time-period, a trigger provided by the merchant 110 for updating the QR code, and a completion of a successful payment transaction. For instance, the timer module of the merchant device 1100 may sense the expiration of the pre-defined threshold time-period. The timer module may trigger the QR code generator 1106 to update the QR code. In one example embodiment, the I/O module 1108 may be connected to a trigger input button (e.g., the trigger button 206 of FIG. 2) to receive the trigger for the QR code update. In another example embodiment, the communication module 1110 may receive a notification message on the completion of the payment transaction. The communication module 1110 provides the notification message to the processing module 1102. The processing module 1102 invokes the QR code generator 1106 to update the QR code.
[00102] Moreover, the various components of the merchant device 1100, such as the processing module 1102, the memory 1104, the QR code generator 1106, the input/output module 1108, the communication module 1110, the merchant application 1112 and the camera module 1114 may be configured to communicate with each other via or through a centralized circuit system 1116. The centralized circuit system 1116 may be various devices configured to, among other things, provide or enable communication between the components (1102 - 1116) of the merchant device 1100. In certain embodiments, the centralized circuit system 1116 may be a central printed circuit board (PCB) such as a motherboard, a main board, a system board, or a logic board. The centralized circuit system 1116 may also, or alternatively, include other printed circuit assemblies (PCAs) or communication channel media. In some embodiments, the centralized circuit system 1116 may include appropriate storage interfaces to facilitate communication among the components (1102 - 1114). Some examples of the storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the merchant device 1100 with access to the data stored in a memory (not shown in FIG. 11).
[00103] FIG. 12 shows a simplified block diagram of a user device 1200, for example a mobile phone capable of implementing the various embodiments. The user device 1200 is depicted to include one or more applications 1206. The user device 1200 is an example of the user device 104. It should be understood that the user device 1200 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with the user device 1200 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 12. As such, among other examples, the user device 1200 could be any of an electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00104] The illustrated user device 1200 includes a controller or a processor 1202 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1204 controls the allocation and usage of the components of the user device 1200 and support for one or more applications programs (see, applications 1206), such as a user application 125 for the QR based payment transaction in the user device 1200 of a user (e.g., the user 102). In addition to the application, the applications 1206 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications such as USSD messaging or SMS messaging or SIM Tool Kit (STK) application) or any other computing application.
[00105] The illustrated user device 1200 includes one or more memory components, for example, a non-removable memory 1208 and/or removable memory 1210. The non-removable memory 1208 and/or removable memory 1210 may be collectively known as database in an embodiment. The non-removable memory 1208 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1210 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1204 and the applications 1206. The user device 1200 may further include a user identity module (UIM) 1212. The UIM 1212 may be a memory device having a processor built in. The UIM 1212 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1212 typically stores information elements related to a mobile subscriber. The UIM 1212 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA7000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00106] The user device 1200 can support one or more input devices 1220 and one or more output devices 1230. Examples of the input devices 1220 may include, but are not limited to, a touch screen / a screen 1222 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1224 (e.g., capable of capturing voice input), a camera module 1226 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1228. Examples of the output devices 1230 may include, but are not limited to a speaker 1232 and a display 1234. Other possible output devices 1230 can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1222 and the display 1234 can be combined into a single input/output device.
[00107] A wireless modem 1240 can be coupled to one or more antennas (not shown in the FIG. 12) and can support two-way communications between the processor 1202 and external devices, as is well understood in the art. The wireless modem 1240 is shown generically and can include, for example, a cellular modem 1242 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1244 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1246. The wireless modem 1240 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the user device 1200 and a public switched telephone network (PSTN).
[00108] The user device 1200 can further include one or more input/output ports 1250 for establishing connection with peripheral devices including a power supply 1252, one or more sensors 1254 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the device 1200 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1256 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1260, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00109] With the application (see, applications 1206) and/or other software or hardware components, the user device 1200 can implement the technologies described herein. In one example embodiment, the processor 1202 can cause performing registration of the user 102, selecting a QR scan option, scanning a QR code from a UI, such as the UI 200, sending a scanned QR code of the user 102 as user provided QR code to a server, such as the payment server 800 and making a payment transaction to a payee, such as the merchant 110 of FIG. 1.
[00110] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for performing payment transaction using a Quick Response (QR) code. The QR code is generated based on a random number data and is valid for a pre-defined threshold time-period. The QR code is updated upon expiry of the valid pre-defined threshold time-period. This makes the QR code dynamic in nature. Moreover, the QR code does not embed any personal or confidential information of the merchant 110. This provides an enhanced security and also increases difficulty in replicating the QR code into a counterfeit QR code by fraudsters. Further, a user 102 and the merchant 110 need to scan the QR code within the valid pre-defined threshold time-period for the payment transaction as the QR code is dynamic. The QR code is displayed on a user interface (a transparent display screen) that enables scanning of the QR code from both sides of the UI by the user 102 and the merchant 110 in same time. Each scanned QR code of the user 102 and the merchant 110 is provided via an application in each device of the user 102 and the merchant 110. Thus, the user 102 and the merchant 110 may perform the QR based payment transaction in a secure, feasible and efficient manner.
[00111] The disclosed methods with reference to FIGS. 1 to 12, or one or more operations of the method 500 and the method flow diagram 600 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and is considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00112] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00113] Particularly, the server system 700 (e.g. the payment server 116) and its various components such as the computer system 702 and the database 704 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.
[00114] Various embodiments of the disclosure, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the disclosure has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the disclosure.
[00115] Although various exemplary embodiments of the disclosure are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
| # | Name | Date |
|---|---|---|
| 1 | 202041004157-FORM 18 [17-01-2024(online)].pdf | 2024-01-17 |
| 1 | 202041004157-STATEMENT OF UNDERTAKING (FORM 3) [30-01-2020(online)].pdf | 2020-01-30 |
| 2 | 202041004157-POWER OF AUTHORITY [30-01-2020(online)].pdf | 2020-01-30 |
| 2 | 202041004157-Correspondence_07-02-2020.pdf | 2020-02-07 |
| 3 | 202041004157-FORM 1 [30-01-2020(online)].pdf | 2020-01-30 |
| 3 | 202041004157-Deed of Assignment_(As Filed)_07-02-2020.pdf | 2020-02-07 |
| 4 | 202041004157-DRAWINGS [30-01-2020(online)].pdf | 2020-01-30 |
| 4 | 202041004157-Proof of Right [05-02-2020(online)].pdf | 2020-02-05 |
| 5 | 202041004157-DECLARATION OF INVENTORSHIP (FORM 5) [30-01-2020(online)].pdf | 2020-01-30 |
| 5 | 202041004157-Correspondence_04-02-2020.pdf | 2020-02-04 |
| 6 | 202041004157-Form26_General Power of Attorney_04-02-2020.pdf | 2020-02-04 |
| 6 | 202041004157-COMPLETE SPECIFICATION [30-01-2020(online)].pdf | 2020-01-30 |
| 7 | 202041004157-Form26_General Power of Attorney_04-02-2020.pdf | 2020-02-04 |
| 7 | 202041004157-COMPLETE SPECIFICATION [30-01-2020(online)].pdf | 2020-01-30 |
| 8 | 202041004157-DECLARATION OF INVENTORSHIP (FORM 5) [30-01-2020(online)].pdf | 2020-01-30 |
| 8 | 202041004157-Correspondence_04-02-2020.pdf | 2020-02-04 |
| 9 | 202041004157-Proof of Right [05-02-2020(online)].pdf | 2020-02-05 |
| 9 | 202041004157-DRAWINGS [30-01-2020(online)].pdf | 2020-01-30 |
| 10 | 202041004157-Deed of Assignment_(As Filed)_07-02-2020.pdf | 2020-02-07 |
| 10 | 202041004157-FORM 1 [30-01-2020(online)].pdf | 2020-01-30 |
| 11 | 202041004157-Correspondence_07-02-2020.pdf | 2020-02-07 |
| 11 | 202041004157-POWER OF AUTHORITY [30-01-2020(online)].pdf | 2020-01-30 |
| 12 | 202041004157-FORM 18 [17-01-2024(online)].pdf | 2024-01-17 |
| 13 | 202041004157-FER.pdf | 2025-05-05 |
| 15 | 202041004157-FER_SER_REPLY [03-11-2025(online)].pdf | 2025-11-03 |
| 16 | 202041004157-COMPLETE SPECIFICATION [03-11-2025(online)].pdf | 2025-11-03 |
| 17 | 202041004157-CLAIMS [03-11-2025(online)].pdf | 2025-11-03 |
| 18 | 202041004157-ABSTRACT [03-11-2025(online)].pdf | 2025-11-03 |
| 1 | SearchHistoryE_18-10-2024.pdf |