GB2544341A

GB2544341A - A method, apparatus, system, and computer readable medium for processing an electronic payment transaction with improved security

Info

Publication number: GB2544341A
Application number: GB1520087.6A
Authority: GB
Inventors: Elgaard Robert; Scharff Jesper
Original assignee: Sdc As
Current assignee: Sdc As
Priority date: 2015-11-13
Filing date: 2015-11-13
Publication date: 2017-05-17
Also published as: EP3374951A1; GB201520087D0; WO2017080755A1

Abstract

A method for enabling a computer system 130 to manage processing of an electronic payment transaction between a payer 151 and a payee 140 without the payer disclosing financial information, such as credit card information, over the internet to the payee or to the computer system. The method comprises receiving, at the computer system 130, data from a financial institution 160 associated with the payer over a secure private connection. The data comprises financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer and is sent upon the financial institution receiving an authorisation message from the payer. A payment request, comprising identification information, may be received from the payer at the computer system which may validate the request by comparing the received data to identification information received from the financial institution to enable an electronic payment.

Description

A method, apparatus, system, and computer readable medium for processing an electronic payment transaction with improved security

Field of Invention

This disclosure relates to electronic payment transactions. More specifically, but not exclusively, this disclosure relates to the secure registration and subsequent processing of an electronic payment transaction from a payer to a payee.

Background of the Invention

The internet enables users to buy and sell goods and services online by utilising online electronic transactions to enable a buyer or payer to send money electronically to the seller or payee who then receives the money. In order for such e-commerce transactions to occur online between a payer and payee it is necessary for at least some financial information to be exchanged over the internet.

The volume of e-commerce transactions has been constantly on the rise in recent years and, compared to traditional payment methods such as payment by debit or credit card in person, or payment by cheque, the benefits of e-commerce include on-demand availability, speed of access, accessibility and global reach. However, all this comes with the risk of reduced security and privacy and, furthermore, requires lots of manual data entry. For example, users are faced with the exasperating task of entering their personal and financial details each time they shop online. Moreover, for each of these transactions, they are at risk of web hackers stealing their personal and financial details. The use of mobile phones for e-commerce (so-called m-commerce) raises the potential threat of data theft to a higher level because users may additionally have to exchange financial data over a mobile wireless network. Together, these risks and tasks keep many users away from shopping online and act as an obstacle for the further development of e-commerce and m-commerce.

One proposal for improving the security and privacy of e-commerce and m-commerce transactions is to encrypt transaction communications and implement security technologies such as the Secure Sockets Layer (SSL). However, such encryption techniques are still vulnerable to attack and provide little or no protection against attacks based on key-logging.

Another proposal is to use a web fraud detection system that looks for unusual behaviour in a user’s transaction activities. However, this is a reactive approach that detects fraudulent use after a user’s financial information has been stolen and used, which is less than ideal.

The issue of e-commerce and m-commerce fraud remains a huge problem and there are still inadequate measures in place to protect consumer’s financial information online.

Summary of the Invention

In accordance with an aspect of the disclosure there is provided a method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system. The method comprises receiving, at the computer system, data from a financial institution associated with the payer over a secure private connection. The data comprises financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer and is sent upon the financial institution receiving an authorisation message from the payer.

In addition there is provided a method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system. The method comprises sending, from the payer, an authorisation message to a financial institution associated with the payer, the authorisation message authorising the financial institution to send data to the computer system over a secure private connection. The data comprises financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer.

There is also provided a method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system. The method comprises sending, from a financial institution associated with the payer, data to the computer system over a secure private connection. The data comprises financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer and is sent upon the financial institution receiving an authorisation message from the payer.

The data received at the computer system in any of the methods disclosed herein may further comprise identification data associated with the payer.

The methods disclosed herein may also comprise receiving, at the computer system, identification data associated with the payer from the payer to validate the data received at the computer system from the financial institution associated with the payer.

The methods disclosed herein may also comprise verifying, at the computer system, that the financial details received from the financial institution associated with the payer are validated by the payer by comparing the identification data received from the payer with the identification data received from the financial institution.

The identification data associated with the payer may include data comprising one or more of the payer’s mobile phone number, name, email address, address.

Additionally, or alternatively, the identification data associated with the payer may include data comprising one or more of: a social security number associated with the payer; a location identifier associated with the payer such as the country code of the payer’s place of residence; a one-time-password (OTP); a hashed one-time-password (OTP); and a hashed value of the payer’s social security number concatenated with the hashed value of the OTP.

In the methods disclosed herein a one-time-password (OTP) may be generated by the financial institution associated with the payer and sent from the financial institution associated with the payer to the payer.

The data received at the computer system in the methods described herein may be encrypted.

Further, in the methods described herein, the data and messages sent to or from the payer may be sent to or from an electronic device associated with the payer, respectively.

Further, in the methods described herein, the financial details comprise one or more of the payer’s credit card details, debit card details, or current account details.

The credit card details may comprise the credit or debit card numbers, issue date, expiry date, CVV number, and/or the name of the account holder as displayed on the card.

The current account details may comprise the current account number, sort code and name of the current account provider.

In the methods disclosed herein the processing, at the computer system, of an electronic payment transaction between the payer and the payee may comprise: receiving and validating a payment request at the computer system; and if the payment request is valid, determining details associated with the payer, at the computer system and instructing an electronic payment at the computer system. The payment request may be received from the payer. In addition, the payment request may identify the electronic payment to be made from the payer to the payee and comprise identification data associated with the payer. Validating the payment request may be by verifying if the identification data received in the payment request is associated with the payer. The determined details associated with the payer enable execution of the electronic payment from the payer to the payee according to the payment request. The instructing of the electronic payment may be based on the determined details and the payment request.

Verifying if the identification data is associated with the payer may comprise comparing the identification data received in the payment request with identification data received from the financial institution.

The identification data received from the financial institution at the computer system and/or the determined details associated with the payer may be stored on the computer system.

The identification data received from the financial institution and the determined details associated with the payer may be linked to one another within the computer system.

The determined details associated with the payer may comprise financial information associated with the payer.

The determined details associated with the payer may comprise one or more of the payer’s name, address, social security number, company registration number, and mobile phone number details.

The payment request may be based on an order request originating from the payee.

The order request may be sent from the payee to the payer.

Optionally, an intermediate device, such as a computer terminal, associated with the payer may obtain the order request from the payee and provide the order request to the payer.

The order request may be provided from the intermediate device to the payer via electronic communication such as a Bluetooth, near field communication (NFC) or other short range wireless communication.

Alternatively, the order request may be provided from the intermediate device, such as a computer terminal, associated with the payer to the payer by displaying a QR code comprising the order request for the payer to read.

Instructing of the electronic payment may be sent to the financial institution associated with the payer for the financial institution to make the electronic payment.

The methods disclosed herein may also comprise the computer system receiving and sending a status indicator. The status indicator may be received from the financial institution and indicate approval or disapproval of the electronic payment. The status indicator may be sent to the payee, optionally as part of the data comprising a confirmation message.

The methods disclosed herein may also comprise the payer sending a payment request to the computer system. The payment request may identify the electronic payment to be made from the payer to the payee and comprise identification data associated with the payer.

The methods disclosed herein may also comprise the financial institution associated with the payer receiving instructions instructing the electronic payment based on the determined details and a payment request. The payment request may identify the electronic payment to be made from the payer to the payee and comprise identification data associated with the payer. Further, the payment request may be sent from the payer to the computer system.

Also disclosed is a method for processing an electronic payment transaction between a payer and payee without the payer disclosing financial information such as credit card information over the internet. The method comprises receiving, at a computer system, data comprising a payment request identifying an electronic payment to be made from a payer to a payee, the data received from equipment associated with the payer. The method further comprises the steps of: validating the payment request at the computer system; determining details of the payer and payee at the computer system; and instructing the electronic payment at the computer system, if the payment request is valid. The step of validating comprises verifying if the equipment is associated with the payer. The details of the payer and payee enable execution of the electronic payment from the payer to the payee according to the payment request. The step of instructing the electronic payment is based on the determined details and the payment request.

Also provided is a method for processing an electronic payment transaction between a payer and payee without the payer disclosing financial information such as credit card information over the internet. That is, there is provided a process for completing payments for eCommerce and mCommerce which improves security by eliminating the transfer of financial information, such as credit card information, over the internet from a payer to a payee. In addition, there is also provided a process to register for making such payments without disclosing financial information such as credit card details over the internet to the payee or computer system. Furthermore, there is also provided a process to validate the information provided to the computer system during registration without disclosing financial information such as credit card details over the internet to the payee or computer system. In this way, the risk of a web hacker stealing the payer’s financial details over the internet during a registration, validation and payment process is eliminated and the risk of credit card fraud is reduced.

In addition, there is also provided a method for processing an electronic payment transaction between a payer and payee without the payer having to enter his/her financial details each time they make a transaction. In this way, the method reduces manual input requirements and provides a better user experience.

In accordance with another aspect of the disclosure there is provided a computer-readable medium comprising instructions that are executable by a processor to perform the method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system, as per any one of the methods set out herein.

There is also provided a computer-readable medium comprising instructions that are executable by a processor to perform the method for enabling a payer to process an electronic payment transaction between a payer and payee without the payer disclosing financial information such as credit card information over the internet to the payee or the computer system, as per any one of the methods set out herein.

In accordance with a further aspect of the disclosure there is provided an apparatus comprising a processor and a memory, the memory storing instructions that are executable by a processor to perform the method for enabling a payer to process an electronic payment transaction between a payer and payee without the payer disclosing financial information such as credit card information over the internet to the payee or the computer system, as per any one of the methods set out herein.

The apparatus may be a server. The server may be configured to communicate with: a financial institution associated with the payer; a financial institution associated with the payee; equipment associated with the payee; and the equipment associated with the payer. The financial institution associated with the payer may be suitable for paying the payee according to the payment request. The financial institution associated with the payee may suitable for receiving payment from the payer according to the payment request.

In accordance with a further aspect of the disclosure there is provided a system comprising the server set out above, the financial institution associated with the payer, the financial institution associated with the payee, equipment associated with the payee; and the equipment associated with the payer.

The payee may be a merchant such as any company selling goods to consumers. The payer may be a consumer such as a private consumer or corporate consumer that purchases goods from a merchant. A financial institution may be, for example, a bank. A computer system may orchestrate and enables a payment process between a payer and a payee. The computer system may hold credit card and account information along with name, email and address information of the payer and payee, these details facilitating a secure and user friendly payment experience.

Brief Description of the Drawings

Exemplary arrangements shall now be described with reference to the drawings in which:

Figure 1 illustrates an electronic payment system in accordance with the present disclosure;

Figure 2 illustrates a registration process as used in the system of Figure 1 and in accordance with the present disclosure;

Figure 3 illustrates a payment process as used in the system of Figure 1 and in accordance with the present disclosure; and

Figure 4 illustrates a smartphone associated with a payer displaying user selectable options in accordance with a payment request received from a payee.

Throughout the description and the drawings, like reference numerals refer to like parts. Specific Description

In the present disclosure, a payer may make an electronic payment to a payee without the payer sending financial information such as credit card or bank account details over the internet. For example, a consumer may purchase goods for sale on a merchant’s website by making an electronic payment to the merchant for the goods, without disclosing his or her financial details to the merchant or sending his or her financial details over the internet. This is achieved as set out below.

In a standard online transaction, a consumer (i.e. a payer) identifies something that they would like to purchase on a merchant’s (i.e. payee’s) website. Then the payer provides their financial information such as credit card details and identification information over the internet to the payee so that the payee can process the transaction.

In contrast, the system of the present disclosure uses a computer system, such as a server, to store the financial and identification information of both the payer and payee, which is provided during a registration process to the server directly from the payer and payee’s bank over a direct secure connection, rather than over the internet. When a payer wants to purchase something from a payee, the payer obtains details from the payee that identify an electronic payment to be made from the payer to the payee. These details include the payment amount and identification details of the payee such as the payee’s company registration number. The payer sends the details of the payee to the server along with its own identification details, which comprise the hashed value of the payer’s social security number concatenated with the hashed value of a one-time passcode (OTP) that is generated by the payer’s bank. In addition to the payer identification details, the payer may send information to identify a selected credit card or other details for making the payment to the payee. To authorise the payment, the server validates that the received information from the payer is from the payer based on comparing the identification details that were received from the payer during the purchasing process with the identification details that were received during registration. If the payment is validated, the server then uses the received information to process the transaction by obtaining the relevant financial information associated with the payer and payee that it already has pre-registered. This obtained data enables execution of the electronic payment from the payer to the payee according to the details received from the payer. In this way, the process allows for an online financial transaction to be made without a consumer sending his/her financial details over the internet.

An overview of the electronic payment system shall now be described with reference to Figure 1.

An electronic payment system 100 comprises a computer system or server 130 which is configured to process an electronic payment transaction between a payer 150 and a payee 140 without the payer disclosing financial information such as credit card information over the internet. The computer system 130 is arranged in communication with: an electronic device 140 associated with the payee; an electronic device 150 associated with the payer, which in the arrangement discussed below is a smartphone; an electronic device of a financial institution 160 associated with the payer, i.e. the payer’s bank; and an electronic device of a financial institution 170 associated with the payee, i.e. the payee’s bank. The electronic device associated with the payee 140, and the electronic device associated with the payer 150, are communicatively connected to the computer system 130 via a network that comprises the internet. The financial institution associated with the payer 160, and the financial institution associated with the payee 170, are communicatively connected to the computer system 130 via a secure private network connection which, as is known in the art, is not accessible via the internet.

The system further comprises a further electronic device associated with the payer 151, which in the arrangement discussed below is a computer terminal. This further electronic device 151 is arranged in communication with the electronic device associated with the payee 140 and the electronic device associated with the payer 150. The electronic device associated with the payer 150 is also arranged in communication with the electronic device of a financial institution associated with the payer 160. The electronic device associated with the payee 140 is also arranged in communication with the electronic device of a financial institution associated with the payee 170. Also, arranged in communication with each other are the electronic device of the financial institution associated with the payee 170 and the electronic device of the financial institution associated with the payer 160. Further communicative couplings between devices in the system will become clear when the process operated by the system is discussed in detail.

The computer system 130 has memory arranged to store information about both the payer and payee, including financial information and identification data of the payer and payee. All information associated with a particular payer or payee has an association, for example it may be stored in a particular account together. The computer system 130 also has a processor arranged to manage the processing of financial transactions between each of the other devices within the overall electronic payment system 100.

Each of the other devices within the electronic payment system 100 comprises at least a memory, processor and communications port for communicating with other devices within the system 100. The electronic device associated with the payer 150 is a smartphone and includes a camera, which as will be discussed, enables the electronic device 150 associated with the payer to capture information from the further electronic device 151 associated with the payer. In addition, the electronic device 150 includes a communications module, which as will be discussed, enables the electronic device 150 associated with the payer to transmit and receive information to and from the further electronic device 151 associated with the payer, the computer system 130, and the payer’s financial institution 160. In certain arrangements the communications module is a short range communications module.

Further, each component of the electronic payment system 100 contains software components that enable an electronic payment transaction between a payer 130 and a payee 120 in accordance with the methods disclosed herein. That is, for example, the computer system 130, the electronic device 140 associated with the payee, the electronic device 150 associated with the payer, the further electronic device 151 associated with the payer, the electronic device of a financial institution associated with the payer 160, and the electronic device of a financial institution associated with the payee 170 each contain software components that enable an electronic payment transaction between a payer 150 and a payee 140 to be processed in accordance with the methods disclosed herein.

In the following sections, the interactions between the components of the electronic payment system 100 are outlined. Also outlined is a technical description of how the payer and payee enroll, or register, to the electronic payment system. In addition, an outline of the payment process for making an electronic payment transaction between the payer and payee is given.

Figure 2 illustrates a registration process in accordance with the present disclosure which will now be described with reference to the electronic payment system of Figure 1. This registration process enables the financial data of a payer (e.g. consumer) and a payee (e.g. merchant) to be stored on the server, which then enables for the secure payment process to take place.

At step R1 of the registration process, the payee 140 sends a request to the payee’s bank 170 to enroll to the electronic payment system 100. The request may either be sent and processed using the bank’s online banking service or in a branch office of the bank. In response to the request, the payee’s bank 170 generates and sends an activation code to the payee 140. The activation code is used to authenticate the payee to the electronic payment system 100 and, if the payee is using an online banking service for registration, the activation code alternatively may be delivered to the payee by displaying it in the online banking service. Together with the activation code, the payee’s bank 170 sends instructions to the payee 140 instructing the payee to: save the activation code for later use; and download and install an app, or software, from the server 130. The app, or software, contains components that enable the payee to validate the information provided to the computer system 130 from the payee’s bank and process electronic payments via the electronic payment system 100.

At step R2 of the registration process, the payee’s bank 170 sends the activation code to the server 130, together with financial details of the payee for enabling execution of an electronic payment from a payer to the payee. The financial details of the payee include the payee’s name, address, company registration number, and one or more account numbers chosen by the payee for receiving electronic payment transactions. The data transmitted from the payee’s bank 170 to the server 130 is sent over a network connection that is not accessible via the internet such as a secure private network, an IPSec protected connection or a 2-way SSL protected connection. Further, the transmitted data is encrypted using public key infrastructure (PKI) cryptographic techniques, as are known in the art. For example, the transmitted data at step R2 is encrypted using the global public key that is exclusively for use with the electronic payment system 100. This global public key is embedded in each of the components of the electronic payment system 100 such as, for example, the payee’s bank 170.

At step R3 of the registration process, the payee 140 downloads and installs the software from the server, as per the instructions at step R1. During installation, the payee 140 enters the activation code that was received from the payee’s bank 170 into the software. After the installation is complete, the software configures the payee’s electronic device 140 to generate and transmit to the server 130 an encrypted message that includes identification data associated with the payee such as data comprising the payee’s company registration number and a message authentication code (MAC) based on the activation code such as a hashed value of the activation code. For example, the payee’s device 140 may first generate a message containing the payee’s company registration number and a public key of the payee. The public key of the payee is part of a public-private key pair that the payee generates and provides to the server 130 to encrypt any messages that it sends back to the payee such as, for example, a confirmation message indicating approval or disapproval of an electronic payment. The corresponding private key of the payee is stored on the payee’s device and used to decrypt any messages that are encrypted with the public key of the payee. After generating the message containing the payee’s company registration number and the public key of the payee, the payee appends the message with a message authentication code (MAC) that is based on the activation code (such as a hashed value of the activation code) to form a new message. This new message is then encrypted with the global public key of the electronic payment system 100, which is embedded in the app downloaded by payee 140 and sent to the server 130 from the payee’s device 140.

Following receipt of the encrypted message, the server 130 decrypts the encrypted message using the corresponding global private key of the electronic payment system which is stored exclusively on the server 130.

After decrypting the encrypted message, the server 130 searches its database to find and retrieve financial details which correspond to the company registration number details that were received in the encrypted message from the payee’s device. The financial details retrieved from the database may have been sent to the server from the payee’s bank.

Subsequently, to verify that the retrieved financial details are associated with the payee, the server 130 calculates a separate MAC value based on details of the activation code that are contained in the retrieved financial details. If the calculated MAC value corresponds to the MAC value received in the encrypted message from the payee, the retrieved financial details are verified as being associated with the payee. In this case, the server 130 completes enrollment of the payee with the electronic payment system 100 by retaining the retrieved financial details in its database and associating these details with the payee . If the encrypted message received from the payee contains a public key of the payee, the server 130 also stores and links the public key of the payee with the retained financial data. This public key of the payee will be used in later steps to send a confirmation message to the payee to indicate approval or disapproval of an electronic payment request. If the calculated MAC value does not correspond to the MAC value received in the encrypted message from the payee, validation fails and enrollment is not complete. If validation fails three consecutive times, the retrieved financial details are deleted. In this case, the server 130 sends a message to the payee requesting the payee to contact his/her bank.

At step R4 of the registration process, the payer 150 sends a request to the payer’s bank 160 to enroll to the electronic payment system 130. The request may be sent and processed using the bank’s online banking service or submitted and processed at a branch office of the bank.

At step R5 of the registration process, the payer’s bank 160 sends to the server 130data comprising financial and identification data associated with the payer. Financial data of the payer comprises details of the payer’s standard remitting account number and credit card numbers. The standard remitting account is selected by the payer’s bank 160 and is typically the payer’s current account. Identification data of the payer includes data comprising the payer’s social security number (or company registration number for corporate users), mobile phone number, name, email address, address, the country code of the payer’s place of residence, and a hashed one-time-password (OTP). The hashed one-time-password (OTP) is generated by the payer’s bank 160 and used to validate the payer details provided to the server 130 during registration and authenticate payment requests made by the payer 150 to the electronic payment system 130. The data transmitted from the payer’s bank 160 to the server 130 is sent over a network connection that is not accessible via the internet such as a secure private network, an IPSec protected connection or a 2-way SSL protected connection. Further, the transmitted data is encrypted using public key infrastructure (PKI) cryptographic techniques, as are known in the art. For example, the transmitted data is encrypted using the global public key that is exclusively for use with the electronic payment system 130. This global public key is embedded in each of the components of the electronic payment system such as, for example, the payer’s bank 160.

After the server 130 receives the financial and identification data of the payer, the server 130 stores the received financial and identification data in a new database entry. The key for the new database entry is a hash-value of the payer’s social security number concatenated with the hashed OTP. In pseudo code, this is represented as H” =

CalcHash(SocialSecurityNumber + H’(OTP)), where H’(OTP) = CalcHash(OTP). The new database entry includes a status indicator indicating that the server is waiting for the payer to validate that the received financial and identification data is associated with him/her. Also provided in the new database entry is a timer indicating a time limit for the payer to verify that the received financial and identification data is associated with him/her.

At step R6 of the registration process, the payer’s bank 160 passes the OTP to the payer. If the enrollment is done in a branch office the OTP is passed on paper print and, if the enrollment is done using online banking, the OTP is displayed in the online banking website/app/software running on the payer’s device. Subsequently, the payer’s bank 160 sends instructions to the payer’s device 150 instructing the payee to save the OTP for later use and download, install and run an app, or a piece of software. The app, or software, contains components that enable the payer to validate the financial and identification data provided to the server 130 from the payer’s bank, and to process electronic payments via the electronic payment system 130 For example, the payer may be instructed to download the app from an App-Store, appropriate to the brand of the payer’s smartphone, and to start the app on the smartphone and have the OTP ready for use in the subsequent validation steps.

At step R7 of the registration process, the payer enters his social security number and the OTP into the app. After this has been complete, the payer’s electronic device 150 is configured to generate and transmit to the server 130 an encrypted message that comprises the payer’s social security number and, to integrity protect the message, a message authentication code (MAC) based on a hashed value of the OTP. For example, the payer’s device 150 may first generate a message containing the public key of the payer and data comprising a hashed value of the payer’s social security number concatenated with the hash value of the OTP. In pseudo code, the hashed value of the payer’s social security number concatenated with the hash value of the OTP is represented as H” = CalcHash(SocialSecurityNumber + H’(OTP)), where H’(OTP) = CalcHash(OTP). The public key of the payer is part of a public-private key pair that the payer generates and provides to the server 130 to encrypt any messages that it sends back to the payer such as, for example, a missing information message that indicates additional data which the server requires in order to complete registration. The corresponding private key of the payer is stored on the payer’s device and used to decrypt any messages that the payer 150 receives from the server 130. Successful decryption ensures that the received message originated from the server 130 and not another device because only a message encrypted with the public key of the payer may be decrypted by the private key of the payer. After generating the message, , the payer appends the message with a MAC value. The MAC value is calculated based on the hashed value of the OTP and the data in the message such as the public key of the payer and/or the hash value of the payer’s social security number concatenated with a hashed value of the OTP. Thereafter, the payer encrypts the entire message, which includes the MAC value, using the global public key of the electronic payment system 100, which is embedded in the app downloaded by the payer 150, and sends the encrypted message to the server 130 from the payer’s device 150.

After receiving the encrypted message from the payer device 150, the server 130 decrypts the received message using the corresponding global private key. Subsequently, the server finds the database entry containing data corresponding to the payer’s social security number. For example, the server 130 may locate and retrieve the database entry that was created at step R5 which contains identification details corresponding to the received data from the payer 150 such as the payer’s social security number.

Subsequently, the server calculates a MAC value based on the stored hashed OTP and the data in the received message from the payer such as the public key of the payer and/or the hash value of the payer’s social security number concatenated with a hashed value of the OTP. Thereafter, to verify that the data in the database entry, or rather that the financial and identification data stored in the database entry, is associated with the payer, the server 130 determines whether the calculated MAC value corresponds to the MAC value received with the message from the payer If the calculated MAC value corresponds to the MAC value received from the payer 150, the data in the database entry is verified as being associated with the payer. In this case, the server 130 retains the data in the database entry and associates this data with the payer. Furthermore, if the encrypted message received from the payer 150 contains a public key of the payer, the server 130 includes the public key of the payer in the database entry and links it to the data associated with the payer. In addition, the server updates the status indicator stored with the data in the database entry to indicate that the payer has completed validation and hence registration.

If registration is complete, the server subsequently examines whether any information needed for completing an electronic payment from the payer is missing in the data associated with the payer. If such data is found to be missing, the server 130 generates and sends an encrypted missing information message to the payer 150 to indicate the missing data items. Together with the missing information message the server 130 sends a payment profile to the payer 150 to indicate the types of payment instruments that have been registered with the server and the country code of the payer’s place of residence. The server encrypts the missing information message and payment profile message using the public key of the payer and sends the encrypted messages to the payer over the mobile network using, for example, transport layer security (TLS). The missing information message and the payment profile message may be sent separately or together as one message. Examples of missing data items include any of the payer identification details set out above such as the payer’s name, address, email address, and the CW codes of the payer’s debit and/or credit cards. However, the missing data items do not include any of the payer’s financial details, such as the payer’s bank account number or credit card numbers. If a missing information message is provided to the payer, either during registration or a purchasing session, the payer will be prompted to provide the missing information to the server 130. An encrypted message containing the missing data items may subsequently be generated by the payer 150 and sent to the server 130 for storage in the database entry that is associated with the payer. The encrypted message containing the missing data items is encrypted by the payer based on the global public key of the electronic payment system 100.

If the calculated MAC value does not correspond to the MAC value received from the payer, validation fails and enrollment is not complete. In this case, the server 130 sends a message back to the payer 140 asking the payer to check, re-enter and re-send the message that includes data comprising a hashed value of the payer’s social security number concatenated with the hash value of the OTP. The message sent to the payer 150 from the server 130 may be encrypted based on the public key of the payer that was received in the previous message.

If validation fails three consecutive times, the data stored in the database entry at the server 130 is deleted. In this case, the server 130 sends a message to the payer 150 requesting the payer to contact his/her bank for registration assistance.

In summary, there is therefore provided a registration process wherein the payee’s electronic device 140 sends a registration request to the payee’s bank 170. In response to the registration request, the payee’s bank 170 sends to the server 130 data comprising: an activation code; financial details of the payee such as the payee’s bank account details; and details of the payee’s name, address, and company registration number. The data is sent from over a private network connection that is not accessible to internet traffic. Alternatively, the data may be transmitted over an IPSec protected connection or a 2-way SSL protected connection.

The payee’s electronic device 140 sends data comprising an identifier, or rather identification data, to the server. The identifier is used by the server to validate the information it received from the payee’s bank 170. In examples, the identifier may be based on a company registration number and/or an activation code. In addition, a MAC value based on the company registration code and/or activation code may be used for validating registration of the payee 140 with the electronic payment system 100. Following receipt of the data received from the payee and the payee’s bank, the server 130 validates the registration request by verifying if the identifier of the payee received from the payee 150 corresponds with one or more data items that it received from the payee’s bank 170.

There is also provided a registration process to register the payer 150 with the electronic payments system 100. In summary, this registration process comprises, the payer’s electronic device 150 sending a registration request to the payer’s bank 160. In response to the registration request, the payer’s bank 160 sends data comprising financial details and identification details of the payer to the server 130. The identification details include data comprising a hashed one-time passcode generated by the payer’s bank 160, the payer’s social security number, and the country code of the payer’s place of residence. The financial details of the payer include data comprising the payer’s credit card details and bank account details. The data is sent from the payer’s bank 160 to the server 130 over a private network connection that is not accessible to internet traffic. Optionally, the data may be transmitted over an IPSec protected connection or a 2-way SSL protected connection.

Subsequently, the payer’s electronic device sends identification data to the server 130 to validate the data received at the server 130 from the payer’s bank 160. The identification data includes data comprising the public key of the payer and a hashed value of the payer’s social security number concatenated with the hash value of the OTP. In pseudo code, the hashed value of the payer’s social security number concatenated with the hash value of the OTP is represented as H” = CalcHash(SocialSecurityNumber + H’(OTP)), where H’(OTP) = CalcHash(OTP).

Following receipt of the data received from the payer 150 and the payer’s bank 160, the server 130 validates the registration request by verifying if the identification details of the payer provided in the message from the payer corresponds to one or more identification details of the payer received from the payer’s bank 160. A payment process in accordance with the present disclosure is illustrated in Figure 3 and will now be described with reference to the electronic payment system of Figure 1.

At step P1 of the payment process, a payer uses his computer 151 to selects goods to purchase from a payee’s website. At check-out, the payer indicates that he would like to purchase the goods using the electronic payment system 100 described herein. In response to this request, the payee generates a QR code containing an order request and, subsequently, provides the QR code to the payer’s computer 151 for display. Figure 4 illustrates the displayed QR code at the payer’s computer 151.

The order request identifies an electronic payment to be made from the payer to the payee and includes order details which may comprise one or more of: a payment amount; a list of payment instruments accepted by the payee; a purchase expiry time; a session ID between the payer’s browser and payee’s website at the time of the purchase; a URL containing a session identifier as a parameter to identify an address at which payment confirmation messages to the payee should be sent such as, for example, a netpoint; payee identification data such as the company registration number of the payee; and a digital signature of the payee. The digital signature of the payee is the hash value of the other data items included in the order request and is encrypted with the private key of the payee that was generated during the registration process at step R3. The netpoint defines a return point, or rather address, where messages to the payee should be sent. In the payment methods described herein, messages, such as confirmation message indicating approval or disapproval of an electronic payment, may be sent from the server to the payee according to the return point specified by the netpoint.The expiry time is generated by the payee and sets a time limit to complete the purchase such as, for example, 10 minutes. Examples of payment instruments include a Visa ® payment, MasterCard ® payment, American Express ® payment, and PayPal ® payment.

After the QR code is displayed on the payee’s computer 151, the payee’s smartphone 150 scans the QR code using the smartphone’s camera, as illustrated in Figure 4 at step 405. In other words, the payer’s smartphone 150 receives the order request by using a QR scanner embedded in the payer’s smartphone 150. The payment request is then processed by the payer’s smartphone 150 to make the electronic payment to the payee 140.

Part of the processing at the payer’s smartphone comprises comparing the payment instruments accepted by the payee in the order request with the available forms of payment set out in the payer’s financial details, such as the payer’s credit card details, to determine which payment instruments are accepted by both the payee and payer. The available forms of payment may be provided in the payment profile that was sent by the server to the payer at step R7 of the registration process. After this determination, the payer’s smartphone displays the list of payment instruments accepted by the payee and payer for the payee to then choose a preferred payment instrument to make the electronic payment transaction. An illustration of the displayed list of payment instruments to select from is illustrated at point 410 in Figure 4.

Also contained in the order request, or optionally the QR code, is a request from the payee to access information associated with the payer such as the payer’s identification data. For example, the order request may request permission to access details of the payer’s name, address and email address. If such a request is made, the payer’s smartphone 150 informs the payer of the information requested by the payee for the payee to then select which information items the payee 140 can have access to. For example, the payer’s smartphone 150 may display the information requested by the payee for the payer to then select which information items the payee 140 can have access to. An illustration of the displayed request on the payer’s smartphone 150 is illustrated in Figure 4 at point 420. Subsequently, the payer enters his pin code and taps ΌΚ’ to confirm the access settings and the selected payment instrument. In the payment methods described herein, preference information indicating the payer’s access settings may be included in the payment request sent from the payer 150 to the server 130.

At step P2 of the payment process, the payer builds a payment request. The payment request contains data from the order request, together with identification data of the payer, a digital signature of the payer and, optionally, preference information identifying the payer’s access settings, the country code of the payer’s place of residence, and/or other details for making the payment to the payee. The identification data of the payer includes data comprising a hashed value of the payer’s social security number concatenated with the hash value of the OTP. In pseudo code, this is represented as H” =

CalcHash(SocialSecurityNumber + H’(OTP)), where H’(OTP) = CalcHash(OTP). The digital signature of the payer is the hash value of the other data items included in the payment request and is encrypted with the private key of the payer that was generated during the registration process at step R7. The data from the order request includes the payment amount and the digital signature of the payee generated at step P1. Optionally, the payment request may include one or more other order request data such as: the list of payment instruments accepted by the payee; the purchase expiry time; the session ID between the payer’s browser and payee’s website at the time of the purchase; the URL containing a session identifier as a parameter to identify an address at which payment confirmation messages to the payee should be sent such as, for example, a netpoint; and payee identification data.

After forming the payment request, the payer 150 encrypts the payment request using the global public key of the electronic payment system 100. This global public key is contained in the app that was installed on the payer’s smartphone 150 during registration. After encryption, the payer 150 transmits the payment request to the server 130 over a cellular network using security technologies such as Transport Layer Security (TLS).

At step P3 of the payment process, the server 130 receives the payment request from the payer 150. After receipt, the server 130 decrypts the payment request, the digital signature of the payer, and the digital signature of the payee.

Thereafter, to verify the integrity of the payment request, the server 130 verifies that the digital signature of the payer is associated with the payer. Additionally or alternatively, the server may verify that the digital signature of the payee is associated with the payee. Verification of the payer’s digital signature is done by recalculating the digital signature of the payer based on the relevant data contained in the payment request, and subsequently determining whether the calculated digital signature corresponds to the received digital signature in the payment request. That is, the server calculates its own hash value of the received payment request and checks whether this hash value corresponds to the received hash value from the payer. Similarly, verification of the payee’s digital signature is done by recalculating the digital signature of the payee based on the relevant data contained in the payment request, and subsequently determining whether the calculated digital signature corresponds to the received digital signature of the payee in the payment request.

Verification is confirmed if the calculated digital signatures are found to correspond to the received digital signatures from the payer.

If a purchase expiry time is included in the payment request and both digital signatures verify correctly, the server 130 then examines whether the purchase expiry time has been exhausted. If the purchase expiry time is not exhausted, the server 130 proceeds to validate that the payment request from the payer is associated with the payer.

The validation process includes the server 130 retrieving the database entry that contains data corresponding to the payer’s social security number received in the payment request. The server then verifies that the payer identification data contained in the payment request corresponds to the payer identification data in the database entry. For example, if the received identification data is a hashed value of the payer’s social security number concatenated with the hashed value of the OTP, the server determines if this data corresponds to the hashed value of the payer’s social security number concatenated with the hashed value of the OTP stored in the database entry. If the payer identification data received in the payment request is found to match the payer identification data in the database entry, the server validates that the payment request from the payer is associated with the payer.

If the payment request is validated, the server uses the information in the payment request to process the transaction by obtaining the relevant financial information and/or identification information associated with the payer and payee that it already has pre-registered during registration. This obtained data enables execution of the electronic payment from the payer to the payee according to the payment request details received from the payer. In this way, the process allows for an online financial transaction to be made without a consumer sending his/her financial details over the internet.

If the payment request is validated, the server uses the information in the payment request to process the electronic payment by obtaining the relevant financial information and/or identification information associated with the payer that it already has pre-registered during registration. Optionally, the relevant financial information and/or identification information associated with the payee may also be obtained. For example, the server 130 obtains the bank account details of the payer that were stored in the database entry associated with the payer during registration

After the payment request has been validated, the server 130 makes a credit card transaction request or an account transfer (i.e. direct debit) transaction request according to the payment request. The transaction request is sent to the payer’s bank 160 over a secure private network connection that is not connected to the internet. In other examples, the transaction may be sent to a preferred acquirer selected by the payer’s bank.

At step P4 of the payment process, the payer’s bank 160 either accepts the transaction request or declines the transaction request. For example, the payer’s bank 160 may decline the transaction request if there are not enough funds in the payer’s account for making the payment. In response to the transfer request, the payer’s bank sends a status indicator to the server 130, indicating whether the transaction request has been accepted or declined.

If the payer’s bank 160 accepts the transfer request, it makes the electronic payment to the payee’s bank 170. In addition, the payer’s bank sends a status indicator to the server 130 indicating that the transfer request has been approved. When the server receives the status indicator, the server 130 sends a confirmation message to the payee 140 containing the status indicator and any payer information that the payer granted access to in the payer’s access settings at step P1 of the payment process. The confirmation message is sent to the payee 140 according to, for example, the return point specified in the netpoint data received in the payment request. In addition, the confirmation message is digitally signed by the server and encrypted using the public key of the payee that was generated during the registration process at step R3 of the registration process.

If the payer’s bank 160, or the acquirer, declines the transfer request, the payer’s bank sends a status indicator to the server 130 indicating that the transaction request has been declined. When the server receives the status indicator, the server sends a confirmation message to the payee 140 containing the status indicator. In this case, the confirmation message does not contain payer information that the payer granted access to in the payer’s access settings.

After receiving the confirmation message, the merchant sends a message to the payer’s computer 151 and/or electronic device of the payer 150. This message either informs the payer that the payment has been approved or declined.

Therefore, in summary, there is provided a payment process wherein the payee’s electronic device 140 generates an order request and sends it to the payer’s computer 151. The payer’s smartphone 150 obtains the order request by reading the order request from the payer’s computer 151. The payer’s smartphone 150 then generates a payment request containing data from the order request together with an identifier of the payer to the computer system 130. For example, the smartphone 150 may send to the computer system 130a payment request comprising the order request, a digital signature of the payer, and payer identification data comprising a hashed value of the payer’s social security number concatenated with the hashed value of the OTP.

Following receipt of the payment request, the computer system 130 validates the payment request by verifying if the payment request is associated with the payer 250. More specifically, the computer system verifies whether the received payer identification data corresponds to the payer identification data it holds in its database. Additionally or alternatively, the computer system 130 may verify the integrity of the payment request by recalculating the digital signature(s) associated with the payment request and evaluating whether the recalculated value(s) correspond to the received digital signature(s) from the payer. The stored details of the payer and/or payee may be stored locally on the computer system or retrieved from an external database that stores details of all payers and payees registered with the electronic payment system 100.

In addition to validating the payment request, the computer system 130 determines details associated with the payer and payee for enabling execution of the electronic payment. That is, the computer system 130 determines the financial details of the payer and, optionally the payee, in accordance with the payment request. For example, the computer system determines the name and address details of the payer, together with the details of the payer’s elected credit card. In addition, the computer system may determine the details of the payee’s bank account for making the payment, in accordance with the payment request. The determined details may be stored locally on the computer system or retrieved from an external database that stores details of all payers and payees registered with the electronic payment system 100.

If the payment request is valid, the computer system 130 instructs the electronic payment based on the determined details and the payment request over a private network which is not accessible via the internet. Instructing the electronic payment may comprise making a credit card transfer, debit card transfer or any other form of wire transfer according to the payment request and determined details.

Subsequently, the financial institution of the payer makes a payment to the financial institution associated with the payee, according to the instructions received from the computer system. The payment may be in the form of a standard credit card transaction or in form of a direct account transfer. In addition, the financial institution of the payer sends a status indicator to the server 130. The status indicator indicates approval or disapproval of the electronic payment. Following receipt of the status indicator, the server 130 sends a confirmation message comprising the status indicator to the electronic equipment associated with the payee to confirm the payment. At this point the payment has been completed without the need for the payer to send personal financial information over the internet.

The various methods described herein may be implemented by one or more computer program products or computer readable media provided on one or more devices. The computer program product or computer readable media may include computer code arranged to instruct a computer or a plurality of computers to perform the functions of one or more of the various methods described herein. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer, on a computer readable medium or computer program product. The computer readable medium may be transitory or non-transitory. The computer readable medium could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. Alternatively, the computer readable medium could take the form of a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD.

An apparatus such as a computer may be configured in accordance with such code to perform one or more processes in accordance with the various methods discussed herein. Such an apparatus may take the form of a data processing system. Such a data processing system may be a distributed system. For example, such a data processing system may be distributed across a network. Some of the processes may be performed by software on a user device, while other processes may be performed by software on a server, or a combination thereof.

The software components associated with the component of the electronic payment system 100 for enabling an electronic payment transaction in accordance with the methods disclosed herein are set out below.

Payee software components

The software components associated with the payee 140 that enable an electronic payment transaction between a payer 130 and a payee 120 to be processed in accordance with the methods disclosed herein include an installer component, an order request generation component, a receiver component, an encryption component, and a POS-COM component. Each of these will described in turn.

Installer component

The installer component is used to install, configure and verify the software components installed on the payee’s electronic device 140 at step R1 of the registration process.

During installation the payee is asked to enter the received activation code along with his company registration number. In addition, the installer generates a public-private key pair associated with the payee. Subsequently, the installer constructs a message including identification data associated with the payee and the public key of the payee, as per the registration process at step R3.

When the server 130 receives the message, the server decrypts the message using the corresponding global private key of the electronic payment system 100. The server 130 then verifies that the financial details it received from the payee’s bank are associated with the payee. The verification process includes recalculating the MAC value associated with the message that the server received from the payer. The recalculation is based on the details the server received from the payee’s bank. Subsequently, the process involves determining if the recalculated MAC value corresponds to the MAC value contained in the message it received from the payee; as per step R3 of the registration process. If the calculated MAC value corresponds to the received MAC value, the installer component receives a ‘proceed’ command from the server 130 indicating that the registration has been accepted and that the downloaded software can be installed. In this case, the installer proceeds to install and configure the program files on the payee’s electronic device - as any other installer would do. Further, as described in the registration steps, if the MAC values are identical, the received public key of the payee is stored with the payee’s financial data.

If the calculated MAC value is different from the received MAC value, the installer on the payee’s device receives an ‘abandon’ command from the server 130. In the latter case, the installation could have been tampered with and accordingly the server 130 does not validate and register the payee. In this case, the payee is requested to re-download the software or to contact his bank.

Order request generation component

This function generates an order request as per the specifications set out in the payment process.

In addition, this function generates a QR bitmap holding the order request that will be scanned by the payer 150. The QR order request is structured in two areas; one with displayable text and field generation instructions and one area with fields that must be hidden for the payer. The input part of the interface towards the payee’s system is a simple XML text string, where the XML structure instructs the payer’s App with instructions on how to display and process the QR code. The hidden part of the QR code holds a digital signature of the displayable part, and thereby enforces the integrity of the QR code. The output part of the interface is a text string holding the full path to a subfolder where a bitmap file holding the generated QR code is written to. The payee’s system can simply embed the bitmap file in a web page, and display that web page to the payer.

Further; the QR code will contains a purchase expiry time. Based on this purchase expiry time the bitmap files holding the QR code will be deleted from the subfolder.

Receiver component

The Receiver component is configured to listen for messages from the server 130 such as confirmation messages in response to order requests that are sent to the payer 150 during a purchasing process. The Receiver is activated over a specific URL that accepts the messages as encrypted parameters. The received messages are encrypted by the server 130 using the public key of the payee that was sent to the server 130 during registration at step R3.

Messages received by the payee are decrypted by the payee using the encryption component installed on the payee’s device. Decryption is done using the private key of the payee. Decrypted messages, such as confirmation messages, contain two fields. The first field is the business response and provides an indication on whether the order request sent by the payee 140 to the payer 150 during a purchasing process has been ‘completed’ or ‘declined’. In the methods herein, this first response is associated with the status indicator of step P4. The second field is the sessionID that can optionally be included in the order request. The Receiver uses the sessionID to identify and pass the business response to the pending consumer session, where the response is displayed to the payer.

Encryption component

The encryption component is a dedicated module, which has an embedded PKI and is implemented in software. Furthermore, the encryption component is configured to integrate and leverage existing standard PKI solutions. The encryption component is also configured to handle all cryptographic operations, including OTP generation, MAC value calculations, and digital signature calculations. Additionally, the encryption component can use a hardware security module (HSM) associated with the payee’s device to perform encryption functions. POS-COM device

The POS-COM device is a component attached to, or integrated with, the payee’s electronic device. Examples of the payee’s electronic device include a server or an electronic point-of-sale terminal. The electronic point-of-sale terminal may be located in a store such as a supermarket. The POS-COM device holds an embedded computer providing QR code communication and/or short range wireless communication between the payee’s electronic device 140 and the payer’s electronic device 150. Short range wireless communication can use NFC, Bluetooth, infrared, or other short range wireless communication protocol. The POS-COM device is configured to send order requests to the payer’s electronic device 150. The POS-COM device may receive a order request from the cash register it is attached to and convey the order request to the payer’s electronic device 150. In addition, the POS-COM device is configured to receive messages sent to the payee from the server 130 or payer 150 at step P4 of the payment process and relay the received messages to the payer 150. For example, in the payment methods described herein a confirmation message sent from the server 130 to the payee’s electronic device 140 (e.g. the payee’s cash register) via the POS-COM device. Similarly, for example, in the payment methods described herein a confirmation message may first be sent from the server 130 to the payer 150 and then secondly sent from the payer 150 to the payee 140, optionally via the POS-COM device. In addition, the QR-NFC device is also configured to verify the digital signature associated with received messages.

Financial institution software components

The software components associated with the payee’s bank 170 and payer’s bank 160_that enable an electronic payment transaction between a payer 150 and a payee 140 to be processed in accordance with the methods disclosed herein include an installer component, an admin component, and an encryption component.

Installer component

The installer component installed in the payee’s bank and payer’s bankjs configured to enroll users such as payees and payers by executing the registration steps described herein such as steps R1 to R7. The installer component is also configured to allow users to make an electronic payment by executing the purchasing steps described herein such as steps P1 to P4. The installer component also contains identical components to the installer component installed on the payee’s device.

Admin component

The Admin component is configured to perform administration processes for its registered users such as registered payer’s and/or registered payees. This processing can be invoked from the bank’s online banking service and/or from a web GUI provided by the server 130. The Admin can enroll users by executing the registration steps described herein such as steps R1 to R7.

Using the web GUI, the Admin component controls a payee’s or payer’s access to the electronic payment system 100. When a ‘Suspend’ function is enabled, the Admin component disables the payee or payer from using the electronic payment system 100. When a ‘Resume’ function is enabled, the Admin component re-enables payee or payer access to the electronic payment system 100.

Further, with the web GUI, the bank can see the registration status of the payee and payer during the registration process of the payee and payer, respectively.

Encryption component

The encryption component is a dedicated module, which has an embedded PKI and is implemented in software. Furthermore, the encryption component is configured to integrate and leverage existing standard PKI solutions. The encryption component is also configured to handle all cryptographic operations, including OTP generation, MAC value calculations, and digital signature calculations. Additionally, the encryption component can use a hardware security module (HSM) associated with the bank’s electronic device to perform encryption functions.

The paver components

The software components associated with the payer 150 that enable an electronic payment transaction between a payer 130 and a payee 140 to be processed in accordance with the methods disclosed herein include an installer component, an enrolment component, a payment component, and an encryption component.

Installer component

The installer component is configured to enroll users such as payees 140 and payers 150 by executing the registration steps described herein such as steps R1 to R7. The installer component is also configured to allow users to make an electronic payment by executing the purchasing steps described herein such as steps P1 to P4. The installer component also contains generic installer functions such as those found in smartphone Apps.

Enrollment component

Each time the payer 150 starts a payment process using the electronic payment system 100, the payer’s device will check if the public-private key pair of the payer has been generated by checking the existence of the private key of the payer. If a private key of the payer is not found, the Enrollment component is invoked and a request for the OTP is displayed on the payer’s electronic device 150.

The Enrollment component implements the payer registration steps described herein such as the registration steps outlined in steps R1 to R7 of the registration process.

If a private key exists, the Pay function is invoked.

Payment component

The functions provided by the Payment component at the payer’s electronic device 150 comprise a first function and a second function. The first function invokes the communications module such as the QR scanner or the NFC, Bluetooth or Infrared communications module. The QR scanner is controlled either by the software installed at step R6 of the registration process or by third party software. During this process, the payment component provides text instructing the payer 150 to scan the QR code displayed on his computer 151. When the QR code has been scanned, the second function is invoked. The second function processes the order request and instructs the payer to select a payment instrument and select access settings to allow or deny the payee access to his/her details such as his/her name, address and/or e-mail address. The second function also processes the payment request.

The payment component is configured to implement the payer payment steps outlined in step P1 of the payment process.

Encryption component

The encryption component is a dedicated module, which has an embedded PKI and is implemented in software. Furthermore, the encryption component is configured to integrate and leverage existing standard PKI solutions. The encryption component is also configured to handle all cryptographic operations, including OTP generation, MAC value calculations, and digital signature calculations. Additionally, the encryption component can use a hardware security module (HSM) associated with the payer’s electronic device to perform encryption functions.

The server components

The software components associated with the server 130 that enable an electronic payment transaction between a payer 130 and a payee 120 to be processed in accordance with the methods disclosed herein include an admin component, an proxy payer component, a logger component, an environment component, and an encryption component.

Admin component

The Admin component is a process component configured to perform administration processes for users such as registered payer’s, registered payees, and registered bank. The functions performed are implemented according to the type of user. All user information stored on the server 130 is encrypted using FIPS 140 level-3 HSM boxes. The Admin component is configured to store a profile for each user (i.e. for each payee 140 and payer 150). For the enrolled users, Admin component is configured to keep their respective financial and identification data in a standard industry database. The identification data column in each table row may be in clear text or encrypted. For payer’s, the identification data columns include identification details of the payer such as the payer’s social security number and a hashed value of the payer’s social security number concatenated with the hashed value of the OTP. These payer details can be used as a user ID to identify the payer. For payees, the identification data column includes payee identification details such as the payee’s company registration number. These payee details can be used as a user ID to identify the payee. The Admin component is configured to receive and process messages from banks, payees and consumers in accordance with the registration and purchasing steps described herein such as steps R1 to R7 of the registration process and steps P1 to P4 of the payment process. proxvPaver component

The proxyPayer is configured to receive a payment request from the payer 150, validate the request and, upon successfully validation, perform the payment transaction according to the payment request and in accordance with purchasing steps described herein such as steps P1-P4 of the payment process. The transaction is either a credit card transaction, a direct debit transaction, or an account-to-account transfer. The message received from the payer 150 does not contain any data that can be used to directly build and execute the transaction, such as the payer’s credit card number. proxyPay is configured to use payer’s identifier, such as a hashed value of the payer’s social security number concatenated with the OTP, to validate the payment request from the payer 150. In addition, proxyPay is configured to use payer’s identifier such as the hashed value of the payer’s social security number concatenated with the hashed value of the OTP to select the payer’s identification data and/or financial data such as the payer’s credit card/ account entry required for the transaction and/or validation. Only the consumer’s financial and identification data containing details of the payer’s name, address, email and selected payment instrument (the selected credit card or account) will be decrypted and used for building the payment transaction. proxyPay is configured to send the transaction to the relevant acquirer, such as the payer’s bank, using a secure private network connection that is not connected to the internet such as a TLS or IPSec connection. Further, if the relevant acquirer is enrolled to the electronic payment system 100, the transaction will be encrypted using the acquirer’s public key prior to sending it. As soon as the transaction is transmitted, any temporary memory data banks containing details of the payment transaction is overwritten in order to erase credit card and account information from the server’s 130 temporary memory.

When the server 130 receives a response from the acquirer, as set out a step P4, proxyPayer will relay the response to the payee 150. For example, in the payment methods described herein a confirmation message confirming that the payer’s bank has completed the payment may be sent from the server 130 to the payee’s electronic device 140 (e.g. the payee’s cash register), optionally via the POS-COM device associated with the payee. Similarly, for example, in the payment methods described herein a confirmation message may first be sent from the server 130 to the payer 150 and then secondly sent from the payer 150 to the payee 140 (e.g. the payee’s cash register), optionally via the POS-COM device.

If the response from the acquirer is an approval of the payment transaction, the permitted payer details set in the payer’s access settings, such as the payer’s name, address, and email account, are sent with the response from the acquirer in the confirmation message, in accordance with the process at step P4. If the payer has not given permission for the payee to access certain details, these details are not sent to the payee in the confirmation message, in accordance with the process at step P4.

The proxyPayer component is configured to implement the registration steps described herein such as steps R1 to R7. The proxyPayer component is also configured to implement the purchasing steps described herein such as steps P1 to P4.

Logger component

The Logger function is an audit trial framework that logs all activities (e.g. enrollment activities, purchasing activities, and messaging activities) associated with the server 130.

The environment component

The environment component is configured to provide a highly secure environment. The perimeter security is configured to be enforced by a double layer of firewalls (one gateway level and one application level). The environment component is configured such that all network traffic inside the firewalls is based on IPsec (VPN). All stored data is, with the exception of database keys, encrypted by the environment component. Examples of database keys that could be used with the registration and purchasing steps described herein include the payer’s social security number, the payer’s company registration number, and the payee’s company registration number. Optionally, these examples of the database keys could be concatenated with the OTP and/or additionally represented as hashed values and/or encrypted. In this way, the environment component is configured to ensure that no information is stored in clear text. The cryptographic operations are implemented using specialized and tamper resistant hardware.

Encryption component

The encryption component is a dedicated module, which has an embedded PKI and is implemented in software. Furthermore, the encryption component is configured to integrate and leverage existing standard PKI solutions. The encryption component is also configured to handle all cryptographic operations, including OTP generation, MAC value calculations, and digital signature calculations. Additionally, the encryption component can use a FIPS140 level-3 hardware security module (HSM) associated with the bank’s electronic device to perform encryption functions.

In the methods set out herein, cryptographic techniques may be implemented. Such techniques may use a public key infrastructure (PKI) embedded in the components of the electronic payment system 100. The cryptographic keys may be unique to the electronic payment system and will not find use in any other context. Further, all cryptography is implemented in dedicated modules of each system component utilizing an application program interface (API) with abstracted functions. However, in other arrangements, the cryptographic technique implemented in the dedicated cryptographic modules may be replaced and/or modified to implement a custom PKI method. Accordingly, the electronic payment system is not limited to one type of encryption technique and may be adapted to implement other PKI based encryption techniques.

Also, in arrangements wherein a message is encrypted using a public key, the message may be encrypted using a generated symmetric key, and the generated symmetric key may be encrypted using the public key and appended to the message. Alternatively, the entire message may be encrypted using the public key.

The arrangement and process described above is just one implementation. Alternative implementations shall now be discussed. It should be appreciated that this is not an exclusive description of alternative implementations, but instead just some key examples in order to assist understanding of the breadth of the disclosure.

The records associated with the payer 150 may be stored locally on the computer system 130 or retrieved from an external database that stores details of all payers and payees registered with the electronic payment system 100.

Rather than use a QR code for step P1 of the payment process, the payee 140 may generate and use a barcode or any other optical machine-readable representation to communicate the order request to the payer 150. For example, the payee 140 may generate a barcode containing the order request.

While the example set out with reference to the Figures relates to online purchases, it will be appreciated that the system could be used for in-store purchases. In one such arrangement, the payee 140 at step P1 of the payment process sends the order request to the payer 150 via short-range wireless communication technology such as, for example, near field communication (NFC), Bluetooth (BT) or infrared (IR). That is, the electronic device associated with the payee 140 may communicate the order request to the electronic device associated with the payer 150 by electronically transmitting the order request to the payer. For example, an electronic point-of-sale terminal associated with the payee 140 may send the order request to a payer’s smartphone 150 via NFC. The computer system 130 may send data comprising the status indicator, such as a confirmation message, to the electronic equipment associated with the payer 150. Optionally, the electronic equipment associated with the payer 150 may subsequently send data comprising the status indicator to the electronic equipment associated with the payee 140. In such arrangements, there would not be a need for the further device 151 associated with the payer.

In one arrangement, the order request generated by the payee 140 may comprise any one or more of; a payment amount; a payee identifier; a list of payment instruments accepted by the payee for the electronic payment transaction; an expiry time; a URL containing a session identifier as a parameter to identify an address at which payment confirmation messages to the payee should be sent such as, for example, a netpoint; a request to access certain details associated with the payer; and/or a digital signature of the payee. In other arrangements, the digital signature of the payee may be a hash value based on the entire order request as generated by the payee 140. Alternatively or additionally, the digital signature of the payee may be a hash value based on any one or more of the items contained in the order request when generated by the payee 140.

The payment request sent from the payer 150 to the computer system 130 may comprise any one or more of the order request from the payee, a preferred payment instrument, preference settings indicating the access setting set by the payer, the payment amount, and/or a digital signature of the payer. The digital signature of the payer may be a hash value based on the entire payment request as sent by the payer. Alternatively or additionally, the digital signature of the payer may be a hash value based on any one or more of the items contained in the payment request as sent by the payer 150.

Additionally or alternatively, the payer identification details used to validate the payer’s payment request and/or the data sent from the payer’s bank to the server 130 during registration may be based on a user ID that is assigned to the payer during registration with the electronic payment system 100. The user ID of the payer may be based on the social security number of the payer, company registration number of the payer, and a one-time passcode. Optionally, the userlD may be based on a combination of these examples and/or a hash value of these examples. For example, the user ID may be a hashed value of the payer’s social security number concatenated with the hashed value of the OTP. In pseudo code, this is represented as H” = CalcHash(SocialSecurityNumber + H’(OTP)), where H’(OTP) = CalcHash(OTP)

Additionally or alternatively, the payee identification details used to validate the data sent from the payee’s bank to the server 130 during registration may be based on a user ID that is assigned to the payee during registration with the electronic payment system 100. The user ID of the payee may be based on the company registration number of the payee, the activation code, and a country code of the payee’s place of residence. Optionally, the userlD of the payee may be based on a combination of these examples and/or a hash value of these examples. For example, the user ID of the payee may be a hashed value of the payee’s company registration number concatenated with the activation code. In pseudo code, this may be represented as H” = CalcHash(registration number + H’(activation code)), where H’(activation code) = CalcHash(activation code)

Additionally or alternatively, the payee identification data in the order request and/or payment request may comprise the company registration number of the payee.

In the examples herein, the country code may be used as a routing parameter if the payee and server are connected to different servers. In this case, the server of the payee can route payment and registration requests to the server of the payer, based on the country code of the payer, in order to complete a payment or registration.

In the examples herein, the payment request may be encrypted based on industry standard encryption techniques, as are known in the art. Accordingly, the payment request may be sent and/or received by the equipment associated with the payee, equipment associated with the payer, computer system, payer’s bank, and/or payee’s bank using industry standard encryption techniques.

The electronic device associated with payer 150 may send the payment request to the computer system 130 over any other type of communications interface such as an internet connection instead of a cellular network. Transmission of the payment request over a cellular network may incorporate security technologies such as the Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

Alternatively or additionally, the equipment associated with the payer 150 may automatically select a preferred payment instrument based on pre-selected user preferences and/or historical payment selections.

In addition to sending the message comprising the status indicator at step P7 of the payment process, the computer system 130 may send the message to the electronic equipment associated with the payer 150. The payer may then subsequently relay the message to the payee via: short-range wireless communication such as NFC, Bluetooth and infrared; Wi-Fi; the internet; or optically. Furthermore, after receiving the message, the electronic device associated with the payee and/or payer may validate the data received from the computer system by, for example, validating the digital signature of the computer system.

The equipment associated with the payer may be a mobile telephone, network-enabled tablet or any other portable telecommunications device.

The equipment associated with the payee may be a server, cash register, or any other electronic point-of-sale device that is capable of communicating with the equipment associated with the payer, in accordance with the present disclosure.

The details comprising the payer’s financial and identification data may be received at the server 130 from one or more financial institutions associated with the payer, rather than one financial institution. For example, the payer’s social security number may be transmitted to the server 130 from a first financial institution associated with the payer, and the payers credit card details may be sent to the server from a second financial institution associated with the payer, wherein the first financial institution is different to the second financial institution.

While Figures 1 to 3 illustrate a central server 130 running the process, it will be appreciated that the functionality provided by the server 130 could be integrated within in one of two financial institutions or the merchant. In addition, in certain arrangements, different aspects of the server’s functionality may be distributed between different parts of the system such that the server is not required, or the server is only required to perform limited functionality.

The registration steps associated with the payer may be performed before, or in parallel, with the registration steps associated with the payee. In addition, there may be many merchants and consumers registered onto the system. The only requirement is that the payer 150 and payee 140 involved in a transaction have both registered with the system before the transaction takes place. However, it will be appreciated that the transaction could be initiated without one of the parties of the transaction being registered and the registration process could be carried out responsive to the initiation of the payment process.

It will be appreciated that in certain arrangements there is no need for the two electronic devices (150 and 151) associated with the payer. All of the functionality could be achieved by a single device. For example, in one arrangement only the electronic device 150 is utilised. In such an arrangement the electronic device is carrying out the online purchase and receives data from the payee that would otherwise have been received by the further electronic device 151 in Figure 1.

In each of the arrangements set out above, the system provides improved security for financial transaction over any other system available.

The methods described herein make online shopping safer by processing an electronic payment transaction between a payer and payee without the payer disclosing financial information such as credit card information over the internet. As a result, hackers are unable to steal a payer’s financial details by tapping their internet connection or by enforcing Trojans to be installed to a payee’s device and/or the payer’s device. In this way, online shopping is made safer.

Furthermore, with the methods described herein, the payer also does not disclose his/her personal details over the internet. In this way, online shopping is made even safer, fraud is reduced and user privacy is provided in a safe and reliable way.

Further still, there is provided a method for processing an electronic payment transaction between a payer and payee without the payer having to enter his/her personal and/or financial information each time they make a transaction. In this way, the method reduces manual input requirements and thereby provides a better user experience.

Claims

Claims:

1. A method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system, the method comprising: receiving, at the computer system, data from a financial institution associated with the payer over a secure private connection, the data comprising financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer, wherein the data is sent upon the financial institution receiving an authorisation message from the payer.

2. A method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system, the method comprising: sending, from the payer, an authorisation message to a financial institution associated with the payer, the authorisation message authorising the financial institution to send data to the computer system over a secure private connection, the data comprising financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer.

3. A method for enabling a computer system to manage processing of an electronic payment transaction between a payer and a payee without the payer disclosing financial information such as credit card information over the internet to the payee or to the computer system, the method comprising: sending, from a financial institution associated with the payer, data to the computer system over a secure private connection, the data comprising financial details associated with the payer for enabling the computer system to manage processing of an electronic payment from the payer, wherein the data is sent upon the financial institution receiving an authorisation message from the payer.

4. The method of any one of claims 1 to 3, wherein the data further comprises identification data associated with the payer.

5. The method of claim 1 or claim 4 when dependent on claim 1, wherein the method further comprises: receiving, at the computer system, identification data associated with the payer from the payer to validate the data received at the computer system from the financial institution associated with the payer.

6. The method of claim 1 or any one of claims 4-5 when dependent on claim 1, wherein the method further comprises verifying, at the computer system, that the financial details received from the financial institution associated with the payer are validated by the payer by comparing the identification data received from the payer with the identification data received from the financial institution.

7. The method of any one of claims 4 to 6 when dependent on claim 1, wherein the identification data associated with the payer includes data comprising one or more of a social security number associated with the payer, a location identifier associated with the payer such as the country code of the payer's place of residence, a one-time-password (OTP), a hashed one-time-password (OTP), and a hashed value of the payer's social security number concatenated with the hashed value of the OTP.

8. The method of claim 7 when dependent on claim 1, wherein a one-time-password (OTP) is generated by the financial institution associated with the payer and sent from the financial institution associated with the payer to the payer.

9. The method of any one of claims 1 to 8, wherein the data received at the computer system is encrypted.

10. The method of any one of claims 1 to 9, wherein data and messages sent to or from the payer are sent to or from an electronic device associated with the payer, respectively.

11. The method of any one of claims 1 to 10, wherein the financial details comprise one or more of the payer's credit card details, debit card details, or current account details.

12. The method of claim 1 or claims 4 to 11 when dependent on claim 1 wherein the processing, at the computer system, of an electronic payment transaction between the payer and the payee comprises: receiving, at the computer system, a payment request from the payer, the payment request identifying the electronic payment to be made from the payer to the payee and comprising identification data associated with the payer; validating, at the computer system, the payment request by verifying if the identification data received in the payment request is associated with the payer; if the payment request is valid, determining at the computer system details associated with the payer, the details enabling execution of the electronic payment from the payer to the payee according to the payment request; and instructing, at the computer system, the electronic payment based on the determined details and the payment request.

13. The method of claim 12 when dependent on claims 1 and 4, wherein verifying if the identification data is associated with the payer comprises comparing the identification data received in the payment request with the identification data received from the financial institution.

14. The method of claim 12 or claim 13, wherein the identification data received at the computer system from the financial institution and/or the determined details associated with the payer are stored on the computer system.

15. The method of any one of claims 12 to 14, wherein the identification data received from the financial institution and the determined details associated with the payer are linked to one another within the computer system.

16. The method of any one of claims 12 to 15, wherein the determined details associated with the payer comprises financial information associated with the payer.

17. The method of any one of claims 12 to 16, wherein the determined details associated with the payer comprises one or more of the payer's name, address, social security number, company registration number, and mobile phone number details.

18. The method of any one of claims 12 to 17, wherein the payment request is based on an order request originating from the payee.

19. The method of claim 18, wherein the order request is sent from the payee to the payer.

20. The method of claim 19, wherein an intermediate device, such as a computer terminal, associated with the payer obtains the order request from the payee and provides the order request to the payer.

21. The method of claim 20, wherein the order request is provided from the intermediate device to the payer via electronic communication such as Bluetooth, near field communication (NFC) or other short range wireless communication.

22. The method of claim 19, wherein the order request is provided from the intermediate device to the payer by displaying a QR code comprising the order request for the payer to read.

23. The method of any one of claims 12 to 22, wherein the instructing of the electronic payment is sent to the financial institution associated with the payer for the financial institution to make the electronic payment.

24. The method of any one of claims 12 to 23 further comprising: receiving, at the computer system, a status indicator from the financial institution, the status indicator indicating approval or disapproval of the electronic payment; and sending, from the computer system, the status indicator to the payee.

25. The method of claim 2 or any one of claims 4 and 9-11 when dependent on claim 2 further comprising: sending, from the payer, a payment request to the computer system , the payment request identifying the electronic payment to be made from the payer to the payee and comprising identification data associated with the payer.

26. The method of claim 3 or any one of claims 4 and 9-11 when dependent on claim 3 further comprising: receiving, from the financial institution associated with the payer, instructions instructing the electronic payment based on the determined details and a payment request, the payment request identifying the electronic payment to be made from the payer to the payee and comprising identification data associated with the payer and wherein the payment request is sent from the payer to the computer system.

27. A computer-readable medium comprising instructions that are executable by a processor to perform the method of any one of claims 1 to 26.

28. Apparatus comprising a processor and a memory, the memory storing instructions that are executable by the processor to perform the method of any one of claims 1 to 26.