HK40002615A - An electronic payment system and method thereof - Google Patents

Description

Electronic payment system and method thereof

Technical Field

The present invention relates to electronic payment systems.

Definition of

The term "registered user" as used in the following specification refers to a person performing an electronic payment transaction using the Electronic Payment System (EPS) of the present invention. The registered user may be a payer, i.e., a person who sends/pays money using the EPS, or a payee, i.e., a person who receives/collects money using the EPS.

The term "user device" as used in the following specification refers to a device used by a registered user, including but not limited to a cell phone, laptop, tablet, iPad, PDA, laptop, netbook, smart device, smart phone, personal computer, handheld device, etc.

The term "payment transaction" as used in the following specification refers to financial and non-financial transactions. The financial transaction includes a collect/pull request, a pay/push request, and merchant payments. Non-financial transactions include, but are not limited to, mobile banking registrations, generating one-time passwords (OTP), checking balances, setting or changing PINs, placing complaints, and checking transaction status.

The term "Payment Service Provider System (PSPS)" as used in the following specification refers to a bank, payment bank, or any other central and/or governmental regulatory entity that can acquire and provide payment (credit/debit) services to customers (individuals or entities). The PSPS provides corresponding application tools for registered users to access on their user devices to push or pull payment requests. PSPS provides electronic processing tools for financial and non-financial transactions

The term "sender" as used in the following specification refers to a registered user who sends a payment/push or receipt/pull request using the user device of the present invention. The sender may be a payer or a payee.

The term "recipient" as used in the following specification refers to a registered user who receives a collect/pull or pay/push money request on a user device using the user device of the present invention. The recipient may be a payer or a payee.

The term "unique ID" or "Virtual Payment Address (VPA)" as used in the following specification refers to a unique identifier associated with a registered user. The unique ID or Virtual Payment Address (VPA) is used to perform a payment transaction. The registered user may create a unique ID for the payment transaction.

The term "Unified Payment Interface (UPI)" as used in the following specification refers to an interface system that provides interaction between PSPS for financial and non-financial transactions, including payment transactions and payment settlement.

The term "Payment Service Provider Application (PSPA)" used in the following specification refers to an application tool provided by each PSPS. The PSPA tool may be provided on a Web portal or application store and/or cell phone Web or by other means, interacting with the PSPS through UPI.

The term "user information data" as used in the following specification refers to registered user related data, including the VPA, account details and other non-financial details of the registered user. The user information data is used to verify the identity of the registered user.

The above definitions are complementary to the prior art definitions.

Background

In recent years, more and more financial transactions have been performed by handheld devices (i.e., functional phones and smartphones). There are a number of payment techniques currently available using handheld devices. These payment techniques require knowledge of the payer's account and other bank related information of the payer. When paying online, the payer must access his bank Web portal by means of internet banking or cell phone banking to perform financial transactions. To date, many users are still dissatisfied with online financial/electronic transactions because the banking Web portal including internet banking or mobile banking is not user-friendly or is complicated to operate, and takes time for data input and authorization.

In some cases, payment is also made using the payee's cell phone number. However, in such techniques, the payer must know the payee's bank details and/or the cell phone number, since the cell phone bank is based on the SIM card number. In all such transactions, the payer pushes the payment to the payee. The payee relies entirely on the payer for the transaction, and the payer relies on his bank Web portal for the payment service. Some users may change cell phones/phone numbers frequently, in which case it is difficult for the payer to track such changes. Further, in some cases, the payer and the payee do not want to disclose bank details and personal details to each other.

Accordingly, there is a need for an efficient control of the above-mentioned deficiencies and for a system and method for performing electronic payment transactions that is efficient, simplified and user friendly.

Object of the Invention

The related objects of the present invention are as follows, and are satisfied by at least one of the following embodiments:

it is an object of the present invention to ameliorate one or more of the problems of the prior art or at least provide a useful alternative.

It is an object of the present invention to provide an electronic payment system that is easy to use.

It is another object of the present invention to provide an electronic payment system with a Unified Payment Interface (UPI).

It is another object of the present invention to provide an electronic payment system that allows a user to pull/collect payment from an associated individual/entity after the requesting entity authorizes the payment.

It is another object of the present invention to simplify an electronic payment system for payers and payees by reducing authorization steps and adding security functions.

It is another object of the present invention to provide an electronic payment system that enables a payment transaction between a payer and a payee without mandatorily requiring the provision of bank information and bank account details of the parties.

Further, it is an object of the present invention to provide an electronic payment system allowing a user to send and receive money by means of a virtual payment address.

Another object of the present invention is to provide an electronic payment system that eliminates the user's reliance on the Web portal or cell phone application of the internet bank or cell phone bank in which the user is used, and allows the user to conduct payment transactions using other bank Web portals and/or cell phone applications than the bank in which the user is account.

Other objects and advantages of the present invention will become more apparent from the following description, which is not to be construed as limiting the scope of the invention.

Disclosure of Invention

An Electronic Payment System (EPS) and a method are designed to facilitate payment transactions among multiple users. The system includes a primary storage device, an operations processor configured for user registration and further configured for EPS registration, a plurality of Payment Service Provider Systems (PSPS), a plurality of user devices, a payment service provider application tool (PSPA), and a Unified Payment Interface (UPI). The main memory device stores a set of predetermined rules for use by the operation processor in obtaining a set of system operation commands. Each PSPS includes a local storage device for storing information data relating to registered users of the PSPS, at least one look-up table for matching customer entered data, user information data and registered users, and a PSPS server. Each user device of the plurality of user devices is associated with a registered user and registered as part of the user information data. Each PSPA tool is associated with and hosted on a PSPS server of a PSPS registered to the EPS, and has elements that can be downloaded and stored on the user equipment of the registered user, independent of whether the registered user registers the PSPS associated with the PSPA tool. Each PSPS tool will facilitate the generation and receipt of transaction data signals relating to the registered user's payment request, and the crediting and/or debiting of accounts based on the requested registered user. The downloadable elements of each PSPA tool include a registration module and a Virtual Payment Address (VPA) creator module. The registration module allows the use of PSPA tool-related, registered user equipment of the registered PSPS in one-to-one communication. The VPA creator module allows a registered user to create a unique VPA containing the PSPS identity information registered by the registered user and also allows the user device to transfer the unique VPA to the local storage device of the PSPS in which the user is registered as part of the user information data of the registered user. The UPI facilitates registration of the PSPS in the EPS and also facilitates selectively controllable movement of transaction data signals between the PSPS to effect payment from one registered user to another registered user in the same or a different PSPS. The UPI includes a settlement module that cooperates with the plurality of PSPS to periodically check credit and debit transactions to generate net credit and debit instructions between the registered PSPS.

Brief description of the drawings

The electronic payment system and method of the present invention will now be described with the aid of the accompanying drawings, in which:

FIG. 1 is a schematic block diagram of an Electronic Payment System (EPS) in accordance with an embodiment of the present invention;

FIG. 2A illustrates a transaction flow between persons using EPS, according to the embodiment of FIG. 1;

FIG. 2B illustrates another transaction flow between persons using EPS, according to the embodiment of FIG. 1;

FIG. 3 illustrates, with the EPS of FIG. 2A, a flow of a payment transaction performed at the time of payment receipt;

fig. 4 illustrates, with the EPS of fig. 2B, a payment transaction flow performed upon direct payment;

fig. 5 illustrates a payment transaction flow between a taxi driver and its passenger with the EPS of fig. 1;

FIG. 6 illustrates the flow of a remittance payment transaction with the EPS of FIG. 1;

FIG. 7 illustrates a three-party "merchant transaction" flow between a customer and a merchant using the same PSPS, in accordance with the embodiment of FIG. 1;

fig. 8A, 8B, 8C, 8D and 8E are different screen display information for registered user equipment using the PSPA tool of the EPS of fig. 1.

List of reference numbers and detailed information used in description and drawings：

Detailed Description

The invention will now be illustrated by means of the accompanying drawings, which are not to be construed as limiting the scope and ambit of the invention. Are illustrated purely by way of example and in schematic form.

Several years ago, bank account holders were only able to use their debit/ATM cards for money transactions at the account holder's bank's authorized ATM machine. With the increasing demands of bank users, trusts and customers, a new model is designed to expand the use range of ATMs and allow bank account holders to use any ATM operated by a bank. Now, one can use any ATM in the world, no matter which bank it belongs to. This enables versatility and mutual portability of various network operations between the bank ATM and debit/ATM cards, and transaction processing and fund settlement between transaction parties.

The present invention is directed to addressing the interoperability of banking phone applications and/or banking Web portals for payment transactions. With the system of the present invention, users and/or bank customers will no longer be restricted to using the Web portal and/or cell phone Web of the bank where their account is located. The user (payer and payee) and/or customer can select any bank's Web portal or cell phone Web to conduct payment transactions without knowing the bank account details of the other party. The user (payer or payee) can conduct a financial/electronic payment transaction by knowing only the unique ID or Virtual Payment Address (VPA).

Referring to the drawings, FIG. 1 is a schematic block diagram of an electronic payment system (1000) (hereinafter EPS) that facilitates payment transactions among a plurality of users. Payment transactions include financial transactions including collect/pull requests, payment/push requests, and merchant payments, as well as non-financial transactions including mobile banking registrations, generating one-time passwords (OTP), setting or changing PINs, checking transaction status, making complaints, and the like.

The EPS (1000) includes a primary storage device (1002a), an operations processor (1002b), a plurality of Payment Service Provider Systems (PSPS), a plurality of user devices, Payment Service Provider Application (PSPA) tools, and a Unified Payment Interface (UPI) (100).

The master storage device (1002a) is configured to store a set of predetermined rules. The primary storage device (1002a) may comprise any computer-readable medium known in the art, including volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM), and/or non-volatile memory, such as Read Only Memory (ROM), erasable programmable ROM, flash memory, hard disks, optical disks, and magnetic tape, and/or cloud-based storage (cloud storage). In one embodiment, the primary storage device (1002a) is configured to store predetermined rules associated with electronic payment transactions, transmitting and receiving payment requests, and the like.

The operations processor (1002b) is configured to receive and process the pre-determined rules in coordination with the primary storage device (1002a) to obtain a set of system operation commands. The operations processor (1002b) may operate as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and/or any devices that perform signal operations in accordance with operational instructions. In other functional aspects, the operations processor (1002b) is configured to retrieve and execute a predetermined set of rules stored in the primary storage device (1002a) to control the EPS 1000 module.

A plurality of Payment Service Provider Systems (PSPS) are registered with the EPS (1000) and configured to register users. Each PSPS (1004) includes a local storage device (1004a), at least one look-up table (1004b), and a PSPS server (1004 c). The local storage device (1004a) stores relevant user information data of the registered user of the PSPS (1004). In one embodiment, the user data includes a Virtual Payment Address (VPA), account details, and other non-financial details of the registered user to facilitate verifying the identity of the registered user. At least one look-up table (1004b) facilitates matching customer entered data, user information data and registered users.

A plurality of user devices (1006), each associated with a registered user and registered as part of the user information data. Each registered user uses a registered user device to generate transaction data signals associated with a payment request via the PSPA tool.

Each PSPA tool (1008) is associated with and hosted on a PSPS server (1004c) of a PSPS (1004) of the registered EPS (1000) and has elements that can be downloaded and stored on the user equipment (1006) of the registered user, independent of whether the registered user registers the PSPS associated with the PSPA tool (1008). Each PSPA tool (1008) is to facilitate generation and receipt of transaction data signals relating to payment requests by the registered user, and credit and/or debit accounts based on the requested registered user. The downloadable elements of each PSPA tool (1008) include a registration module (1008a) and a Virtual Payment Address (VPA) creator module (1008 b). The registration module (1008a) allows for use of a registered user equipment (1006) of the registered PSPS (1004) associated with the PSPA tool (1008) in a one-to-one communication. The VPA creator module (1008b) allows a registered user to create a unique VPA containing the PSPS identity information registered by the registered user and allows the user device (1006) to transfer the unique VPA to the local storage device (1004a) of the PSPS (1004) in which the user is registered as part of the user information data of the registered user.

The UPI (100) facilitates registration of PSPS (1004) in the EPS (1000) and also facilitates selectively controllable mobile transaction data signals between PSPS to effect payment from one registered user to another registered user in the same or different PSPS. The UPI (100) includes a settlement module (100a) that generates net credit and debit instructions between registered PSPSPS's in coordination with a plurality of PSPS's periodically checking credit and debit transactions. In one embodiment, the settlement module (100a) is a settlement server.

To facilitate controlled mobile transaction data, the UPI (100) also includes a receiver (100b), a parser (100c), an extractor (100d), and a transmitter (100 e). The receiver (100b) receives a transaction data signal relating to a payment request from a registered user device via any PSPA tool. Each payment request includes the VPA of the first registered user, the VPA of the second registered user, and the transaction amount, such that the VPAs contain information about the PSPS registered by the first registered user and the second registered user. The parser (100c) parses the transaction data signal to obtain a parsed signal. The PSPS of the first registered subscriber and the PSPS related information of the second registered subscriber are then extracted and identified from the parsed signal by an extractor identifier (100 d). The transmitter (100e) transmits the transaction data signals to the identified respective PSPS to facilitate selective crediting or debiting of the first registered user account or the second registered user account based on the parsed data signal content.

Fig. 2A and 2B of the accompanying drawings are a person-to-person transaction flow for performing a payment transaction using the UPI (100). The UPI (100) is an interface with multiple servers.

In one embodiment, the UPI (100) includes a transaction server, an authorization server, a UPI server, and a settlement server. The transaction server processes the transaction data signals, the authorization server authorizes the registered user, and the UPI server processes the stored set of rules to identify the registered PSPS. The UPI (100) interacts with the bank according to the "instructions/requests issued from the PSPS via the PSPA tool". The UPI (100) performs transaction processing and payment settlement. In one embodiment, transaction processing is performed by a transaction server. At the end of the day, payment settlement is completed between the bank and the PSPS using a settlement server. In one embodiment, the PSPS server hosts a PSPA facility for use by registered users in transmitting payment requests. The payment request may be a payment/push request or a collect/pull request.

A payment pull request refers to a situation where an individual/entity needs to collect payments from other individuals/entities. A payment push request refers to a situation where an individual/entity needs to pay a certain amount to another individual/entity. In one embodiment, the enabling step to allow the user to push or pull payment comprises:

a. registering a PSPS;

b. registering the mobile phone bank, and generating a UPI PIN for the transaction (if not registered);

c. downloading a PSPA tool provided by any PSPS on user equipment, providing account detailed information and a password/login PIN by using the PSPA tool, and creating a configuration file for a registered user;

d. by utilizing the system, a VPA is created by using a PSPA tool and is used as a unique ID, so that the VPA is associated with the detailed information of any bank account of a user;

e. the push or pull payment request/transaction data is transmitted through the PSPA tool.

The PSPS is a bank that provides a PSPA tool and can register with the EPS (1000) to use the UPI (100). In the above step "a" of "registering PSPS", the user opens an account at the bank and registers his or her selected bank. If the user already has a bank account, the necessary details (including user device details) may be provided for handset bank registration to register the user device. After registration is complete, the user may download the PSPA tool mentioned in step "c" above. A user (e.g., a payer or payee) uses his user device to access his selected PSPA tool, regardless of whether he has an account with the bank that provides the PSPA tool. In step "d", the user must create a VPA. Fig. 8A is a VPA creation screen. The user provides the same detailed information to use the PSPA tool after registering at the bank. The user account is automatically displayed on the VPA creation screen of fig. 8A. So that the user does not have to remember account details. The system then prompts the user to create a new VPA or a VPA registered with it (if a VPA was previously created). In one embodiment, if the user registers at the "xyz" bank, the VPA will carry the suffix code "@ xyz". The UPI (100) and/or the PSPS (stored in the UPI server and/or the PSPS server) decide the VPA suffix code determination rule of a particular PSPS. The VPA will then have the user name selected by the user and the associated suffix code of the PSPS with which the user is registered. For "abc @ xyz," abc "is the unique name/user name selected by the user, and" xyz "is the user's PSPS name. Other examples include Uniquename @ HDFC, Uniquename @ SBI, Uniquename @ Corporation, Uniquename @ PNB, and the like. The user's PSPS will store VPA details created using the PSPA tool and other non-financial details in the local storage device of the PSPS. In one embodiment, the user registers with at least one bank using the PSPA tool, with account details such as the user's account name, account number, Aadhaar number, IFSC code, etc., for identifying the user's bank account to perform a payment transaction. Upon successful creation of the VPA, the user may use the VPA in transmitting push or pull payment request/transaction data through the PSPA tool. In addition, the user can also pay through UPI (100) using the account number and IFSC, Aadhaar number + IIN and cell phone number, MMID or cell phone number only (if and if included).

After the registration and VPA creation process is completed, the users (payers and payees) have the corresponding VPA. The payer or payee performs a payment transaction using the VPA/unique ID without knowing the bank name or bank account details of the opposite party. All the user's VPAs and bank details are maintained by the corresponding local storage device, processed by the corresponding PSPS server, and not shared by the UPI (100).

The payment transaction includes a collect transaction (collect request) and a payment transaction (payment request). The PSPA tool provides different options for the registered user to perform a payment transaction on the display screen of the user device, as shown in fig. 8B. The user may choose to pay for VPA, receive from VPA, pay using two-dimensional code, pay using account number and IFSC, pay Aadhaar, pay to cell phone number, and pay or receive. The UPI (100) also facilitates user retention of UPI transaction history via the PSPA tool. Allowing the user to manage his VPA. If the user wishes to manage his VPA, the "manage" option displayed on the screen may be selected, as shown in fig. 8B, and accordingly the screen of fig. 8E is displayed to the user by the PSPA tool. The user can then choose to modify the existing VPA or delete the existing VPA.

When the payee wishes to collect money from the payer (such as a pull money request or a collect transaction request or a collect request) (fig. 2A), the payee may use the payee user device (102) to access and operate the PSPA tool, providing the VPA/unique ID of the payer, and the amount of money the payee wishes to collect from the payer (step 1). In one embodiment of this case, the display screen presented to the payee is shown in fig. 8D. This screen is displayed when a pickup request is initiated (i.e., "pickup from VPA" of fig. 8B). Upon receipt from the VPA, the VPA that the user/payee has registered is automatically filled. The payee then needs to enter the payer's VPA, the amount to be charged, and any notes needed. The payee may also choose to collect the payment electronically and immediately or at a designated time. After submitting the collect request, the payee's PSPS (106) validates the request. The payee's PSPS (106) sends the verified request to the UPI (100) along with the payee's registered bank details and the payer's VPA/unique ID (step 2). The UPI (100) identifies the payer PSPS (108) based on the payer VPA suffix code, and sends a collect request to the payer PSPS (108) (step 3). The payer PSPS (108) transmits a collect request to the payer via the PSPA instrument using the payer user device (104). The payer receives the receipt request, and provides the authentication detail information if the receipt request is approved to be fulfilled, i.e., if the requested amount is approved to be paid to the payee. The payer PSPS (108) authenticates the payee (not shown) before verifying the transaction using the authentication method. The identity verification method comprises UPI PIN, biological characteristics, iris scanning and the like. An authentication credential is provided by the payer to continue the transaction. Bank details registered by the payer at the payer's PSPA tool and the payer's PSPS (108) via the payer user device (104) are transmitted to the UPI (100) server (step 4). The UPI (100) now has the bank details of the payer and payee based on VPA/unique ID. The UPI (100) uses the bank details to communicate with the sender bank (110) (i.e., the payer bank), debits the desired amount (steps 5 and 6), and then contacts the beneficiary bank (112) (i.e., the payee bank), crediting the amount to complete the transaction (steps 7 and 8). Upon successful transaction, the UPI (100) sends transaction success information to the payee and payer's PSPA tools (steps 9a, 9b, and 10), which are accessed by the payee user device (102) and the payer user device (104), respectively, wherein the transaction details are popped up on the display screens of the respective user devices by the respective PSPA tools.

The transaction flow of the collect/pull request includes the following steps (fig. 3):

step 301-the payee initiates a transaction on the payee user device (102) via the PSPA tool.

Step 302-payee user equipment (102) initiates a collect request to payee's PSPS (106).

Step 303-payee's PSPS (106) verifies payee details, verifying factor 1 authentication.

Step 304-the payee's PSPS (106) sends a collect request to the UPI (100).

Step 305-the UPI (100) resolves the payer's address in two ways:

a. if the address has a global identifier (e.g., cell phone number, unique ID, account number, etc.), the PSPS requests a suspend message from the UPI (100) through the API in accordance with the given cell phone number, Aadhaar number or account number and IFSC.

b. If the address has a virtual address provided by the payer PSPS (108), the UPI (100) will initiate a request to the payer PSPS (108) to translate the address.

Step 306-in the case of step 305b, payer PSPS (108) sends a notification to the payer, who accepts or rejects the request according to its own rule set.

Step 307-in the case of step 305b, after accepting the collect request, the payer PSPS (108) initiates a request to the payer user device (104) to enter authentication credentials. The payer provides authentication credentials on the payer user device (104).

Step 308-in the case of step 305b, payer PSPS (108) populates the payer details, and responds with the UPI (100).

Step 309-the UPI (100) sends a debit request to the debit account provider (110).

Step 310-the account provider verifies the identity of the payer based on the provisioned credentials.

Step 311-the account provider debits the payer account.

Step 312-the account provider sends a debit response to the UPI (100).

Step 313-the UPI (100) sends a credit request to the credit account provider (112).

Step 314-the account provider credits the account according to the payee details.

Step 315-the account provider sends a credit response to the UPI (100).

Step 316-the UPI (100) sends a confirmation response to the payer PSPS (108).

Step 317-the UPI (100) sends the payment response to the payee PSPS (106).

Step 318 — payee PSPS (106) notifies the payee.

When the payer wishes to issue an amount of money to the payee (i.e., a push money request or a payment transaction request or a push request) (fig. 2B), the payer accesses or operates the PSPA tool using the payer user device (104), providing the payee with an authorized VPA and the amount of money the payer wishes to issue to the payee (step 1). In one embodiment of this case, the display screen presented to the payer is shown in FIG. 8C. This screen is displayed when a push/pay request is initiated (i.e., "pay to VPA" of fig. 8B). Upon payment to the VPA, the user/payer VPA automatically populates because it has registered PSPS details with the PSPA tool. The payer then needs to enter the payee's VPA, the amount to be charged, and any notes needed. After submitting the payment request, the payer PSPS (108) may use an authentication method to authenticate the payer's identity prior to the transaction. The identity verification method comprises UPI PIN, biological characteristics, iris scanning and the like. An authentication credential is provided by the payer. The payer's authentication and bank details registered by the payer are sent to the UPI (100) together with the payee VPA via the payer PSPS (108) (step 2). The UPI (100) identifies the payee's PSPS (106) based on the payee's VPA suffix code, and sends a request to the payee's PSPS (106) (step 3). The payee PSPS (106) authorizes the bank details registered by the payee PSPA tool on the payee PSPS (106) through the payee user device (102) and returns the bank details to the UPI (100) server (step 4). The UPI (100) now has the bank details of the payer and payee based on VPA/unique ID. The UPI (100) uses the bank details to communicate with the sender bank (110) (i.e., the payer bank), debits the desired amount (steps 5 and 6), and then communicates with the beneficiary bank (112) (i.e., the payee bank), credits the amount to complete the transaction (steps 7 and 8). Upon successful transaction, the UPI (100) sends a transaction success message to the payer and payee PSPA tools (steps 9a, 9b, and 10), which are accessed by the payer user device (104) and payee user device (102), respectively, wherein the transaction details are popped up on the display screens of the respective user devices through the respective PSPA tools.

At the end of the day when all financial and non-financial transactions are completed, the UPI (100) settles all payment transactions that occur between all PSPS registered with the EPS (1000). In one embodiment, the payer uses a different PSPA tool than the payee. In another embodiment, the payer uses the same PSPA tool as the payee.

The transaction flow of the payment/push request comprises the following steps (fig. 4):

step 401-the payer initiates a transaction on the payer user device (104) through its PSPA tool.

Step 402-the payer provides authentication credentials on the payer user device (104).

Step 403-payer user device (104) initiates a payment request to payer PSPS (108).

Step 404-payer PSPS (108) verifies the details of the payer, verifying factor 1 authentication.

Step 405-payer PSPS (108) sends payment request to UPI (100).

Step 406-UPI (100) resolves the payee's address in the following two ways

a. If the address has a global identifier (e.g., cell phone number, unique ID, account number, etc.), the UPI (100) central mapping tool may resolve the payee address.

b. If the address has a virtual address provided by the payee PSPS (106), the UPI (100) will send a request to the payee PSPS (106) to translate the address.

Step 407-in the case of 406b, the payee PSPS (106) accepts or rejects the request according to its rule set.

Step 408-in the case of 406b, upon accepting the payment request, the payee PSPS (106) populates the payee details and responds to the UPI (100).

Step 409-the UPI (100) sends a debit request to the debit account provider (114).

Step 410-the account provider verifies the identity of the payer based on the provisioned credentials.

Step 411-the account provider debits the payer account.

Step 412-the account provider sends a debit response to the UPI (100).

Step 413-the UPI (100) sends a credit request to the credit account provider (112).

Step 414-the account provider credits the account according to the payee details.

Step 415-the account provider sends a credit response to the UPI (100).

Step 416-the UPI (100) sends a confirmation response to the payee PSPS (106).

Step 417 — the UPI (100) sends the payment response to the payer PSPS (108).

Step 418-payer PSPS (108) notifies the payer.

The EPS (1000) uses different authentication methods. In one embodiment, the EPS (1000) uses a "1-click 2-factor" authentication method, as shown in table 1 below:

TABLE-1

In particular embodiments, each PSPS (1004) includes an authentication module (not shown) configured to provide 2-factor authentication. The authentication module includes a factor 1 authentication tool and a factor 2 authentication tool. The factor 1 authentication tool accepts a pre-registered unique number from a registered user of the PSPS (1004), matches the accepted pre-registered unique number with user information data of the registered user stored in the local storage device (1004a), authenticates and associates the registered user with the registered user device (1006), thereby providing factor 1 authentication. The factor 2 authentication tool is configured to accept UPI PIN and/or biometric input from a registered user, match the accepted UPI PIN and/or biometric input with user information data, authenticate the registered user, and thereby provide factor 2 authentication.

Referring to table-1, for factor 1 authentication, at the time of registration in the PSPA tool, an encrypted short message is sent from the user equipment/handset of the user and transmitted to the PSPS where the user is registered. The PSPS verifies the unique number (cell phone number or IMEI, etc.) of the user equipment (this unique number is pre-stored as user information data of the PSPS at the time of user registration), and binds the unique number with the user account. If the customer registers with the cell phone bank, the UPI PIN or biometric will be used in the factor 2 authentication. If the customer wishes to register with the cell phone bank, the UPI PIN may be set using the last 6 digits of the debit card and the debit card expiration date, as well as the OTP issued by the card issuer, or any other similar suitable program. The PSPS may use the device fingerprint for authorization in later transactions. In factor 2 authentication, authorized by the issuer, the user may make a request to use UPIPIN or biometrics in the current transaction to authenticate the user's identity.

Fig. 5 of the accompanying drawings is a process of payment transaction between a taxi driver and a passenger. In an exemplary embodiment, a taxi driver uses the system of the present invention to charge a passenger/customer for the service provided. After the taxi reaches the destination, the taxi driver (in this case the payee) can use the system of the invention to pull/collect payment (taxi fare) to the passenger using his user device (502). The passenger provides a VPA and the taxi driver will enter a collect request on the VPA taxi driver user device (502) together in the payee PSPA tool. The PSPS (506) of the taxi driver (payee) provides the VPA and account details of the taxi driver to the UPI (500) (step 51). The UPI (500) identifies the passenger (payer) PSPS/bank via the VPA and sends a collect request to the passenger PSPS (508) (step 52). The passenger PSPS (508) sends a collect request notification to the passenger PSPA tool on the passenger user device (504) (step 53), accepting the collect request based on the passenger-provided authentication credentials (step 54). In one embodiment, the UPI PIN is entered using the PSPA tool on the passenger user device (504) for authentication. Upon receipt of the passenger (payer) confirmation, the passenger PSPS (508) verifies the passenger details, sends the financial details to the UPI (500), and debits the passenger (payer) bank account (step 55). A debit request is then sent to the passenger PSPS/bank (sender) (510), and the UPI (500) debits the requested amount of money from the passenger bank (sender) (510) (steps 56 and 57). The UPI (500) sends a request for credit to the taxi driver's PSPS/bank (beneficiary) (512) to credit the required amount (step 58), and upon successful credit receives a credit success message from the taxi driver's PSPS/bank (beneficiary) (512) (step 59). Next, the UPI (500) transmits a transaction success confirmation back to the passenger (payer) (step 50a) and the taxi driver (payee) (50b) through the respective PSPA tool.

Couriers (food delivery, garment delivery, etc.) can use the EPS (1000) of the present invention to address the payment on delivery (COD) issue. With the "1-click 2-factor" authentication method, only the UPI PIN can be entered to authorize the transaction.

Fig. 6 is a remittance payment transaction flow via EPS (1000), which a sender (payer) may use to push payment. The sender uses the user device (604) to enter a payment request including the VPA of the recipient (payee) and the issuing bank UPI PIN, and the amount to be pushed to the recipient bank (step 61). The account details of the sender, the UPI PIN and the VPA of the recipient are then provided to the UPI (600) via the PSPS (608) using the PSPA tool of the sender (step 62). The UPI (600) identifies the process/PSPS details of the sender (payee/beneficiary) and sends a payment request to the receiver's PSPS (606) (step 63). The recipient's PSPS (606) responds with the beneficiary financial transaction address (i.e., payee financial transaction address) (step 64). In response, the UPI (600) sends the sender (payer) account details and PIN and debit request to the sender PSPS/bank (610) (step 65), receiving a successful debit response (step 66). Upon receipt of the debit response, the UPI (600) sends a credit request to the receiver/payee's PSPS/bank (612) (step 67), receiving a successful credit response (step 68). A transaction success confirmation is then sent to the sender/payee's PSPS (step 69) and the consignee via the sender's PSPS (608) and the user device (604).

The payer/sender/merchant and the payee/receiver/customer may have the same PSPS. Fig. 7 is a three-party "merchant transaction" flow between a customer and a merchant using the same PSPS. The customer (710) registers the UPI (700) of the system of the present invention using the PSPA tool on his user device (702). Since the PSPS (704) for the customer and the merchant are the same, the PSPS (704) provides virtual addresses for the merchant and the customer. When a request (push or pull) is made using the PSPA tool, the request is sent (step 71) to a PSPS (704) common to the merchant and customer (in this case). In one embodiment, the request includes a reference ID (user VPA), an amount, and a merchant ID. Since the virtual address is available to the PSPS (704), the PSPS (704) actually provides the UPI (700) with the financial transaction address on which the virtual address is based (step 72). The UPI (700) then sends a debit request to the issuer/payer PSPS/bank (706) (step 73) and receives a debit response based on the push or pull request (step 74). The UPI (700) sends a credit request to the acquirer/payee's PSPS/bank (708) (step 75) and receives a credit success response from the acquirer/payee's PSPS/bank (708) (step 76). The UPI (700) transmits the transaction success (steps 77 and 78) to the user via the user device (702) using the PSPS (704).

The invention relates to an electronic payment method for facilitating payment transactions among a plurality of users. The method comprises the following steps:

● storing a predetermined set of rules in a master storage device;

● the operation processor processes the predetermined rule to obtain a set of system operation commands;

● registering a user with a plurality of Payment Service Provider Systems (PSPS) registered with an Electronic Payment System (EPS) (1000), each PSPS comprising the steps of:

○ stores user information data relating to the PSPS registered user in a local storage device,

○ are passed through at least one look-up table to match customer entered data and user information data with registered users,

○ providing a PSPS server;

● associating each of a plurality of user devices with a registered user and registering as part of the user information data;

● each of a plurality of Payment Service Provider Application (PSPA) instruments associated with and hosted on a PSPS server of a EPS registered PSPS, having elements downloadable and stored on a user device of a registered user independent of whether the registered user registers the PSPS associated with the PSPA instrument and facilitating generation and receipt by each PSPA instrument of transaction data signals relating to a payment request by the registered user and a credit and/or debit account based on the requested registered user, the downloadable elements of each PSPA instrument comprising the steps of:

○ the registration module allows the use of the PSPA tool-related registered user equipment of the registered PSPS in one-to-one communication,

○ Virtual Payment Address (VPA) creator Module allows a registered user to create a unique VPA containing PSPS identity information registered by the registered user and allows the user device to transfer the unique VPA to the local storage device of the PSPS in which the user is registered as part of the user information data of the registered user;

and

● a Unified Payment Interface (UPI) facilitates registration of PSPS in EPS while selectively controlling mobile transaction data signals between PSPS to effect payment from one registered user to another registered user in the same or different PSPS, the UPI comprising the steps of:

○ provides a settlement module that cooperates with a plurality of PSPS's to periodically check credit and debit transactions to generate net credit and debit instructions between registered PSPS's.

The UPI further comprises the steps of:

● the receiver receives from the registered user devices, via any PSPA facility, transaction data signals relating to payment requests, each request including a VPA of a first registered user, a VPA of a second registered user, and a transaction amount;

● the parser parses the transaction data signals to obtain parsed signals,

● the extractor identifier extracts and identifies from the parsed signal the PSPS of the first registered user and the PSPS related information of the second registered user,

● the transmitter transmits a transaction data signal to the respective PSPS identified to facilitate selective crediting or debiting of either the first registered user account or the second registered user account based on the parsed data signal content.

Each PSPS further comprises the step of providing 2-factor authentication by an authentication module. The step of providing 2-factor authentication comprises the steps of:

● the factor 1 authentication facility accepts a pre-registered unique number from a registered user of the PSPS, matches the accepted pre-registered unique number with user information data of the registered user stored in a local storage device, authenticates and associates the registered user with the registered user device, thereby providing factor 1 authentication,

● the factor 2 authentication tool accepts input from a UPI PIN and/or biometric of a registered user, matches the accepted UPI PIN and/or biometric input with user information data, authenticates the registered user device, and thereby provides factor 2 authentication.

Even if the customer and merchant use different PSPSs, both may have a variety of different PSPA tools on their respective user devices. In one embodiment, a PSPS Software Development Kit (SDK) is embedded in a merchant's PSPA tool, providing different PSPA tools for customers. In this case, when the merchant makes an intent/request, all UPI PSPA tools on the customer's user device will be displayed to the customer for selection of the same PSPA tool as the merchant. As shown in fig. 7, and also in this embodiment, the virtual addresses of the merchant and customer are available to the PSPS and the transaction proceeds in a manner similar to that previously described.

The EPS (1000) designed by the invention can be used for the transaction of physical stores/merchants, including the payment of vegetable suppliers, the payment of groceries, the payment of taxis/cars/buses/trains/plane tickets, the payment of restaurants/stores/gas stations, the payment of fees of various education institutions, the payment of charging areas during traveling, the payment of milk suppliers/newspaper suppliers, the payment of trusts/temples/relief money/non-government organizations, the payment of shopping centers and the like. The EPS (1000) can also be used to pay various fees including bill payment for electricity, water, phone, credit cards, etc., apartment maintenance bill submission and payment, school bill submission and payment, insurance fee payment, loan installment payment, car loan EMI payment, etc.

In addition, online merchants may also use the EPS (1000) for e-commerce transactions, including payment for cash on delivery, application payments. Shopping online, newspaper-ad mobile phone payment using "scan code payment", electronic commerce (collection/pull) -pay by UPI after checkout, order movie tickets, etc. In addition, the system can be used for remittance (push and pull) of person-to-person transaction, payment to other people/friends, bill sharing with friends, driver pay for wages, remittance to other bank accounts based on Aadhaar/mobile phone number.

Technical advantages

The invention described above has a number of technical advantages, including but not limited to implementing an electronic payment system:

● facilitate sending and receiving money in a simpler manner by means of the user device;

● provide a Unified Payment Interface (UPI);

● allow users to pull/collect payments from related individuals/entities;

● are simple to use for payers and payees;

●, rather than mandatorily requiring the provision of bank information and bank account details for each party, to effect a payment transaction between a payer and a payee;

● allow the user to send and receive money via the virtual payment address;

● provide secure payments based on a single/unique identifier;

● eliminates the risk of storing the customer's virtual address (as in a card);

● are available to customers without credit/debit cards;

● is suitable for electronic commerce and mobile phone commerce;

● solving the problem of collecting payment of the arrival;

● provide application payments (IAP);

● share only virtual addresses and not other sensitive information and privacy;

● facilitate multiple payment-cash on delivery/bill allocation/merchant payment/remittance;

● only enter a UPI PIN or biometric or UID or iris or otherwise authorize the transaction;

● can work between various interfaces, and can generate payment request on Web interface and authorize on mobile phone interface (App).

The present embodiments, together with various features and advantageous details thereof, will be understood by reference to the following description of specific embodiments, including, but not limited to, the embodiments. Descriptions of well-known components and processing techniques are omitted so as to not obscure the particular embodiments of the invention. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments of the invention may be practiced and to further enable those of skill in the art to practice the embodiments of the invention. Therefore, such examples should not be construed as limiting the scope of the embodiments of the invention

The foregoing description of the specific embodiments will 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. Therefore, such adaptations and modifications are intended to be included 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 modified within the spirit and scope of the embodiments described.

Claims (7)

1. An Electronic Payment System (EPS) (1000) for facilitating payment transactions between a plurality of users, the system comprising:

-a master storage device (1002a) configured to store a set of predetermined rules;

-an operation handler (1002b) configured to receive and process said predetermined rules in cooperation with the master storage device (1002a) to obtain a set of system operation commands;

-a plurality of Payment Service Provider Systems (PSPS) configured for user registration and further configured for said EPS (1000) registration, each PSPS (1004) comprising:

o a local storage device (1004a) configured to store user information data relating to registered users of the PSPS (1004),

o at least one look-up table (1004b) configured to facilitate matching customer entered data, user information data and registered users, an

o a PSPS server (1004 c);

-a plurality of user devices, each user device (1006) being associated with one of said registered users and registered as part of user information data,

-Payment Service Provider Application (PSPA) tools, each PSPA tool associated with and hosted on a PSPS server (1004c) of a PSPS (1004) of the registered EPS (1000), having elements that can be downloaded and stored on a user device (1006) of a registered user, independent of whether the registered user registers the PSPS associated with the PSPA tool (1008), each PSPA tool (1008) configured to facilitate generation and receipt of a payment request with the registered user, and transaction data signals related to crediting and/or debiting an account based on the registered user in the request, the downloadable elements of each PSPA tool (1008) comprising:

a registration module (1008a) configured to allow use of registered user equipment (1006) of the registered PSPS (1004) associated with the PSPA utility (1008) in a one-to-one communication,

o a Virtual Payment Address (VPA) creator module (1008b) configured to allow a registered user to create a unique VPA containing PSPS identity information registered by the registered user, and to allow the user device (1006) to transfer the unique VPA to a local storage device (1004a) of a PSPS (1004) in which the user is registered, as part of user information data of the registered user;

and

-a Unified Payment Interface (UPI) (100) configured to facilitate registration of PSPS (1004) in said EPS (1000), and further configured to facilitate selectively controllable mobile transaction data signals between PSPS, enabling payment from one registered user to another registered user in the same or a different PSPS, said UPI (100) comprising:

a settlement module (100a) configured to generate net credit and debit instructions between said registered PSPS in coordination with said plurality of PSPS periodically reconciling credit and debit transactions.

2. The EPS (1000) of claim 1, wherein said UPI (100) comprises:

-a receiver (100b) configured to receive transaction data signals relating to payment requests from registered user devices via any PSPA tool, each request comprising a VPA of a first registered user, a VPA of a second registered user, and a transaction amount;

-a parser (100c) configured to parse the transaction data signal to obtain a parsed signal;

-an extractor identifier (100d) configured to extract and identify the PSPS of the first registered user and the PSPS related information of the second registered user from the parsed signal;

-a transmitter (100e) configured to transmit said transaction data signal to the identified respective PSPS, facilitating selective crediting or debiting of the first registered user account or the second registered user account depending on the content of the parsed data signal.

3. The EPS (1000) of claim 1, wherein each PSPS (1004) further comprises an authentication module configured to provide 2-factor authentication, said authentication module comprising:

-a factor 1 authentication facility configured to accept a pre-registered unique number from a registered user of said PSPS (1004), match the accepted pre-registered unique number with user information data of the registered user stored in said local storage device (1004a), authenticate the registered user and associate with a registered user device (1006) to provide a factor 1 authentication,

a factor 2 authentication tool configured to accept input from a registered user UPI PIN and/or biometric, match the accepted PIN and/or biometric input with the user information data, authenticate the registered user device, and thereby provide factor 2 authentication.

4. The EPS (1000) of claim 2, wherein said UPI (100) further comprises a transaction server for processing transaction data signals, an authorization server for user authorization, and a UPI server for processing stored rule sets for identifying registered PSPS.

5. An electronic payment method for facilitating payment transactions between a plurality of users, said method comprising the steps of:

storing a set of predetermined rules in the master storage device;

an operation processor processes the predetermined rule to obtain a set of system operation commands;

registering a user registration with a plurality of Payment Service Provider Systems (PSPS) registered with an Electronic Payment System (EPS) (1000), each PSPS comprising the steps of:

o storing said PSPS registered user related user information data in a local storage device,

o matching the customer entered data with the user information data and the registered user via at least one look-up table,

o providing a PSPS server;

-associating each of a plurality of user devices with one of said registered users and registering as part of user information data;

each of a plurality of Payment Service Provider Application (PSPA) instruments associated with and hosted on a PSPS server of a EPS registered PSPS, having elements that can be downloaded and stored on a user device of a registered user, independent of whether the registered user registers the PSPS associated with the PSPA instrument, each PSPA instrument facilitating the generation and receipt of a payment request by the registered user, and transaction data signals relating to credit and/or debit accounts of the registered user based on the request, the downloadable elements of each PSPA instrument comprising the steps of:

the o-registration module allows the use of PSPA tool-related registered user equipment of the registered PSPS in one-to-one communication,

o a Virtual Payment Address (VPA) creator module that allows a registered user to create a unique VPA containing PSPS identity information registered by the registered user and also allows the user device to transfer the unique VPA to a local storage device of the PSPS in which the user is registered, as part of user information data of the registered user;

and

a Unified Payment Interface (UPI) to facilitate registration of PSPS in the EPS while selectively controlling mobile transaction data signals between PSPS to effect payment from one registered user to another registered user in the same or different PSPS, the UPI comprising the steps of:

a settlement module is provided for periodically reconciling credit and debit transactions with said plurality of PSPS to generate net credit and debit instructions between said registered PSPS.

6. The method of claim 5, wherein the UPI further comprises:

the receiver receives from the registered user devices, via any PSPA tool, transaction data signals relating to payment requests, each request including the VPA of a first registered user, the VPA of a second registered user, and a transaction amount;

a parser parses the transaction data signal to obtain a parsed signal,

the extractor identifier extracts and identifies the PSPS of the first registered user and the PSPS related information of the second registered user from the parsed signal,

the transmitter transmits the transaction data signal to the identified respective PSPS to facilitate selective crediting or debiting of the first registered user account or the second registered user account depending on the content of the parsed data signal.

7. The method of claim 5, wherein each PSPS further comprises:

providing 2-factor authentication by an authentication module, said step of providing 2-factor authentication comprising the steps of:

o the 1 st factor authentication tool accepts a pre-registered unique number from the registered user of the PSPS, matches the accepted pre-registered unique number with user information data of the registered user stored in the local storage device, authenticates and associates the registered user with the registered user device, thereby providing a 1 st factor authentication, and

the 2 nd factor authentication tool accepts input from a PIN and/or biometric of the registered user, matches the accepted PIN and/or biometric input with the user information data, and authenticates the registered user device, thereby providing 2 nd factor authentication.