EP3374951A1 - Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité - Google Patents

Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité

Info

Publication number
EP3374951A1
EP3374951A1 EP16781485.4A EP16781485A EP3374951A1 EP 3374951 A1 EP3374951 A1 EP 3374951A1 EP 16781485 A EP16781485 A EP 16781485A EP 3374951 A1 EP3374951 A1 EP 3374951A1
Authority
EP
European Patent Office
Prior art keywords
payer
payee
computer system
payment
details
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP16781485.4A
Other languages
German (de)
English (en)
Inventor
Robert Elgaard
Jesper SCHARFF
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sdc As
Original Assignee
Sdc As
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sdc As filed Critical Sdc As
Publication of EP3374951A1 publication Critical patent/EP3374951A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3265—Payment applications installed on the mobile devices characterised by personalisation for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0641—Shopping interfaces

Definitions

  • 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.
  • 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.
  • e-commerce transactions 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.
  • SSL Secure Sockets Layer
  • Another proposal is to use a web fraud detection system that looks for unusual behaviour in a user's transaction activities.
  • 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.
  • 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 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.
  • 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 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.
  • 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.
  • 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.
  • 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
  • OTP one-time-password
  • OTP hashed one-time-password
  • a hashed value of the payer's social security number concatenated with the hashed value of the OTP.
  • a one-time-password 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.
  • the data and messages sent to or from the payer may be sent to or from an electronic device associated with the payer, respectively.
  • 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, CW 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.
  • 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.
  • 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.
  • 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.
  • electronic communication such as a Bluetooth, near field communication (NFC) or other short range wireless communication.
  • 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.
  • the intermediate device such as a computer terminal
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 illustrates an electronic payment system in accordance with the present disclosure
  • Figure 4 illustrates a smartphone associated with a payer displaying user selectable options in accordance with a payment request received from a payee.
  • a consumer i.e. a payer
  • a merchant's i.e. payee's
  • 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.
  • 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.
  • 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 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 1 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.
  • 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.
  • the communications module is a short range communications module.
  • 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.
  • 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.
  • FIG. 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.
  • a payer e.g. consumer
  • a payee e.g. merchant
  • 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.
  • 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.
  • 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.
  • 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.
  • the transmitted data is encrypted using public key infrastructure (PKI) cryptographic techniques, as are known in the art.
  • PKI public key infrastructure
  • 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.
  • the payee 140 downloads and installs the software from the server, as per the instructions at step R1 .
  • the payee 140 enters the activation code that was received from the payee's bank 170 into the software.
  • 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.
  • MAC message authentication code
  • 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.
  • 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.
  • MAC message authentication code
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • OTP hashed one-time-password
  • the hashed one-time-password 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.
  • the transmitted data is encrypted using public key infrastructure (PKI) cryptographic techniques, as are known in the art.
  • PKI public key infrastructure
  • 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.
  • the server 130 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 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.
  • 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 payer enters his social security number and the OTP into the app.
  • 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.
  • MAC message authentication code
  • 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.
  • the server 130 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.
  • 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.
  • 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.
  • the server 130 includes the public key of the payer in the database entry and links it to the data associated with the payer.
  • 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.
  • 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).
  • TLS transport layer security
  • the missing information message and the payment profile message may be sent separately or together as one message.
  • 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.
  • 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.
  • the server 130 sends a message to the payer 150 requesting the payer to contact his/her bank for registration assistance.
  • the payee's electronic device 140 sends a registration request to the payee's bank 170.
  • 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.
  • the identifier may be based on a company registration number and/or an activation code.
  • 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.
  • 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.
  • this registration process comprises, the payer's electronic device 150 sending a registration request to the payer's bank 160.
  • 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.
  • the data may be transmitted over an IPSec protected connection or a 2-way SSL protected connection.
  • 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.
  • 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.
  • FIG. 3 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.
  • a payer uses his computer 151 to selects goods to purchase from a payee's website.
  • the payer indicates that he would like to purchase the goods using the electronic payment system 100 described herein.
  • 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.
  • 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.
  • the payee's smartphone 150 scans the QR code using the smartphone's camera, as illustrated in Figure 4 at step 405.
  • 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.
  • 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.
  • a request from the payee to access information associated with the payer such as the payer's identification data.
  • the order request may request permission to access details of the payer's name, address and email address.
  • 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.
  • 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.
  • the payer enters his pin code and taps 'OK' to confirm the access settings and the selected payment instrument.
  • preference information indicating the payer's access settings may be included in the payment request sent from the payer 150 to the server 130.
  • 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 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 .
  • 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.
  • the payer 150 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).
  • TLS Transport Layer Security
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the relevant financial information and/or identification information associated with the payee may also be obtained.
  • the server 130 obtains the bank account details of the payer that were stored in the database entry associated with the payer during registration
  • the server 130 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.
  • 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.
  • the payer's bank sends a status indicator to the server 130, indicating whether the transaction request has been accepted or declined.
  • the payer's bank 160 accepts the transfer request, it makes the electronic payment to the payee's bank 170.
  • the payer's bank sends a status indicator to the server 130 indicating that the transfer request has been approved.
  • 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.
  • 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.
  • the payer's bank 160 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.
  • the server receives the status indicator, the server sends a confirmation message to the payee 140 containing the status indicator.
  • the confirmation message does not contain payer information that the payer granted access to in the payer's access settings.
  • the merchant 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payee is asked to enter the received activation code along with his company registration number.
  • 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.
  • the server 130 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.
  • 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.
  • the installer on the payee's device receives an 'abandon' command from the server 130.
  • the installation could have been tampered with and accordingly the server 130 does not validate and register the payee.
  • the payee is requested to re-download the software or to contact his bank.
  • This function generates an order request as per the specifications set out in the payment process.
  • 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.
  • 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.
  • 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.
  • 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.
  • HSM hardware security module
  • the POS-COM device is a component attached to, or integrated with, the payee's electronic device.
  • 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.
  • 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.
  • 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.
  • 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.
  • the QR-NFC device is also configured to verify the digital signature associated with received messages.
  • 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.
  • 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.
  • 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.
  • the Admin component controls a payee's or payer's access to the electronic payment system 100.
  • the Admin component disables the payee or payer from using the electronic payment system 100.
  • the Admin component re-enables payee or payer access to the electronic payment system 100.
  • the bank can see the registration status of the payee and payer during the registration process of the payee and payer, respectively.
  • 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.
  • HSM hardware security module
  • 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.
  • 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.
  • 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.
  • the Pay function is invoked.
  • 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
  • the QR scanner is controlled either by the software installed at step R6 of the registration process or by third party software.
  • the payment component provides text instructing the payer 150 to scan the QR code displayed on his computer 151.
  • 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.
  • 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.
  • HSM hardware security module
  • 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.
  • 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.
  • 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.
  • 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.
  • proxyPayer 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.
  • proxyPay is configured to use payer's identifier such as the hashed value of the payer's social security number
  • 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.
  • proxyPayer 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • HSM hardware security module
  • cryptographic techniques may be implemented. Such techniques may use a public key infrastructure (PKI) embedded in the components of the electronic payment system 100.
  • PKI public key infrastructure
  • the cryptographic keys may be unique to the electronic payment system and will not find use in any other context.
  • all cryptography is implemented in dedicated modules of each system component utilizing an application program interface (API) with abstracted functions.
  • API application program interface
  • the cryptographic technique implemented in the dedicated cryptographic modules may be replaced and/or modified to implement a custom PKI method.
  • the electronic payment system is not limited to one type of encryption technique and may be adapted to implement other PKI based encryption techniques.
  • 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.
  • the entire message may be encrypted using the public key.
  • 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.
  • 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.
  • the payee 140 may generate a barcode containing the order request.
  • 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).
  • NFC near field communication
  • BT Bluetooth
  • IR infrared
  • 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.
  • 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.
  • 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.
  • 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.
  • a payment amount a payee identifier
  • a list of payment instruments accepted by the payee for the electronic payment transaction such as, for example, a netpoint
  • 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.
  • the digital signature of the payee may be a hash value based on the entire order request as generated by the payee 140.
  • 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.
  • 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.
  • the userlD may be based on a combination of these examples and/or a hash value of these examples.
  • 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.
  • the userlD of the payee may be based on a combination of these examples and/or a hash value of these examples.
  • the payee identification data in the order request and/or payment request may comprise the company registration number of the payee.
  • the country code may be used as a routing parameter if the payee and server are connected to different servers.
  • 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.
  • 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).
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • 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.
  • 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.
  • 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.
  • 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.
  • Figures 1 to 3 illustrate a central server 130 running the process
  • the functionality provided by the server 130 could be integrated within in one of two financial institutions or the merchant.
  • 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.
  • 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.
  • financial information such as credit card information over the internet.
  • 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.
  • 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.
  • 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 reduces manual input requirements and thereby provides a better user experience.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé, un appareil, un système et un support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité. L'invention porte sur un procédé permettant à un système informatique de gérer le traitement d'une transaction de paiement électronique entre un payeur et un bénéficiaire sans que le payeur ne divulgue des informations financières telles que des informations de carte de crédit sur Internet au bénéficiaire ou au système informatique. Le procédé consiste à recevoir, au niveau du système informatique, des données en provenance d'un établissement financier associé au payeur par le biais d'une connexion privée sécurisée. Les données comprennent des détails financiers associés au payeur pour permettre au système informatique de gérer le traitement d'un paiement électronique par le payeur et sont envoyées lorsque l'établissement financier reçoit du payeur un message d'autorisation.
EP16781485.4A 2015-11-13 2016-10-14 Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité Ceased EP3374951A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1520087.6A GB2544341A (en) 2015-11-13 2015-11-13 A method, apparatus, system, and computer readable medium for processing an electronic payment transaction with improved security
PCT/EP2016/074794 WO2017080755A1 (fr) 2015-11-13 2016-10-14 Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité

Publications (1)

Publication Number Publication Date
EP3374951A1 true EP3374951A1 (fr) 2018-09-19

Family

ID=55132781

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16781485.4A Ceased EP3374951A1 (fr) 2015-11-13 2016-10-14 Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité

Country Status (3)

Country Link
EP (1) EP3374951A1 (fr)
GB (1) GB2544341A (fr)
WO (1) WO2017080755A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL2019997B1 (en) * 2017-11-30 2019-06-07 Paycheckout Holding B V A method of authorizing a payment request by a cloud based platform and a server arranged for supporting said method
EP3502994A1 (fr) * 2017-12-22 2019-06-26 Mastercard International Incorporated Procédé et système de notifications fiables
DE102018117038A1 (de) * 2018-07-13 2020-01-16 Matthias Hermanns Verfahren zur Durchführung authentifizierter Zahlungen mit einem mobilen Endgerät des Käufers
CN110705983B (zh) * 2019-09-29 2023-10-03 腾讯科技（深圳）有限公司 扫码支付处理的方法、装置、设备及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2572227C (fr) * 2004-06-25 2017-03-07 Ian Charles Ogilvy Procede, appareil et systeme de traitement de transactions
US20140297533A1 (en) * 2011-11-13 2014-10-02 Millind Mittal System and method of electronic payment using payee provided transaction identification codes

Also Published As

Publication number Publication date
GB201520087D0 (en) 2015-12-30
GB2544341A (en) 2017-05-17
WO2017080755A1 (fr) 2017-05-18

Similar Documents

Publication Publication Date Title
US11127016B2 (en) Unique code for token verification
US20220318799A1 (en) Systems And Methods For Using A Transaction Identifier To Protect Sensitive Credentials
RU2663476C2 (ru) Защищенная обработка удаленных платежных транзакций, включающая в себя аутентификацию потребителей
CN105556553B (zh) 安全的远程支付交易处理
CN113011896B (zh) 使用安全元件的安全远程支付交易处理
JP5940176B2 (ja) ハブアンドスポークｐｉｎ確認
US20180150830A1 (en) System, process and device for e-commerce transactions
US20150302409A1 (en) System and method for location-based financial transaction authentication
WO2016130764A1 (fr) Autorisation de transfert homologue de demandes numériques
US20200273031A1 (en) Secure end-to-end online transaction systems and methods
EP3374951A1 (fr) Procédé, appareil, système et support lisible par ordinateur permettant de traiter une transaction de paiement électronique avec une meilleure sécurité

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180219

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1261002

Country of ref document: HK

17Q First examination report despatched

Effective date: 20200102

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20220221