Description:THIS APPLICATION IS A PATENT OF ADDITION TO INDIAN PATENT APPLICATION NO. 202121060001 FILED ON 22/12/2021.
FIELD
The present disclosure generally relates to offline payment systems. More particularly, the present disclosure relates to a system and method for secure financial transaction processing.
DEFINITIONS
As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
The term “set of tokenization rules” is a set of instructions used to tokenize financial accounts by replacing sensitive payment information, such as credit card numbers, and sensitive details with a unique, random set of characters.
The term “set of verification rules” is a set of instructions used to match and verify the verification code/PIN entered by the user during the transaction with the verification code/PIN generated by the payment application and facilitate the user to authorize the transaction.
The term “user/customer’ is hereafter interchangeably used in the specification to represent the user/customer involvement in the payment transaction.
BACKGROUND
The background information herein below relates to the present disclosure but is not necessarily prior art.
Performing payments without the use of any payment interface or online applications poses several limitations in today's fast-paced and digitally-driven world. Traditional payment methods, such as cash or checks, lack the speed and convenience offered by digital platforms. One significant limitation is the absence of real-time transactions, making it challenging for businesses and individuals to conduct instant fund transfers.
Moreover, manual processes involved in non-digital payments can lead to errors, delays, and increased operational costs. Tracking and managing financial transactions become more cumbersome without the streamlined interfaces provided by online applications, making it difficult to maintain accurate records.
In such a scenario many retail stores don’t have any electronic devices such as POS machines or any mobile applications to collect the bills and keep track of the transactions. Such retail stores can't afford device costs or the maintenance of these devices. Some of the retail stores are not very aware of using such devices and use of such devices. Furthermore, the use of such devices makes it easy to maintain and track all the transactions and hence the lack of digital receipts and electronic documentation can hinder transparency and auditability. In a landscape where digital payments offer efficiency, security, and ease of use, relying on non-digital methods may result in a less optimal and more resource-intensive financial experience.
This technical problem is solved by providing the technical solution where the transaction that performs transaction processing at the retail store (online or offline merchant) doesn’t have any device or payment interface or application.
Therefore, there is felt a need for a system and method for secure transaction processing that alleviates the above-mentioned drawbacks.
OBJECTS
Some of the objects of the present disclosure, which at least one embodiment herein satisfies, are as follows:
It is an object of the present disclosure to ameliorate one or more problems of the prior art or to at least provide a useful alternative.
An object of the present disclosure is to provide a system for secure transaction processing.
Another object of the present disclosure is to provide a system for offline secure transactions to carry out payment transactions.
Still another object of the present disclosure is to provide a system for secure transaction processing that offers the user a safe and convenient way of performing transactions when merchants do not have POS or another payment mode.
Yet another object of the present disclosure is to provide a method of secure transaction processing.
Other objects and advantages of the present disclosure will be more apparent from the following description when read in conjunction with the accompanying figures, which are not intended to limit the scope of the present disclosure.
SUMMARY
The present disclosure envisages a system for facilitating secure transaction processing. The system comprises a server.
The server implements a payment application having a user interface to allow users to register financial accounts for carrying out secure payment transactions and further having a merchant interface to provide merchant details.
The server includes a data repository, a tokenization module, a scanning and extracting module, a transaction module, and a verification module.
The data repository is configured to store predefined commands, a set of tokenization rules, register user's details, static hydepay QR code, transaction details with ID, register merchant’s details, and a set of verification rules.
The tokenization module is configured to cooperate with the data repository to receive the registered financial accounts and tokenize the financial accounts by means of the set of tokenization rules.
The scanning and extracting module of the payment application is configured to scan a static hypepay QR code by means of an electronic device and extract the registered merchant’s details for secure payment transactions, wherein the static hypepay QR code is generated/provided by the payment application.
The transaction module of the payment application is configured to cooperate with the scanning and extracting module to receive the registered The merchant’s details and open the merchant interface for processing transactions, and further configured to enter the transaction amount and generate a verification code/PIN for transaction.
The verification module of the payment application (104) is configured to cooperate with the transaction module to receive the transaction amount and the verification code/PIN to verify the transaction for secure transaction with transaction ID by means of the set of verification rules.
The tokenization module, the scanning and extracting module, the transaction module, the verification module are executed and operated by one or more microprocessor(s).
In an embodiment, the static hydepay QR code is generated/provided by the payment application on successful registration of the merchant with valid details.
In an embodiment, the successful login into the payment application on successful login attempt by using login credentials.
In an embodiment, the transaction module generates the verification code/PIN in numeric, alphanumeric, symbolic, or combination thereof.
In an embodiment, the transaction is verified the transaction by swiping left or right or via biometric or application PIN, or one time password (OTP) generated in real-time.
In an embodiment, the set of tokenization rules is a set of instructions used to tokenize financial accounts by replacing sensitive payment information, such as credit card numbers, and sensitive details with a unique, random set of characters.
In an embodiment, the verification code/PIN is automatically fetched by the merchant interface from the payment application logs during the checkout of the payment or manually entered by the user during the checkout of the payment.
The present disclosure also envisages a method for secure transaction processing. The method comprises the following steps:
• implementing, by a server, a payment application having a user interface to allow users to register financial accounts for carrying out secure payment transactions and having a merchant interface to provide merchant details,
• receiving, by a tokenization module, the registered financial accounts and tokenizing the financial accounts by means of the set of tokenization rules;
• scanning, by a scanning and extracting module of the payment application, a static hypepay QR code by means of an electronic device and extracting the registered merchant’s details for secure payment transactions, wherein the static hypepay QR code generated/provided by the payment application;
• receiving, by a transaction module of the payment application, the registered merchant’s details and opening the merchant interface for processing transactions, and entering the transaction amount and generating a verification code/PIN for transaction; and
• receiving, by a verification module of the payment application, the transaction amount and the verification code/PIN to verify the transaction for secure transaction with transaction ID by means of the set of verification rules.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
A system for secure transaction processing and method thereof of the present disclosure will now be described with the help of the accompanying drawing, in which:
Figure 1 illustrates a block diagram of a system for facilitating secure transaction processing;
Figures 2A and 2B illustrate a flow diagram of a method for facilitating secure transaction processing, in accordance with the present disclosure; and
Figures 3A-3G illustrate an exemplary user flow at a merchant’s retail store, in accordance with an embodiment of the present disclosure.
LIST OF REFERENCE NUMERALS
100 - System
102 - Server
104 - HydePay(TM) Application /Payment Application
106 - User Interface
108 - Merchant Interface
110 - Data Repository
112 - Tokenization Module
114 - Scanning and Extracting Module
116 - Transaction Module
118 - Verification Module
120 - Issuing Bank
122 - Acquirer Bank
124 - Merchant Server
DETAILED DESCRIPTION
Embodiments, of the present disclosure, will now be described with reference to the accompanying drawing.
Embodiments are provided so as to thoroughly and fully convey the scope of the present disclosure to the person skilled in the art. Numerous details, are set forth, relating to specific components, and methods, to provide a complete understanding of embodiments of the present disclosure. It will be apparent to the person skilled in the art that the details provided in the embodiments should not be construed to limit the scope of the present disclosure. In some embodiments, well-known processes, well-known apparatus structures, and well-known techniques are not described in detail.
The terminology used, in the present disclosure, is only for the purpose of explaining a particular embodiment and such terminology shall not be considered to limit the scope of the present disclosure. As used in the present disclosure, the forms "a,” "an," and "the" may be intended to include the plural forms as well, unless the context clearly suggests otherwise. The terms “including,” and “having,” are open ended transitional phrases and therefore specify the presence of stated features, integers, steps, operations, elements and/or components, but do not forbid the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The particular order of steps disclosed in the method and process of the present disclosure is not to be construed as necessarily requiring their performance as described or illustrated. It is also to be understood that additional or alternative steps may be employed.
As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed elements.
Performing payments without the use of any payment interface or online applications poses several limitations in today's fast-paced and digitally-driven world. Traditional payment methods, such as cash or checks, lack the speed and convenience offered by digital platforms. One significant limitation is the absence of real-time transactions, making it challenging for businesses and individuals to conduct instant fund transfers.
Moreover, manual processes involved in non-digital payments can lead to errors, delays, and increased operational costs. Tracking and managing financial transactions become more cumbersome without the streamlined interfaces provided by online applications, making it difficult to maintain accurate records.
In such a scenario many retail stores don’t have any electronic devices such as POS machines or any mobile applications to collect the bills and keep track of the transactions. Such retail stores can't afford device costs or the maintenance of these devices. Some of the retail stores are not very aware of using such devices and use of such devices. Furthermore, the use of such devices makes it easy to maintain and track all the transactions and hence the lack of digital receipts and electronic documentation can hinder transparency and auditability. In a landscape where digital payments offer efficiency, security, and ease of use, relying on non-digital methods may result in a less optimal and more resource-intensive financial experience.
This technical problem is solved by providing the technical solution where the transaction that performs transaction processing at the retail store (online or offline merchant) doesn’t have any device or payment interface or application.
In order to address the aforementioned problems, the present disclosure envisages a system (hereinafter referred to as “system 100”) for facilitating secure transaction processing and a method thereof (hereinafter referred to as “method 200”). The system 100 and method 200 are now being described with reference to Figure 1 through Figure 3A-3G.
Referring to Figure 1, the system 100 comprises a server 102.
The server 102 implements a payment application 104 having a user interface 106 to allow users to register financial accounts for carrying out secure payment transactions and further having a merchant interface 108 to provide merchant details.
The server includes a data repository 110, a tokenization module 112, a scanning and extracting module 114, a transaction module 116, and a verification module 118.
The data repository 110 is configured to store predefined commands, a set of tokenization rules, register user's details, static hydepay QR code, transaction details with ID, register merchant’s details, and a set of verification rules.
The data repository 110 may be a memory that can store one or more computer-readable instructions or routines, which may be fetched and executed to facilitate secure transaction processing. The memory may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
The tokenization module 112 is configured to cooperate with the data repository 110 to receive the registered financial accounts and tokenize the financial accounts by means of the set of tokenization rules.
The scanning and extracting module 114 of the payment application 104 is configured to scan a static hypepay QR code by means of an electronic device 116 and extract the registered merchant’s details for secure payment transactions, wherein the static hypepay QR code generated/provided by the payment application 104.
The transaction module 116 of the payment application 104 is configured to cooperate with the scanning and extracting module 114 to receive the registered merchant’s details and open the merchant interface 108 for processing transactions, and further configured to enter the transaction amount and generate a verification code/PIN for transaction.
The verification module 118 of the payment application 104 is configured to cooperate with the transaction module 116 to receive the transaction amount and the verification code/PIN to verify the transaction for secure transaction with transaction ID by means of the set of verification rules.
The tokenization module 112, the scanning and extracting module 114, the transaction module 116, the verification module 118 are executed and operated by one or more microprocessor(s).
In an embodiment, the static hydepay QR code is generated/provided by the payment application 104 on successful registration of the merchant with valid details.
In an embodiment, the successful login into the payment application 104 on successful login attempt by using login credentials.
In an embodiment, the transaction module 116 generates the verification code/PIN in numeric, alphanumeric, symbolic, or combination thereof.
In an embodiment, the transaction has verified the transaction by swiping left or right or via biometric or application PIN, or one time password (OTP) generated in real-time.
In an embodiment, the set of tokenization rules is a set of instructions used to tokenize the financial accounts by replacing the sensitive payment information, such as credit card numbers, and sensitive details with a unique, random set of characters.
In an embodiment, the verification code/PIN is automatically fetched by the merchant interface 108 from the payment application 104 logs during the checkout of the payment or manually entered by the user during the checkout of the payment.
In an aspect, the microprocessor may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the microprocessor may fetch and execute computer-readable instructions stored in a memory. The functions of the microprocessor may be provided through the use of dedicated hardware as well as hardware capable of executing machine-readable instructions. In other examples, the microprocessor may be implemented by electronic circuitry or printed circuit board. The microprocessor may be configured to execute functions of various modules of the system 100 such as the tokenization module 112, the scanning and extracting module 114, the transaction module 116, and the verification module 118.
In an aspect, the system 100 may also include a communication interface. The communication interface may include a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, transceivers, storage devices, and the like. The communication interface may facilitate communication of the system 100 with various devices coupled to the system 100 or the microprocessor. The communication interface may also provide a communication pathway for one or more components of the system 100 and the microprocessor.
Also, the system 100 or the microprocessor may include, or be coupled with, one or more transceivers to communicate with various devices coupled to the system 100 or the microprocessor.
Figure 2A and Figure 2B illustrate a flow diagram of a method for facilitating secure transaction processing, in accordance with the present disclosure. The order in which method 200 is described is not intended to be construed as a limitation, and any number of the described method steps may be combined in any order to implement method 200, or an alternative method. Furthermore, method 200 may be implemented by processing resource or computing device(s) through any suitable hardware, non-transitory machine-readable medium/instructions, or a combination thereof. The method 200 comprises the following steps:
At step 202, implementing, by a server 102, a payment application 104 having a user interface 106 to allow users to register financial accounts for carrying out secure payment transactions and having a merchant interface 108 to provide merchant details.
At step 204, receiving, by a tokenization module 112, the registered financial accounts and tokenizing the financial accounts by means of the set of tokenization rules.
At step 206, scanning, by a scanning and extracting module 114 of the payment application 104, a static hypepay QR code by means of an electronic device 116 and extracting the registered merchant’s details for secure payment transactions, wherein the static hypepay QR code generated/provided by the payment application 104.
At step 208, receiving, by a transaction module 116 of the payment application 104, the registered merchant’s details and opening the merchant interface 108 for processing transactions, and entering the transaction amount and generating a verification code/PIN for the transaction.
At step 210, receiving, by a verification module 118 of the payment application 104, the transaction amount and the verification code/PIN to verify the transaction for secure transaction with transaction ID by means of the set of verification rules.
In an operative exemplary embodiment, referring to Figure 3A-3G, a registered customer/user uses the payment application 104 to perform a secure transaction with a registered merchant who has a static hydepay QR code.
Figure 3A shows the initial stage where the user wishes to perform the transaction at a retail store, where the merchant doesn’t have any POS machine or any online payment mode facility. Figure 3B shows the bill generated by the merchant and informs the user to pay the bill of Rs. 2500 by scanning the static hydepay QR code. In Figure 3C, the user logs into payment application 104 by entering his/her secure login credentials. The user selects the payment card/account for carrying out the transaction and generates a verification code/PIN for the transaction corresponding to the selected card/account. Figure 3D shows the generated verification code/PIN on the payment application 104 of the user and copies the verification code/PIN for performing the transaction. In Figure 3E, the user scans the static hydepay QR code provided by the merchant for initiating the payment processing. In Figure 3F, the user enters the amount to be paid for the transaction, enters the verification code/PIN, and proceeds with the payment transaction. Figure 3F, shows the notification message to the user via SMS from the issuer bank on the successful completion of the payment transaction and the notification to the merchant received on his/her nortification device.
In accordance with still another aspect of the present invention, the system 100 is used for transaction processing at a retail shop (online or offline merchant) that doesn’t have any device or payment interface or HydePay™ application. The merchant uses the static hydepay QR code which is generated/provided by the HydePay(TM) app/ payment application 104, wherein the static hydepay QR code consist of the merchant details In an operative embodiment, a customer wishing to make a payment of ‘x’ amount to a merchant using the HydePay(TM) app/ payment application 104 logs into the application 104 by entering his/her secure login credentials. Thereafter, the customer selects a payment card/account for carrying out the transaction and generates a verification code/PIN for the transaction corresponding to the selected card/account. The customer then scans the static hydepay QR code of the vendor using the QR code scanner using her/his application 104.
This opens the merchant interface 108 within the HydePay(TM) app/ payment application 104 by scanning the static hydepay QR code and then prompts the customer to enter the amount ‘x’ and the verification code/PIN to proceed with the transaction on the merchant interface 108. The generated verification code/PIN hydepin may also be automatically fetched by the merchant interface 108 from HydePay(TM) app/ payment application 104 logs during the checkout of the payment or manually entered by the customer during the checkout of the payment.
The transaction module 116 compares the verification code/PIN generated by the customer with the verification code/PIN received and approves the transaction if they match. After approval/successful verification, the transaction server 108 sends an authorization request to the customer on his payment application interface 104 to facilitate the customer to authorize the transaction. The authorization may be performed using one or more of the methods described herein above. Upon receiving authorization from the customer, the transaction module 116 sends the transaction details to the issuing bank 120 of the customer, via the acquirer bank 122, to facilitate the completion of the transaction. The issuing bank 120 may additionally perform an authentication step (e.g., OTP-based authentication) to authenticate the transaction by sending an OTP to the customer. The customer enters the received OTP on the merchant interface 108 via which it is relayed to the transaction module 116 and thereafter to the issuing bank 120. The issuing bank 120 compares the generated one-time password with the received one-time password to authenticate the transaction. Upon successful authentication, the issuing bank 120 debits the customer account with the transaction amount and sends the debit success message to the transaction module 116. Upon receiving the debit success message, the transaction module 116 sends a credit request message to the acquirer bank 122 or the payment gateway via the merchant server 124 to cause the transaction amount to be credited to the merchant’s account and notify the merchant by means of notification devices, wherein the notification devices include a mobile device or audio devices or any device capable of providing notifications. Upon successful debit and credit, the transaction server 108 informs the customer about the success of the transaction as shown in Figure 4J. Additionally, the issuing bank 120 sends an SMS to the customer to inform the customer about the transaction status.
An exemplary pseudo-code depicting the implementation of method 200 for processing at a retail shop (online or offline merchant) –
Do STEP A
{
merchant creates a bill;
customer logs into the HydePay(TM) app/ payment application 104 by entering his/her secure login credentials;

}
If (customer login successful == YES) STEP B
{
generate a verification code/PIN;
customer scans the static hydepay QR code of the merchant;
}
Else
{
Login not successful;
GOTO STEP A;
}

If (static hydepay QR code scanned == YES) STEP C
{
open merchant interface 108;
customer enters the verification code/PIN;
enter the amount ‘x’;
customer will initiate the processing of the payment;

}
Else
{
static hydepay QR code not found/matched;
GOTO STEP A;
}
While (customer scanned the static hydepay QR code )
{
the customer to authorize the transaction on the merchant interface 108 by swapping right or left or using any authorization procedure;
OR
Issuer Bank sends OTP to the customer;
customer enters the OTP on his/her application to approve the transaction;
}
In an operative configuration, the system comprises a server 102 implements a payment application 104 having a user interface 106 to allow users to register financial accounts for carrying out secure payment transactions and further having a merchant interface 108 to provide merchant details, wherein the server 102 comprises a data repository 110 is configured to store predefined commands, a set of tokenization rules, register user's details, static hydepay QR code, transaction details with ID, register merchant’s details, and set of verification rules. The tokenization module 112 is configured to cooperate with the data repository 110 to receive the registered financial accounts and tokenize the financial accounts by means of the set of tokenization rules. The scanning and extracting module 114 of the payment application 104 is configured to scan a static hypepay QR code by means of an electronic device 116 and extract the registered merchant’s details for secure payment transactions, wherein the static hypepay QR code generated/provided by the payment application 104. The transaction module 116 of the payment application 104 is configured to cooperate with the scanning and extracting module 114 to receive the registered merchant’s details and open the merchant interface 108 for processing transactions, and further configured to enter the transaction amount and generate a verification code/PIN for transaction. The verification module 118 of the payment application 104 is configured to cooperate with the transaction module 116 to receive the transaction amount and the verification code/PIN to verify the transaction for secure transaction with transaction ID by means of the set of verification rules.
Advantageously, the system 100 facilitates secure transaction processing. The system 100 performs the transaction processing at a retail shop (online or offline merchant) that doesn’t have any device payment interface or payment application 104. The system 100 perfor the transaction based by scanning the static hydepay QR code which is generated/provided by the HydePay(TM) app/ payment application 104.
The communication means described herein may refer to a means for transmitting and receiving electronic data. The communication means may include, for example, the Internet, the World Wide Web, an intranet, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), and electronic communications. Wireless communication means can support various wireless communication network protocols and technologies such as Near Field Communication (NFC), Wi-Fi, Bluetooth, 4G Long Term Evolution (LTE), Code Division Multiplexing Access (CDMA), Universal Mobile Telecommunication System (UMTS) and Global System for Mobile Telecommunication (GSM).
The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.
The foregoing description of the embodiments has been provided for purposes of illustration and not intended to limit the scope of the present disclosure. Individual components of a particular embodiment are generally not limited to that particular embodiment, but, are interchangeable. Such variations are not to be regarded as a departure from the present disclosure, and all such modifications are considered to be within the scope of the present disclosure.
TECHNICAL ADVANCEMENTS
The present disclosure described herein above has several technical advantages including, but not limited to, the realization of a system for secure transaction processing and method thereof that:
• do not require a merchant to have POS or any payment application for receiving the transaction;
• easy to use;
• fast and efficient; and
• provide independent transactions over POS transactions.
The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
The foregoing description of the specific embodiments so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
The use of the expression “at least” or “at least one” suggests the use of one or more elements or ingredients or quantities, as the use may be in the embodiment of the disclosure to achieve one or more of the desired objects or results.
While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
, Claims:I CLAIM:
1. A system (100) for facilitating secure transaction processing, said system (100) comprising:
• a server (102) implements a payment application (104) having a user interface (106) to allow users to register financial accounts for carrying out secure payment transactions and further having a merchant interface (108) to provide merchant details, wherein said server (102) comprises:
o a data repository (110) configured to store predefined commands, a set of tokenization rules, register user's details, static hydepay QR code, transaction details with ID, register merchant’s details, and set of verification rules;
o a tokenization module (112) configured to cooperate with said data repository (110) to receive said registered financial accounts and tokenize said financial accounts by means of said set of tokenization rules;
o a scanning and extracting module (114) of the payment application (104) configured to scan a static hypepay QR code by means of an electronic device (116) and extract said registered merchant’s details for secure payment transactions, wherein said static hypepay QR code generated/provided by said payment application (104);
o a transaction module (116) of the payment application (104) configured to cooperate with said scanning and extracting module (114) to receive said registered merchant’s details and open said merchant interface (108) for processing transactions, and further configured to enter the transaction amount and generate a verification code/PIN for transaction; and
o a verification module (118) of the payment application (104) configured to cooperate with said transaction module (116) to receive said transaction amount and said verification code/PIN to verify the transaction for secure transaction with transaction ID by means of said set of verification rules,
said tokenization module (112), said scanning and extracting module (114), said transaction module (116), said verification module (118) are executed and operated by one or more microprocessor(s).
2. The system (100) as claimed in claim 1, wherein said static hydepay QR code is generated/provided by the payment application 104 on successful registration of the merchant with valid details.
3. The system (100) as claimed in claim 1, wherein said successful login into said payment application (104) on successful login attempt by using login credentials.
4. The system (100) as claimed in claim 1, wherein said transaction module (116) generates the verification code/PIN in numeric or alphanumeric or symbolic, or in combination thereof.
5. The system (100) as claimed in claim 1, wherein said transaction is verified the transaction by swiping left or right or via biometric or application PIN, or one time password (OTP) generated in real-time.
6. The system (100) as claimed in claim 1, wherein said set of tokenization rules is a set of instructions used to tokenize the financial accounts by replacing the sensitive payment information, such as credit card numbers, and sensitive details with a unique, random set of characters.
7. The system (100) as claimed in claim 1, wherein said verification code/PIN is automatically fetched by the merchant interface (108) from said payment application (104) logs during the checkout of the payment or manually entered by the user during the checkout of the payment.
8. A method (200) for facilitating secure transaction processing, said method (200) comprises the following steps:
• implementing, by a server (102), a payment application (104) having a user interface (106) to allow users to register financial accounts for carrying out secure payment transactions and having a merchant interface (108) to provide merchant details,
• receiving, by a tokenization module (112), said registered financial accounts and tokenizing said financial accounts by means of said set of tokenization rules;
• scanning, by a scanning and extracting module (114) of the payment application (104), a static hypepay QR code by means of an electronic device (116) and extracting said registered merchant’s details for secure payment transactions, wherein said static hypepay QR code generated/provided by said payment application (104);
• receiving, by a transaction module (116) of the payment application (104), said registered merchant’s details and opening said merchant interface (108) for processing transactions, and entering the transaction amount and generating a verification code/PIN for transaction; and
• receiving, by a verification module (118) of the payment application (104), said transaction amount and said verification code/PIN to verify the transaction for secure transaction with transaction ID by means of said set of verification rules.

Dated this 23rd Day of December, 2023

_______________________________
MOHAN RAJKUMAR DEWAN, IN/PA – 25
of R.K. DEWAN & CO.
Authorized Agent of Applicant

TO,
THE CONTROLLER OF PATENTS
THE PATENT OFFICE, AT MUMBAI