Secure transaction processing system and method

Abstract

Secure transaction processing system and method The present invention discloses a system (100) and method (200) for secure transaction processing. The system (100) comprises a payment application (102), a memory (106) and a settlement server (108) hosting the application (102). The application (102) allows registered users to generate requests to initiate a payment. The memory (106) stores registered users associated with a list of identifiers and their corresponding registration details. Upon receiving a payment request, the settlement server (108) generates and sends a first one-time verification code / PIN to the application (102). The settlement server (108) receives the second verification code / PIN via a second user interface (20), verifies the two codes / PINs, and if the two codes / PINs match, sends the transaction data to the issuing bank (30) of the first user via the acquiring bank (40) to complete the payment. The system (100) allows users to perform a payment without entering a secure payment account.

Description

[Technical field]

[0001] The present invention relates generally to payment systems. More specifically, the present invention relates to a system and method for secure payment processing. Background of the invention technology The following background information is relevant to the present invention but is not necessarily prior art. Typically, point-of-sale or automated teller machine (ATM) based payment systems require the use of credit / debit / prepaid cards to carry out financial transactions. Similarly, internet based payment systems require financial related information such as credit / debit card details, online banking login credentials / usernames, passwords for financial services such as PayPal, etc. Internet based payment systems allow remote access to payment accounts to carry out payments without requiring a visit to the bank or paper based transaction methods. However, point-of-sale (POS) payments, ATM or internet payment transactions require the user to insert the payment card into the merchant's point-of-sale (POS) terminal or ATM or enter the account details into a service application interface or payment website. These websites / interfaces may also directly store some payment details such as card number as a token. Even if the card details are stored as a token in the card or file service, the customer still needs to fill in all the card details at least once on the website, which may be stolen. Other details such as Card Verification Value (CVV) are also required each time a transaction is desired. This exposes the transaction data to the user's third-party service provider, thus increasing the risk of transaction fraud. Also, bank details, account details, debit card numbers, prepaid card numbers, credit card numbers, card expiry details, Card Verification Value (CVV), netbanking login username, login credentials associated with transaction accounts, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) usernames, PayPal usernames, Zelle usernames and other transaction usernames are typically transmitted over the public internet. Such transmissions are frequently subject to a wide variety of hacking attacks that may result in the disclosure of sensitive financial information. Therefore, there is a need for a secure transaction processing system and method that mitigates the above-mentioned disadvantages. Object of the invention Some of the objects of the present invention, of which at least one embodiment is sufficient to be mentioned herein, are as follows. It is an object of the present invention to ameliorate one or more of the problems in the prior art, or at least to provide a useful alternative. It is an object of the present invention to provide a secure transaction processing system and method. Another object of the present invention is to provide a secure transaction processing system which enables payments to be made without entering payment account details (e.g., number, credit card number, card expiry details, Card Verification Value (CVV), net banking login username, login credentials associated with transaction accounts, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and other transaction usernames). It is yet another object of the present invention to provide a secure transaction processing system and method, which allows transactions to be carried out safely and conveniently. It is yet another object of the present invention to provide a secure transaction processing system and method that reduces exposure to hacking attacks. It is still another object of the present invention to provide a payment processing system and method that enables payment at a point-of-sale device (POS) or an automated teller machine (ATM) without using a payment card. Other objects and advantages of the present invention will become more apparent from the following description read in conjunction with the accompanying drawings, which are not intended to limit the scope of the invention thereto. Summary of the Invention The present invention provides a system for facilitating secure transaction processing. The system comprises a payment application, a memory, and a payment server on which the payment application is hosted. The application is configured to provide a first user interface that, upon execution on an electronic device, allows a user to register and add a payment account for performing secure payments. The payment application is further configured to enable a registered user to tokenize the payment account using a token issuance platform. The memory is configured to store a database having a first lookup table. The first lookup table comprises a list of identifiers associated with registered users and corresponding registration details for each registered user, where the registration details comprise personal information of the registered user and a token for the payment account and the payment account. The personal information is selected from the group consisting of name, mobile number, email address and identity verification information.The payment account is selected from the group consisting of bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, Card Verification Value (CVV), net banking login username, login credentials associated with the transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, any other transaction username or payment account token etc. The verification code generation module is configured to generate a first one-time verification code / PIN for the payment account or the token of the payment account based on each received payment request. The first one-time verification code / PIN can be a numeric code or an alpha code. The verification code generation module is further configured to store both in a second lookup table. The verification code generation module is also configured to send the first one-time verification code / PIN to the payment application and display it in the first user interface. The verification code verification module comprises a comparator, an extraction module and an authorization module. The comparator is configured to receive a second verification code / PIN input via a second user interface and match the second verification code / PIN retrieved from a second lookup table with the first one-time verification code / PIN. The extraction module is configured to extract a payment account or a stored payment account token in response to the input of the first one-time verification code / PIN. The extraction module is further configured to send the payment account data or token data to an acquiring bank or a payment gateway for authorization. The acquiring bank or the payment gateway further sends transaction details data to the payment application of the registered user. The authorization module is configured to send a payment request consisting of transaction details to the payment application of the registered user and the user confirms the transaction by swiping left or right or by biometric authentication or application PIN. The authorization module is configured to send a transaction verification status to the payment gateway or acquiring bank, which in turn sends the transaction to the issuing bank for authorization or the acquiring bank or payment gateway sends transaction details data to the issuing bank. Here, the issuing bank sends an OTP for the payment request to the registered user of the issuing bank to authorize the transaction. The registered user authorizes the transaction by entering the OTP at the payment gateway and the payment gateway or acquiring bank sends the transaction status to the authorization module. The notification module is configured to cooperate with the authorization module to receive a transaction authorized status at the payment application of the registered user, and the transaction data comprises a registered user identifier, at least one transaction identifier, a payment account of the registered user, a transaction amount, online / offline merchant or ATM details, or one or more registration details of a second registered user making the payment. Furthermore, the issuing bank verifies the transaction data received from the extraction module and generates and sends a one-time password to the bank registered user's electronic device to perform a secondary user authentication. The registered user can, for example, enter the password received by SMS or email on the electronic device into the payment gateway through the first user interface or the second user interface. The issuing bank then verifies that the password received from the bank registered user is the same as the generated password and authenticates the user. In one embodiment, the memory is implemented as a storage area on the payment server, or the memory is implemented as an independent storage device communicatively linked to the payment server. In one embodiment, the payment server comprises a registration module configured to receive registration details from a user via a first user interface and further configured to register the user by generating a unique identifier associated with the user and storing the registration details with the unique user identifier in a first lookup table. The registration module is configured to store the registration details in encrypted form using an encryption engine. The payment server further comprises a login module configured to allow a user to generate and configure login credentials via the first user interface, and further configured to allow the registered user to initiate a payment using the payment application after authenticating the registered user based on the login credentials, where the login credentials can be selected from the group consisting of a login username, a password, a preset PIN number, and a biometric signature of the registered user including at least one of a fingerprint, facial biometric data, an iris pattern, a retina pattern, a finger vein pattern, a palm vein pattern, and a voiceprint. In one embodiment, the transaction data comprises a registered user identifier, at least one transaction identifier, a payment account of the registered user, a transaction amount, online / offline merchant or ATM details, or one or more registration details of a second registered user making the payment. The notification module is configured to receive messages regarding the transaction status from the payment gateway or acquiring bank of the second registered user, and is further configured to notify the registered user and the second registered user regarding the transaction status via the first user interface and the second user interface, respectively. In one embodiment, the system enables users to securely conduct online, e-commerce, merchant point-of-sale, end-to-end (P2P), and automated teller machine (ATM) transactions. Additionally, the present invention provides a method for secure transaction processing. [Brief description of the drawings]

[0002] The secure transaction processing system and method of the present invention will be described with reference to the accompanying drawings, in which: FIG. 1 is a block diagram of a system for enhancing the convenience of secure transaction processing according to the present invention. 2A and 2B show a flow chart of a method for enabling secure transaction processing in accordance with the present invention. FIG. 3A is a block diagram of the system of FIG. 1 for processing secure transactions between customers and merchants in accordance with the present invention. FIG. 3B illustrates a block diagram of the system of FIG. 1 for processing person-to-person (P2P) transactions in accordance with the present invention. 4A-4J illustrate an example of customer flow through a merchant's website in accordance with an embodiment of the present invention. 5A-5G illustrate an example of customer flow through a merchant POS in accordance with an embodiment of the present invention. 6A-6J illustrate an example of a customer flow between terminals according to an embodiment of the present invention. 7A-7H illustrate an example of a customer's flow through an ATM in accordance with an embodiment of the present invention. Reference Number List 100 - System 10 / 50 - Electronic equipment 10a - First User Electronic Device 10b - Secondary User Electronic Devices 20 - Secondary User Interface 30 - Issuing Bank 40 - Acquiring Bank 60 – E-commerce websites 70 - Dealer Server 102 - Application 104 - Primary User Interface 104a - First User Application Interface 104b - Secondary user application interface 106 - Memory 108 - Payment Server 110 - Verification code generation module 112 - Verification code verification module 112a - Comparator 112b - Extraction module 112c - Permissions module 114 - Registration module 116 - Login Module 118 - Notification Module Detailed Description of the Invention An embodiment of the present invention will now be described with reference to the accompanying drawings. The embodiments described herein can allow a person skilled in the art to fully and completely grasp the scope of the present invention. Numerous details related to individual components and methods can be described to fully grasp the embodiments of the present invention. It is obvious to a person skilled in the art that the details described in the embodiments cannot be interpreted as limiting the scope of the present invention. In some embodiments, well-known processes, well-known device structures, and well-known techniques are not described in detail. In the present invention, the terms described are used only to describe certain embodiments and should not be construed as limiting the scope of the present invention. Nouns used in the present invention include plurals unless the context dictates that they should be treated as singular. Terms such as "comprises," "has," and "has" are inclusive transitional terms and thus define the presence of features, characteristics, integers, steps, operations, elements, or components described herein, but do not exclude the presence or addition of other features, integers, steps, operations, elements, components, or groups of components. The particular sequence of steps disclosed in the methods and processes of the present invention should not be construed as necessarily indicating that the performance described or illustrated is essential. It should also be understood that additional or alternative steps may be used. As used herein, the term "or" includes any combination of one or more of the associated listed members. Typically, point-of-sale or automated teller machine (ATM) payment systems require the use of credit / debit / prepaid cards to make financial transactions. Similarly, internet-based or e-commerce payment systems require financial related information (bank details, account details, debit card numbers, prepaid card numbers, credit card numbers, card expiration details, card verification value (CVV), online banking login usernames, financial services account related login credentials, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) usernames, PayPal usernames, Zelle usernames, and other transaction usernames) to make financial transactions. Internet-based transactions allow remote access to payment accounts to make payments without the need to visit a bank and use paper transactions. However, to make point-of-sale (POS) payments, ATM or e-commerce transactions, users are forced to insert their payment cards into the device or enter their payment account details in an application interface or on the merchant's website. Similarly, to make end-to-end online transactions using a particular service, users are required to enter their login username and sender and recipient account details in the service's application interface. Furthermore, users are required to enter financial information on any website or interface where they wish to carry out a transaction. Moreover, such websites / interfaces store part of their payment account details, such as card numbers, either directly or in the form of tokens, and to store card details in the file service as card tokens, users are forced to enter their full card details at least once on the website, where data theft and misuse may occur. This exposes users' financial data to merchants and third-party service providers, increasing the risk of fraudulent transactions. Moreover, internet based transactions have a major drawback in that sensitive information such as bank details, account details, debit card numbers, prepaid card numbers, credit card numbers, card expiry details, card verification values ​​(CVVs), net banking login usernames, login credentials associated with transaction accounts, Virtual Payment Addresses (VPAs) / Unified Payment Interface (UPI) usernames, PayPal usernames, Zelle usernames, and other transaction usernames are transmitted over the public internet, making such transmissions vulnerable to a wide variety of hacking attacks and abuses due to the disclosure of confidentiality of financial related information. To address the above-mentioned problems, the present invention provides a system (hereinafter "system 100") and a method (hereinafter "method 200") for enabling secure transaction processing. System 100 and method 200 will now be described with reference to Figures 1 through 4J. Referring to FIG. 1, the system 100 includes a payment application 102 (also known as “HydePay”). (TM)App”), memory 106, and a payment server 108 hosting the payment application 102 (aka “HydePay (TM) The payment application 102 may be a mobile application or a web application. The payment application 102 may be executed on an electronic device 10 such as a mobile phone, tablet, computer, laptop, or any other electronic device capable of processing data by accessing information in the server 108 and memory 106. The executed payment application 102 is configured to provide a first user interface 104 to enable users to register and add payment accounts to the payment server 108 for conducting secure payments. The payment application 102 is configured to enable registered users to tokenize payment accounts using the token issuance platform. In one embodiment, to allow the user to register, the payment application 102 is configured to request the user to enter registration details from the first user interface 104. The registration details consist of the user's personal details and payment account details. The personal details can be selected from the group consisting of but not limited to name, mobile number, email address, and identification information such as photo, permanent account number, date of birth, etc. The payment account details can be selected from bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, card verification value (CVV), online banking login username, login credentials associated with the transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and any other transaction username or token of the payment account. Upon receiving the registration details, the payment application 102 is configured to send the received details to the payment server 108. The memory 106 is configured to store a database having a first lookup table, the first lookup table being comprised of a list of registered users and user identifiers associated with corresponding registration items for each registered user, the registration items being comprised of personal information of the registered user, a payment account, and a token for the payment account. In one embodiment, the memory 106 is implemented as a storage area on the settlement server 108. Alternatively, the memory 106 is implemented as an independent storage device communicatively linked to the settlement server 108. A payment server 108 that hosts the payment application 102 The payment server 108 includes a verification code generation module 110 , a verification code verification module 112 , and a notification module 118 . The verification code generation module 110 is configured to generate a first one-time verification code / PIN for the payment account or a token for the payment account based on each received payment request and store both in a second lookup table. Further, the verification code generation module 110 is configured to send the first one-time verification code / PIN to the payment application 102 for display on the first user interface 104. The verification code verification module 112 includes a comparator 112a, an extraction module 112b, and an authorization module 112c. The comparator 112a is configured to receive the second verification code / PIN entered at the second user interface 20 and match the first one-time verification code / PIN with the second verification code / PIN from the second lookup table. The second user interface 20 can be a user interface of a payment application 102 running on a merchant's website or on the electronic device of another user (such as a second registered user / payee in the transaction). The extraction module 112b can extract the stored payment account or token upon input of the first one-time verification code / PIN, and is further configured to send the payment account data or token data to the acquiring bank 40 or payment gateway for authorization, and the acquiring bank 40 or payment gateway is further configured to send the transaction details data to the payment application 102 of the registered user. The authorization module 112c is configured to cooperate with the extraction module 112b to send a payment request consisting of transaction details to the payment application 102 of the registered user, when the user confirms the transaction by swiping left or right or by biometric authentication or application pin number, and further send a transaction verification status to the payment gateway or acquiring bank 40, which then sends the transaction to the issuing bank 30 for approval. Alternatively, the acquiring bank 40 or the payment gateway sends transaction details data to the issuing bank 30. Here, the issuing bank 30 sends a payment request OTP to authorize the transaction to the bank registered user. Here, the registered user authorizes the transaction by entering the OTP at the payment gateway, and the payment gateway or acquiring bank 40 sends a transaction status to the authorization module 112c. The notification module 118 is configured to cooperate with the authorization module 112c to receive an authorized status of a transaction at the payment application 102 of a registered user. In one embodiment, the personal information is selected from the group consisting of name, mobile phone number, email address, and identity verification information. In one embodiment, the payment account is selected from the group consisting of bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, card verification value (CVV), online banking login username, login credentials associated with a transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and other transaction usernames, or payment account tokens. In one embodiment, the payment server 108 allows a user to register with the server 108 as a customer or a merchant. In one embodiment, the payment server 108 is configured to maintain the customer registration details and the merchant registration details in different storage devices. In another embodiment, the payment server 108 is configured to maintain the customer registration details and the merchant registration details in the same storage device. The identifier generated for each registration detail is unique. In one embodiment, the identifier indicates: (i) whether the registered user is a customer, a merchant, or both; and (ii) the identity of the customer or merchant to which the registration details correspond. In one embodiment, the payment server 108 comprising a registration module 114 is configured to receive registration details from a user via the first user interface 104, and is further configured to register the user by generating a unique identifier associated with the user and storing the registration details with the unique user identifier in a first lookup table. In one embodiment, the registration module 114 is configured to store the registration details in an encrypted form using an encryption engine. The payment server 108 comprises a login module 116 configured to allow a user to generate and configure login credentials via the first user interface 104 and to allow the registered user to initiate a payment using the payment application 102 after authenticating the registered user based on the login credentials. In one embodiment, the login credentials can be selected from the group consisting of a login username, a password, a preset PIN, and a biometric signature of the registered user including at least one of a fingerprint, facial biometric data, an iris pattern, a retina pattern, a finger vein pattern, a palm vein pattern, and a voice print. For example, in one embodiment, the payment server 108 can enable the registered user to generate or set a login username and password and perform a secure login to the payment application 102 using the login username and password as the credentials. In another embodiment, the payment server 108 can perform the authentication (i.e., enable secure login) by verifying / validating a preset secure PIN entered by the registered user or by verifying the registered user's biometric data / signatures. In one embodiment, the transaction data comprises a registered user identifier, at least one transaction identifier, a payment account of the registered user, a transaction amount, online / offline merchant or ATM details, or one or more registration details of a second registered user making the payment. In one embodiment, the notification module 118 is configured to receive messages regarding the transaction status from the payment gateway or acquiring bank 40 of the second registered user, and is further configured to notify the registered user and the second registered user regarding the transaction status via the first user interface 104 and the second user interface 20, respectively. In one embodiment, the system enables users to securely conduct online, e-commerce, merchant point-of-sale, end-to-end (P2P), and automated teller machine (ATM) transactions. In one embodiment, the memory 106 cooperates with the payment server 108 to store a database having a first lookup table. The first lookup table comprises a list of registered users and user identifiers associated with corresponding registration details for each registered user. The registration details comprise personal information of the registered user, a payment account, and a payment account token. Furthermore, the issuing bank 30 may additionally perform a (secondary) user authentication after verifying the transaction data / payment account of the registered user. The acquiring bank 40 or the payment gateway sends the transaction details to the issuing bank 30. Here, the issuing bank 30 sends an OTP for the payment request to the bank registered user and authorizes the transaction. Here, the registered user authorizes the transaction by entering the OTP in the payment gateway. Thus, the primary authentication is enabled / performed by the payment server 108 and the secondary authentication is performed by the acquiring bank 40. Advantageously, the registration module 114, the login module 116, the verification code generation module 110, the verification code verification module 112, and the notification module 118 may be implemented using one or more processors of the settlement server 108. The processor may be a general purpose processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP), or similar processor. The processor may be configured to retrieve data from or write data to a memory. The memory may be, for example, a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a read only memory (ROM), a flash memory, a hard disk, a floppy disk, cloud storage, or the like. Further, the present invention discloses a method 200 for enabling secure transaction processing. Referring to Figures 2A and 2B, the method 200 comprises the steps of: At step 202 , the payment application 102 allows a user via a first user interface 104 to register and add a payment account for performing secure payments immediately upon execution on the electronic device 10 . At step 204, via the first user interface 104 of the payment application 102, a registered user is enabled to tokenize a payment account using the token issuance platform. At step 206, a database having a first lookup table is stored in the memory 106. The first lookup table comprises a list of identifiers associated with registered users and corresponding registration details for each registered user, the registration details comprising personal information, payment accounts and payment account tokens for the registered users. In step 208, a first one-time verification code / PIN is generated for the payment account or the payment account token by the verification code generation module 110 of the payment server 108 based on each received payment request, and both are stored in a second lookup table. In step 210 , a first one-time verification code / PIN is sent by the verification code generation module 110 of the payment server 108 to the payment application 102 and displayed on the first user interface 104 . At step 212 , the second verification code / PIN number entered through the second user interface 20 is received by the verification code validation module 112 of the payment server 108 . In step 214, the first one-time verification code / pin number is matched by comparator 112a of verification code validation module 112 against a second verification code / pin number from a second look-up table. In step 216, the payment account or stored token is extracted 216 by the extraction module 112b of the verification code validation module 112 in response to entering the first one-time verification code / PIN. The payment account data or token data is sent to the acquiring bank 40 or payment gateway for authorization by the extraction module 112b of the verification code validation module 112 at step 218. The acquiring bank 40 or payment gateway sends the transaction details to the payment application 102 of the registered user. At step 220, a payment request comprising transaction details is sent by the authorization module 112c of the verification code validation module 112 to the registered user's payment application 102, where the user confirms the transaction by swiping left or right or by biometric authentication or an application PIN. In step 222, once the transaction confirmation status is sent by the authorization module 112c of the verification code validation module 112 to the payment gateway or acquiring bank 40, the payment gateway or acquiring bank 40 sends the transaction to the issuing bank 30 for authorization. In step 224, the acquiring bank 40 or the payment gateway sends the transaction details to the issuing bank 30. Here, the issuing bank 30 sends a payment request OTP to the bank registered user for transaction authorization, the registered user authorizes the transaction by entering the OTP in the payment gateway, and the payment gateway or acquiring bank sends the transaction status to the authorization module. At step 226, the transaction authorized status is received by the notification module 118 at the payment application 102 of the registered user. In one embodiment, step 202 in which a user registers to enable secure payments via the first user interface 104 comprises the following process: the registration module 114 of the payment server 108 receiving registration details from the user via the first user interface 104; A registration module 114 registers the user by generating a unique identifier associated with the user and stores the registration details along with the unique identifier in a database. In one embodiment, the registration details are stored in encrypted form via an encryption engine. In one embodiment, the method 200 further comprises: Allowing the user to generate and configure login credentials via the first user interface 104 via the login module 116 of the payment server 108, and then The login module 116 authenticates the registered user based on the login credentials, and then allows the registered user to perform the payment using the first user interface 104, where the login credentials are selected from the group consisting of a login username and password, a preset PIN number, and a biometric signature of the registered user including at least one of a fingerprint, facial biometric data, an iris pattern, a retina pattern, a finger vein pattern, a palm vein pattern, and a voiceprint. Further, the method 200 comprises the steps of: The Registered User's issuing bank 30 receives the transaction data; The issuing bank 30 checks the received transaction data based on pre-stored customer data, The issuing bank 30 generates a first one-time password after verifying the transaction data; The issuing bank 30 transmits the generated first one-time password to the bank registered user's electronic device 10 for user authentication; · A bank registered user enters this into the payment gateway for authentication, the payment gateway sends the received second one-time password to the issuing bank 30; The issuing bank 30 validates the generated first one-time password against the second one-time password received from the payment gateway and authorises the transaction. In one embodiment, the method 200 comprises the steps of: The notification module 118 of the payment server 108 receives a message from the payment gateway / acquiring bank 40 of the second registered user regarding the transaction status, and the notification module 118 notifying the registered user and the second registered user about the transaction status via the first user interface 104 and the second user interface 20, respectively; 3A and 4A-4J, in one operational embodiment, a registered customer (a customer registered with the payment server 108) uses the payment application 102 to conduct secure transactions with registered merchants (merchants registered with the payment server 108). To enable secure online e-commerce transactions, the payment server 108 is communicatively linked via a communication means to a merchant server 70 of the registered merchant. An e-commerce website 60 is hosted on each merchant server 70. A registered customer logs into the retailer's e-commerce website 60 from an electronic device 50. The e-commerce website 60 provides the customer with an interface 20, where the customer places the items they wish to purchase in a shopping cart and clicks on "Confirm Order" as shown in FIG. 4A. This opens a confirmation page for the customer. As shown in FIG. 4B, this page allows the customer to select a payment method. The page shows "HydePay" as one of the payment options. (TM) The customer will be presented with the option to use HydePay. (TM) After selecting the payment method by clicking on the “Use HydePay” option, the customer is directed to the payment page shown in Figure 4C where they enter their unique verification code / PIN (i.e. “HydePay”). (TM) You will be asked to enter your password (also called your personal identification number / PIN). To get a unique verification code / PIN, the customer will need to enter their payment application / HydePay (TM) The customer opens the application 102. As shown in Figure 4D, the payment application 102 asks the customer to select a payment account to perform the transaction. Once the payment account is selected, the payment server 108 generates a one-time verification code / PIN for the card (i.e., a first one-time verification code / PIN) and displays the generated code / PIN via the interface 104 of the payment application 102, as shown in Figure 4E. The customer enters this verification code / PIN (i.e., a second verification code / PIN) into the payment page of the website interface 20, as shown in Figure 4F. In one embodiment, the user may also authenticate the transaction by swiping left or right on the desired application platform, or by entering an application verification code / PIN or application PIN, or using biometric authentication. In an alternative embodiment, referring to Fig. 4G, the issuing bank 30 performs additional authentication and then debits the customer account. Or the acquiring bank 40 / payment gateway sends transaction details to the issuing bank 30. Here, the issuing bank 30 sends an OTP for payment request to the bank registered user and authorizes the transaction as shown in Fig. 4H. As shown in Fig. 4I, the customer (registered user) authorizes the transaction by entering the OTP in the e-commerce website interface 20. The registered user authorizes the transaction by entering the OTP in the payment gateway. As shown in Fig. 4J, the payment gateway and the payment gateway or acquiring bank 40 sends the transaction status. Or the issuing bank 30 sends an SMS to the customer to inform the customer regarding the transaction status. 1 is a pseudocode example illustrating an embodiment of a method 200 for processing electronic commerce payments. Do Step A { The customer places the items they want in the shopping cart and clicks "Confirm Order" The customer chooses a payment method to make the transaction. "HydePay (TM) Click "Use my credit card" to choose your payment option, The customer logs into the payment application 102 by entering their secure login credentials; } If (Customer Login Successful == YES) Step B { Select a settlement account for executing transactions Generate Verification Code / PIN The customer enters the one-time password into the e-commerce website interface Click the "Pay" button } Else { Login Failed Go to step A } If (Customer Generated Verification Code / PIN == Verification Code / PIN Entered on E-commerce Website) Step C { Send a permission request asking the customer to swipe right or left to authorize the transaction or The issuing bank sends the OTP to the customer (registered user at the bank) for payment request and authorizes the transaction. Customer submits OTP from e-commerce website to authorize transaction } Else { Verification code / PIN code does not match Transaction declined Go to step B } According to another aspect of the present invention, and referring to Fig. 3B and Fig. 6A-6J, the system 100 is used for end-to-end (P2P) payment processing. In one operational embodiment, as shown in Fig. 6A, when a second user requests a payment of an amount "x" and sends the request to a first user, the first user logs into the payment application 102 by inputting secure login credentials, as shown in Fig. 6B. As shown in Fig. 6C, the payment application 102 provides a first user interface 104a that allows the first user to select a payment account to perform a transaction and generate a verification code / PIN for the transaction corresponding to the payment account. The first user sends the generated verification code / PIN to the second user via SMS, email, messaging service (e.g., Whatsapp), or other communication means, as shown in Fig. 6D, and the second user executes the payment application 102 on his / her device 10b to receive the payment. Once launched, the payment application 102 provides a second user interface 104b that allows the second registered user to log into the application 102 by inputting secure login credentials. As shown in FIG. 6E, the second registered user inputs the verification code / PIN received from the first user into the second user interface 104b of the payment application 102 and further inputs the amount "x". The second user also sends an authorization request for the requested amount "x" to the first user. The payment server 108 matches the verification code / PIN generated by the first user with the verification code / PIN received from the second user and authorizes the transaction if they match. After approval / success, the payment server 108 sends an authorization request to the payment application interface 104 of the first user, allowing the first user to authorize the transaction, as shown in FIG. 6F. The authorization can be performed using one or more of the above methods described herein. Alternatively, the acquiring bank 40 / payment gateway sends the transaction details to the issuing bank 30. Here, the issuing bank 30 sends an OTP for the payment request to the first user / bank registered user, as shown in FIG. 6G, and authorizes the transaction, as shown in FIG. 6H.As shown in Figures 6I and 6J, the first user enters the OTP into the payment gateway to authorize the transaction. 1 is a pseudocode example illustrating an embodiment of a method 200 for end-to-end (P2P) payment processing. Do Step A { A second user requests payment of an amount "x" and sends this request to the first user, a first or second user logs into the payment application 102 by entering secure login credentials; } If (First User Login Successful == YES) Step B { Select a settlement account for executing transactions Generate a verification code / PIN for a transaction The first user sends the generated verification code / PIN to the second user } Else { Login Failed Go to step A } If (Second User Login Successful == YES) Step C { The second registered user enters the verification code / PIN received from the first user The second user enters an amount "x" The second user sends a request to the first user to grant the requested amount "x" } Else { Login Failed Go to step A } If (First user receives a request from second user) { The first user swipes right or left to authorize the transaction. or The issuing bank sends a payment request OTP to the first user (user registered with the bank) to authorize the transaction First user sends OTP to the payment gateway to authorize the transaction } Else { Transaction declined } In accordance with yet another embodiment, and referring to Figures 5A-5G, the system 100 is used to process transactions at a retail store. In one operational example, HydePay (TM) A customer who wishes to pay a vendor an amount "x" using the app / payment application 102 logs into the application 102 by entering secure login credentials. The vendor generates an invoice for the goods purchased by the customer and requests the customer to pay, as shown in FIG. 5A. The customer then selects a payment account to perform the transaction and generates a transaction verification code / PIN corresponding to the payment account, as shown in FIG. 5B and 5C. The customer then presents the verification code / PIN to the vendor. To receive the payment, the vendor logs into the payment application 102 by entering secure login credentials. The vendor then inputs the verification code / PIN presented by the customer into the input interface 104 of the payment application 102 and inputs the amount "x", as shown in FIG. 5C. The payment server 108 matches the customer generated verification code / PIN with the verification code / PIN received from the merchant and authorizes the transaction if there is a match. After approval / success, the payment server 108 sends an authorization request to the customer's payment application interface 104 to allow the customer to authorize the transaction, as shown in FIG. 5D and FIG. 5E. Authorization can be performed using one or more of the methods described herein above, or as shown in Figure 5F, the acquiring bank 40 or payment gateway sends transaction details to the issuing bank 30. The issuing bank (30) then sends an OTP for the payment request to the customer (registered user of the bank) to authorize the transaction, as shown in Figure 5G. The customer (registered user) then enters the OTP into the vendor's payment gateway to authorize the transaction. 1 is a pseudocode example illustrating an embodiment of a method 200 for retail store transactions. Do Step A { The vendor generates an invoice and a request for a verification code / PIN, The customer logs into the payment application 102 by entering their secure login credentials; } If (Customer Login Successful == YES) Step B { Generate Verification Code / PIN The customer then presents the verification code / PIN to the vendor, } Else { Login Failed Go to step A } If (Vendor Login Successful == YES) Step C { Enter the verification code / PIN provided by the customer, Enter the amount "x" } Else { Login Failed Go to step A } While the customer is receiving a payment request from the merchant { sending an authorization request to the customer's payment application interface 104, where the customer swipes right or left or right to authorize the transaction; or The issuing bank sends the OTP to the customer (registered user at the bank) to authorize the transaction. The customer (registered user) authorizes the transaction by entering the OTP into the vendor's payment gateway. } In one embodiment, the payment of the desired amount can be made using a Hydepin, where the Hydepin must be entered into the ATM screen to select or enter the amount to be debited. In accordance with another embodiment of the present invention, and referring to Figures 7A-7H, a system 100 is used to process transactions associated with an automated teller machine (ATM). A settlement server 108 is communicatively linked to the ATM processing system and provides a payment application / HydePay (TM) In one operational embodiment, as shown in FIG. (TM) A registered user who wishes to withdraw an amount "x" from an ATM using the app / payment application 102 may enter "HydePay (TM)The user selects the "Withdraw via" option on the ATM screen. Once this option is selected, the ATM screen immediately prompts the user to enter a verification code / PIN for the withdrawal, as shown in FIG. 7B. To obtain the verification code / PIN, the user logs into the payment application 102 by entering the secure login credentials. Next, as shown in FIG. 7C and FIG. 7D, the logged in user selects a payment account for performing the transaction and generates a verification code / PIN for the withdrawal transaction corresponding to the payment account. Next, the user enters the verification code / PIN on the ATM screen as indicated by the verification code / PIN. As shown in FIG. 7F and FIG. 7G, the user enters the transaction amount "x" on the ATM screen and enters the verification code / PIN. As shown in FIG. 7H, the settlement server 108 verifies the verification code / PIN generated by the user on the payment application 102 with the verification code / PIN received from the user via the ATM screen, and if they match, authorizes the transaction. After approval / success, the settlement server 108 sends an authorization request to the customer's payment application interface 104 to allow the customer's transaction authorization. Authorization can be performed using one or more of the methods described herein above. Alternatively, the acquiring bank 40 or payment gateway sends transaction details to the issuing bank 30. The issuing bank 30 then sends the customer (registered user of the bank) an OTP for the payment request to authorize the transaction. The customer (registered user) then authorizes the transaction by entering the OTP on the ATM screen. Pseudocode example illustrating an embodiment of a method 200 for processing in an automated teller machine (ATM) Do Step A { The customer logs into the payment application 102 by entering their secure login credentials; } If (Customer Login Successful == YES) Step B { On the ATM screen, select "HydePay (TM) Select the "Withdraw using" option Generate a verification code / PIN The customer enters the amount to be withdrawn ("x") on the ATM screen, Enter your withdrawal verification code / PIN on the ATM screen } Else { Login Failed Go to step A } If (Customer generated verification code / PIN == Verification code / PIN received from ATM screen) Step C { If it matches, the transaction is allowed } Else { Verification code / PIN code does not match Transaction Failed / Rejected Go to step B } While (Customer has received the payment request) Step D { sending an authorization request to the customer's payment application interface 104, where the customer swipes right or left or right to authorize the transaction; or The issuing bank sends the OTP to the customer (registered user at the bank) to authorize the transaction. The customer (registered user) authorizes the transaction by entering the OTP on the ATM screen. } In accordance with another aspect of the present invention, the system 100 is used to process transactions at a brick-and-mortar retail store using a POS system. (TM) In some cases, the user may not have the app 102 or may not know how to use the payment application 102. In this case, the user may need to use a payment card (such as "HydePay") to receive payments from customers. (TM) In one operational embodiment, a HydePay card is issued to a merchant. (TM)A registered customer who wishes to make a payment of "x" amount to a merchant using the app / payment application 102 logs into the payment application 102 by entering secure login credentials. The customer then selects a payment account through which to make the transaction and generates a transaction verification code / PIN corresponding to the payment account. The customer presents the verification code / PIN to the merchant. To receive the payment, the merchant accepts the payment via HydePay. (TM) Insert the card into the point-of-sale terminal (POS). The POS terminal is HydePay. (TM) The card is recognized and a verification code / PIN is requested from the merchant, and the merchant enters the amount "x". The merchant then enters the verification code / PIN provided by the customer and enters the amount "x" into the interface of the POS terminal. The POS terminal then sends the received verification code / PIN to the payment server 108, either directly or via the merchant / acquiring agent's server. The payment server 108 checks the customer generated verification code / PIN with the verification code / PIN received from the merchant and authorizes the transaction if the two codes / PINs match. After authorization / successful verification, the payment server 108 sends a payment request consisting of transaction details to the registered user's payment application 102, where the user confirms the transaction by swiping left or right or with biometric authentication or the application's PIN, or the acquiring bank 40 / payment gateway sends the transaction details to the issuing bank 30. The issuing bank 30 then sends an OTP for the payment request to the bank registered user and authorizes the transaction. Here, once a registered user authorizes the transaction by entering an OTP into the POS interface, the payment gateway or acquiring bank 40 sends the transaction status to the authorization module 112c. Further, in accordance with another aspect of the present invention, the system 100 is used to store card details data in an online platform in accordance with the rules and regulations declared by the competent authorities of a designated country and to tokenize the same for transactions. 1 is a pseudocode example illustrating an embodiment of a method 200 for processing at a traditional retail point of sale having a POS system. Do Step A { The customer logs into the payment application 102 by entering their secure login credentials; } If (Customer Login Successful == YES) Step B { Select a payment account, Generate Verification Code / PIN The customer presents the verification code / PIN to the dealer, } Else { Login Failed Go to step A } Do Step C { HydePay (TM) Insert the card into the point-of-sale (POS) terminal. } If (HydePay (TM) Card == Valid and Accepted) Step D { Prompt the retailer to enter the verification code / PIN, Next, the retailer enters the verification code / PIN provided by the customer, enters the amount "x", } Else { HydePay (TM) If the card is invalid Verification code / PIN code does not match Transaction Failed / Rejected GOTO STEP C; } If (Customer Generated Verification Code / PIN == Merchant Received Verification Code / PIN) Step E { Send a permission request asking the customer to swipe right or left to authorize the transaction or The issuing bank sends the OTP to the customer (registered user at the bank) for payment request and authorizes the transaction. Customer sends OTP to POS interface to authorize transaction } Else { Verification code / PIN code does not match Transaction Failed / Rejected GOTO STEP D; } The system 100 enables customers to make online, e-commerce, merchant point of sale, and ATM transactions without disclosing any payment account details such as bank details, account details, debit card numbers, prepaid card numbers, credit card numbers, card expiry details, card verification value (CVV), online banking login username, login credentials associated with transaction accounts, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and other transaction usernames to any third party service, any application interface, or any merchant (e.g., via an e-commerce website) at any time during the transaction. When using the system 100 for transactions with merchants, the customer only needs to disclose the verification code / PIN (HydeCode / PIN) to the merchant. In other words, the customer can use the HydePay (TM) The app allows payment accounts to be hidden from merchants, and instead, customers enter a one-time HydeCode on the merchant's website. (TM) / You only need to enter your PIN. Also, the payment application 102 (i.e., HydePay (TM) The App) enables registered customers to securely tokenize their payment accounts, store the tokens in a secondary lookup table and dynamically generate unique verification codes / PINs (i.e. HydeCodes / PINs) to perform end-to-end (P2P), buyer-to-merchant (P2M) or ATM transactions, ensuring fail-safe security and reducing the risk of fraud in payments. In one embodiment, the system 100 may be integrated with any localized and internationalized application, mobile wallet, or payment application. Communication means as described herein refers to any means for transmitting and receiving binary data. For example, communication means may include the Internet, World Wide Web, Intranet, cable (including fiber optic cable), magnetic communication, electromagnetic communication (RF, microwave, infrared communication), and electronic communication. Wireless communication means may include any number of wireless network protocols and technologies, such as Near Field Communication (NFC), WiFi, Bluetooth, 4G LTE (Long Term Evolution), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), and others. The functionality described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented as software executed by a processor, the functionality may be stored on or transmitted via one or more commands or codes on a computer readable medium. Other embodiments are within the scope and spirit of the present invention and the appended claims. For example, depending on the nature of the software, the functionality described above may be implemented using software executed by a processor, hardware, firmware, wired connections, or any combination thereof. Nodes implementing functionality may be physically located in various locations, including being distributed such that some of the functionality is implemented in different physical locations. The above description of the embodiments is for illustrative purposes only and is not intended to limit the scope of the present invention to the scope of the description alone. Individual components of a particular embodiment are generally not limited to that particular embodiment and may be interchanged. Such variations cannot be considered as distinct from the present invention, and all such variations are considered to be within the scope of the present invention. Technological advances The invention described herein has the advantage, without being limited thereto, of realizing the following: a secure transaction processing system and method, which: does not require the User to enter any payment account details (bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, Card Verification Value (CVV), net banking login username, login credentials associated with a transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username and any other transaction username) to execute the transaction; Providing users with a secure and convenient way to carry out online or offline or end-to-end transactions; Allowing users to make online or offline transactions at point-of-sale terminals (POS) or automated teller machines (ATM) without using a payment account; Reduce your exposure to hacking attacks; Prevent unauthorized payments; · High probability of successful payment, · Providing convenient payment methods; Provide an easy-to-use payment interface; · Providing a secure payment interface to allow easy and instant payments. The details of the embodiments of the present invention and various features and advantages are described below by referring to non-limiting examples. Descriptions of well-established existing components and processing techniques are omitted so as not to unnecessarily complicate the understanding of the embodiments of the present invention. The examples used in the present invention are intended only to facilitate the understanding of how the embodiments of the present invention can be put into practice and to enable those skilled in the art to practice the embodiments of the present invention. Therefore, the examples should not be construed as limiting the scope of the embodiments of the present invention. The above description of the specific embodiments sufficiently reveals the general nature of the embodiments of the present invention, so that by applying current knowledge, the specific embodiments can be modified or adapted for different applications without departing from the general concept, and therefore, the adaptation / modification should and is intended to be understood in the sense and scope of equivalents to the embodiments of the present invention. The usage of phrases and terms used in this specification are for illustrative purposes and not for limiting purposes. Therefore, the embodiments described in this specification are described based on preferred embodiments, and at the same time, it is recognized that those skilled in the art can practice the embodiments described in this specification even if they are modified within the spirit and scope of the embodiments described in this specification. The use of the phrase "at least" or "at least one" suggests the use of one or more elements or components or quantities, according to which one or more may be used in embodiments of the invention to achieve one or more desired substances or results. Although considerable emphasis has been placed on the different components and component parts of the preferred embodiment, many embodiments are possible, and many changes can be made to the preferred embodiment without departing from the principles of the invention. It is apparent to those skilled in the art that the present invention or the characteristics of the preferred embodiment as well as other embodiments can be modified, and it should be clearly understood that the above description is merely for the purpose of illustrating the present invention and should not be construed as limiting.

Claims

1. A system (100) that enables secure transaction processing. Said system (100) comprises the following items: A payment application (102) configured, upon execution on the electronic device (10), to display a first user interface (104) and to allow a user to register and add a payment account to effect secure payments. Further, the payment application (102) is configured to enable registered users to tokenize the payment account using a tokenization platform; a memory 106 configured to store a database having a first look-up table, the first look-up table consisting of a list of user identifiers associated with registered users and corresponding registration details for each registered user, the registration details consisting of personal details of the registered user, a payment account and a token for said payment account. - A payment server (108) hosting said payment application (102). The payment server (108) consists of the following components: a verification code generation module (110) configured to generate a first one-time verification code / PIN for said payment account or said token of a payment account based on each received payment request and to store both in a second lookup table, and further configured for said verification code generation module (110) to send said first one-time verification code / PIN to said payment application (102) and to display it in said first user interface (104), and further configured for A verification code confirmation module (112) consisting of the following items: a comparator (112a) configured to receive a second verification code / pin number entered from a second user interface (20) and to match said first one-time verification code / pin number with said second verification code / pin number obtained from said second look-up table; an extraction module (112b) configured to extract said payment account or said token in response to entry of a first one-time verification code / PIN and to send said payment account data or token data to an acquiring bank (40) or a payment gateway for authorization, said acquiring bank (40) or said payment gateway further configured to send transaction details data to said payment application (102) of the registered user; an authorization module (112c) configured in cooperation with said extraction module (112b) to send a payment request comprising transaction details to said payment application (102) of a registered user, to confirm the transaction by a user swiping left or right or with biometric authentication or an application PIN, and to send a transaction verification status to said payment gateway or said acquiring bank (40), which in turn transmits said transaction to an issuing bank (30) for authorization; or said acquiring bank (40) or payment gateway sends transaction details to said issuing bank (30), whereby said issuing bank (30) authorizes the transaction by sending an OTP to a registered user of the bank for payment request, whereby when said registered user authorizes the transaction by entering the OTP into the payment gateway, said payment gateway or acquiring bank (40) sends a transaction status to said authorization module (112c); - A notification module (118) configured to cooperate with said authorization module (112c) to receive said transaction authorized status at said payment application (102) of a registered user.

2. A system (100) as claimed in claim 1. Here, the memory (106) is implemented as a storage area on the settlement server (108) or an independent storage device communicatively linked to the settlement server (108).

3. A system (100) as claimed in claim 1. Here, the personal information is selected from the group consisting of name, mobile phone number, email address, and identity verification information.

4. A system (100) as claimed in claim 1. wherein said payment account is selected from the group consisting of bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, Card Verification Value (CVV), net banking login username, login credentials associated with a transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and any other transaction username or payment account token.

5. A system (100) as claimed in claim 1, wherein said payment server (108) comprises a registration module (114) configured to receive said registration details from a user via said first user interface (104), and further configured to register the user by generating a unique identifier associated with the user and storing the registration details in said first lookup table with said unique user identifier.

6. A system (100) as claimed in claim 5, wherein said registration module (114) is configured to store registration details in encrypted form using an encryption engine.

7. The system (100) of claim 1, wherein said payment server (108) further comprises a login module (116) configured to enable a user to generate and configure login credentials via said first user interface (104), and configured to authenticate a registered user based on said login credentials to enable the registered user to initiate said payment using said application (102).

8. A system (100) as claimed in claim 7. Here, the login credentials are selected from the group consisting of a login user name and password, a preset PIN number, and a biometric signature of a registered user including at least one of a fingerprint, facial biometric data, an iris pattern, a retina pattern, a finger vein pattern, a palm vein pattern, and a voiceprint.

9. A system (100) as claimed in claim 1. Here, the transaction data comprises a registered user identifier, at least one of a transaction identifier, a payment account of the registered user, a transaction amount, online / offline merchant or ATM details or one or more registration details of a second registered user with whom the payment is made.

10. A system (100) as claimed in claim 1. and a notification module (118) configured to receive messages regarding the transaction status from the payment gateway or the acquiring bank (40) of the second registered user, and further configured to notify the registered user and the second registered user via the first user interface (104) and the second user interface (20), respectively, regarding the transaction status.

11. A system (100) as claimed in any one of claims 1 to 10. Herein, the said system enables users to securely perform online transactions, e-commerce transactions, point-of-sale, end-to-end (P2P) and automated teller machine (ATM) transactions.

12. A method (200) for enabling secure transaction processing. The method (200) comprises the following steps: - allowing a user to register and add a payment account via a first user interface (104) of the payment application (102) and perform secure payments immediately (202) when executed on the electronic device (10); enabling (204) registered users via the first user interface (104) of the payment application (102) to tokenize (204) the payment account using a tokenization platform; storing (206) in the memory (106) a database having a first lookup table, where the first lookup table comprises a list of identifiers associated with registered users and corresponding registration details for each registered user, where the registration details comprise personal information and payment accounts of the registered users and tokens for said payment accounts; generating (208) a first one-time verification code / PIN for said payment account or said payment account token by said verification code generation module (110) of the payment server (108) based on each received payment request and storing both in a second lookup table; the verification code generation module (110) of the payment server (108) sends (210) the first one-time verification code / PIN to the payment application (102) and displays it on the first user interface (104); a verification code verification module (112) of said payment server (108) receives (212) the second verification code / PIN number entered through the second user interface (20); a comparator (112a) of said verification code verification module (112) compares (214) said first one-time verification code / PIN with said second verification code / PIN from said second look-up table; an extraction module (112b) of the verification code verification module (112) extracts (216) the payment account or the stored token in response to the input of the first one-time verification code / PIN; the extraction module (112b) of the verification code validation module (112) sends (218) the payment account data or token data to the acquiring bank (40) or payment gateway, and, with authorization, the acquiring bank (40) or the payment gateway sends transaction details to the payment application (102) of the registered user; a payment request consisting of transaction details is sent (220) by the authorization module (112c) of said verification code validation module (112) to said payment application (102) of the registered user, the user confirming the transaction by swiping left or right or by biometric authentication or application PIN code, the authorization module (112c) of said verification code verification module (112) sends (222) the transaction verification status to said payment gateway or said acquiring bank (40), which in turn sends said transaction to said issuing bank (30) for authorization, The acquiring bank (40) or payment gateway sends (224) the details to the issuing bank (30), whereby the issuing bank (30) sends a payment request OTP to the bank's registered user to authorize the transaction, the registered user authorizes the transaction by entering the OTP in the payment gateway, the payment gateway or acquiring bank sends the transaction status to the authorization module, and The notification module (118) receives (226) the authorized status of the transaction to the registered user's payment application (102).

13. The method (200) as claimed in claim 12. Here, the personal information is selected from the group consisting of name, mobile phone number, email address, and identity verification information.

14. The method (200) as claimed in claim 12. wherein said payment account is selected from the group consisting of bank details, account details, debit card number, prepaid card number, credit card number, card expiry details, Card Verification Value (CVV), net banking login username, login credentials associated with a transaction account, Virtual Payment Address (VPA) / Unified Payment Interface (UPI) username, PayPal username, Zelle username, and any other transaction username or payment account token.

15. A method (200) as claimed in claim 12, wherein the step (202) of enabling a user to register and perform secure payments via said first user interface (104) comprises the steps of: a registration module (114) of said payment server (108) receiving registration details from a user via said first user interface (104); The registration module (114) registers the user by generating a unique identifier associated with the user and stores registration details per said unique user identifier in the first lookup table.

16. The method (200) as claimed in claim 12. Here, said registration details are stored in encrypted form via an encryption engine.

17. The method (200) as claimed in claim 12. The method further comprises the steps of: a login module (116) of said payment server (108) allowing a user to generate and configure login credentials via said first user interface (104); The registered user is authenticated by the login module (116) based on the login credentials, and then the registered user is allowed to initiate the payment using the first user interface (104), where the login credentials are selected from the group consisting of a login username and password, a pre-defined PIN number, and a biometric signature of the registered user including at least one of a fingerprint, facial biometric data, an iris pattern, a retina pattern, a finger vein pattern, a palm vein pattern, and a voiceprint.

18. The method (200) as claimed in claim 12. The method further comprises the steps of: the registered user's issuing bank (30) receives said transaction data; the issuing bank (30) verifies the received transaction data based on pre-stored customer data; The issuing bank (30) generates a first one-time password after verifying the transaction data, The issuing bank (30) transmits the generated first one-time password to the bank registered user's electronic device (10) for user authentication; - A registered user of the bank enters this into the payment gateway for authentication, the payment gateway sends the received second one-time password to the issuing bank (30); The issuing bank (30) checks the generated first one-time password against the second one-time password received from the payment gateway and authorises the transaction.

19. The method further comprises the steps of: the notification module (118) of said payment server (108) receiving a message from the payment gateway / acquiring bank (40) of the second registered user regarding the transaction status; the notification module (118) notifying the registered user and the second registered user regarding the transaction status via the first user interface (104) and the second user interface (20), respectively;

20. The method (200) as claimed in claim 12. Here, the transaction data comprises at least one of a transaction identifier, a payment account of the registered user, a transaction amount, and one or more personal information of the second registered user making the payment.

Images