GB2620114A

GB2620114A - Electronic payment apparatus

Info

Publication number: GB2620114A
Application number: GB2209111.0A
Authority: GB
Inventors: John Hamilton Christopher
Original assignee: Blukite Group Ltd
Current assignee: Blukite Group Ltd
Priority date: 2022-06-21
Filing date: 2022-06-21
Publication date: 2024-01-03
Also published as: GB202209111D0

Abstract

A smart device, such as a smartphone, for conducting a financial transaction. The device has a first configuration in which an application displays account/financial information, and a second configuration in which the device is arranged to read an optically readable transaction authorisation code for verifying a financial transaction. The optically readable transaction authorisation code comprises human readable code, preferably as per ASCII or Unicode standards. The device may transition between the first and second configurations in response to a change in orientation of the device from portrait to landscape, or when a camera read mode displayed by the application is selected, or when the screen is double tapped. A method involves the smart device reading the transaction authorisation code from the display of a POS device. The code may be generated by a server and the transaction may be verified by comparing the code generated by the server with the code read by the smart device.

Description

ELECTRONIC PAYMENT APPARATUS

The present invention concerns electronic payment apparatus. More particularly, but not exclusively, this invention concerns electronic payment apparatus, and methods and systems for making electronic payments using human readable code.

Background of the Invention

There are various ways in which someone may pay for goods and services without the requirement for carrying cash, or the potential trust issues associated with issuing and honouring a cheque. The most widespread method is the use of a payment card, often with a person authentication step including a personal identification number (PIN), customer signature or biometrics. Recent developments in Near field communication (NEC) and radio frequency identification (RFID) have resulted in payment cards being used for contactless payment, where a card is presented to a reader and payment is automatically taken without the need for the person identification step. Smart devices, such as smart phones, smart tablets, and smart watches, are also being used in a similar way, making use of NFC techniques to allow users to make contactless payments by presenting the smart device to a suitable reader.

The payment industry is also seeing a significant shift towards optical based payment solutions to combat NFC deficiency's using Quick Response (OR). However, hereto, scanning both static and dynamic QR and Barcodes represent a cybersecurity risk to the user in that the content itself may contain harmful code or links to URL's which can lead to a loss of data, such as personal information, passwords, account numbers and card details. In both instances there is significant risk that fraudulent payments may be taken by criminals using card reading devices without the knowledge of the card/device owner, or via a criminal obtaining the data from a payment enabled smart device by use of embedded malware which maybe hidden in a two-dimensional optical code and invisible to the human eye.

The present invention seeks to mitigate the above-mentioned problems. Alternatively or additionally, the present invention seeks to provide an improved method and apparatus for making electronic payments.

Summary of the Invention

In one aspect of the present invention, there is provided an apparatus for conducting a financial transaction, the apparatus comprising: a smart device with an application, the smart device having a first configuration in which the application displays account information, and a second configuration in which the smart device is arranged to read an optically readable transaction authorisation code for verifying a financial transaction, wherein the optically readable transaction authorisation code comprises human readable code.

This arrangement provides apparatus for conducting a financial transaction with improved security. This is because the optically readable transaction authorisation code comprises human readable code, which prevents malware and other undesired data being incorporated into the transaction authorisation code without being visible and intelligible to the user and/or retailer. The transaction is thus safer.

Further, the requirement of a second configuration to read optically readable transaction authorisation code improves the security of the transaction because accidental reading of this code is mitigated -a change of configuration must occur/be effected by the user for code to be read.

As the apparatus is configured to read an optically readable transaction authorisation code, the apparatus is not vulnerable to skimming devices, such as those that use NFC and RFID communication methods. The transaction initiation code is a single use, unique code, Preferably, the optically readable transaction authorisation code is a single use code. Preferably, the optically readable transaction authorisation code is time limited. Thus, repeat transactions are not fraudulently authorised. The transaction initiation code may include an account number with other account determining data.

Preferably, the smart device is arranged to read the optically readable transaction authorisation code via a camera of the smart device.

In a preferrable arrangement, the transition between the first configuration and second configuration is effected by changing the orientation of the smart device, selecting a camera read mode displayed by the application or double tapping on a screen of the smart device.

Preferably, the optically readable transaction authorisation is generated by a remote server.

Preferably, in response to a transition between the first configuration and second configuration being effected the smart device is configured to communicate with the remote server and verify the financial transaction.

Preferably, the financial transaction is verified by comparing the transaction authorisation code read by the smart device with the transaction authorisation code generated by the server for the smart device.

The smart device may be configured such that the application is only opened in response to a unique security input by a user.

Preferably, smart device is a smart phone, point-of-sale device or computer. The smart device may be any suitable device, which can communicate via an electronic network, for example via Bluetooth <RTM>, WI-Fl, near field communication, radio frequency identification, 3G, 4G, 5G etc. In another aspect of the present invention, there is provided a method of conducting a financial transaction using a smart device, the method comprising: providing a smart device including an application, the application including financial data, a user opening the application in a first configuration, the first configuration such that financial information is displayed by the smart device, effecting the smart device into a second configuration such that an optically readable transaction authorisation code can be received by the smart device, the user presenting the smart device in the second configuration to a point of sale device having an optical display, the optical display displaying the optically readable transaction authorisation code, whereby a financial transaction between the smart device and point of sale device is authorised upon reading of the optically readable transaction authorisation code by the smart device, wherein the optically readable transaction authorisation code comprises human readable code.

According to another aspect of the present invention, there is provided a payment system, the payment system comprising: a smart device including an application; and a retail unit having a point of sale device with an optical display, wherein the point of sale device is arranged to display an optically readable transaction authorisation code; wherein smart device is arranged to read the optically readable transaction authorisation code in response to a change in configuration of the smart device; and wherein the optically readable transaction authorisation code comprises human readable code.

Preferably, the displayed optically readable transaction authorisation code forms part of a payment request that is displayed by the point of sale device and received by the smart device when the smart device reads the optically readable transaction authorisation code, the payment request including: the value of a transaction; and a request for an authorisation input from the user of the smart device.

Preferably, in response to the authorisation input from the user, the smart device is arranged to send the retail unit an electronic signal that represents transfer of funds between the smart device and the retail unit.

In an alternative arrangement, the smart device may make the electronic transfer of funds without requiring an authorisation input from the user of the smart device. This may be dependent on the size of the transfer of funds, with a threshold level under which an additional authorisation step is not required, and over which the additional authorisation step is required

Brief Description of the Drawings

Embodiments of the invention will now be described by way of example, with reference to the drawings in which:-Figure 1 shows an example process for setting up a customer account and configuring a smart device for making electronic payments; Figure 2 shows an example payment process; Figure 3 shows how a retailer may set up an account and process an electronic payment; Figure 4 shows an example electronic payment system; and Figures 5A and 5B show a smart device for making electronic payments.

Detailed Description

Figure 1 shows an example process for setting up an account and configuring a smart device for making electronic payments. In this example, the smart device is a mobile phone, but it could be any other suitable smart device, such as a tablet computing device or a smart watch.

The process comprises step 10, whereby a user (or payor) has an established payment account with a bank or e-money institution within which they hold funds accessible for immediate use. In step 12, the user downloads an application to their mobile device. The next step 14, the user, configures their personal profile within the application and passes through a pre-determined verification process. In step 16, the application may be configured to hold cash balances which may be transferred to the application and held separately from the user's day to day accounts. The user may transfer cash 18 from an external bank account to the application installed on the mobile phone or connect an external account to the application. The cash or balance is displayed in the application as virtual cash, as if the mobile phone device is an electronic wallet. Once the application has been loaded or connected with cash, the mobile phone is ready for use 20 as a payment apparatus. The user may also be issued with a conventional payment card, including an ISO 12 to 19 digit account number, an expiry date, and a card verification value (CCV). Alternatively, a bank or e-money institution may enable their own mobile banking application to utilise the electronic payment method of the present invention, thus allowing their customers to make or receive payments by way of a Software development Kit (SDK) or via an Application Programming Interface (API).

Figure 2 shows the process of a user using their mobile phone as a payment apparatus, and conducting a financial transaction using the phone. As a first step 22, the user opens the application on their mobile phone. This step may include an identification step such as a PIN being entered, or biometric data, such as a fingerprint or facial recognition, being verified.

In a first configuration of the mobile phone, the application is configured to display account information on a display of the mobile phone to the user, including the amount of cash present in the account, and one or more previous transactions which have taken place on the account. In this embodiment, the first configuration is a portrait orientation of the mobile phone.

In order to initiate a transaction, the mobile phone is transitioned into a second configuration. In this embodiment, the second configuration is a landscape orientation of the phone. The transition from the first configuration of the phone to the second configuration is effected (or caused) by the user moving or rotating the mobile phone from the portrait orientation into the landscape orientation 24. In another embodiment, the transition from the first configuration of the phone to the second configuration is effected by the user double tapping on the screen of the mobile phone or by selecting a camera read mode displayed by the application.

Upon transitioning (or switching) into the second configuration, the application is arranged to operate a camera of the mobile phone such that an optically readable transaction authorisation (ORTA) code can be read. In this regard, the application comprises an optical character recognition module for capturing (via the camera) and interpreting the ORTA code. In other words, the mobile phone is switched into a 'read' or 'receive' mode that is able to read (or receive) an ORTA code that is within range of the camera.

The payment for goods or services may occur between two parties in person using a mobile device/app, in a shop or other form of retailer or in an eCommerce transaction such as payments or purchases made online. In this embodiment, the user can purchase items from a retailer 28. A point of sale device of the retailer 28 is arranged to display an automatic payment request recognition data package (denoted henceforth as an 'APRR code') which relates to the item(s) being purchased by the user. The APRR code contains a unique ORTA code which is displayed on the point of sale device. More specially, the APRR code comprises information that relates to an automatic payment request and the ORTA comprises information that relates to the transaction. In some embodiments, there may be no APRR code as such, but rather the ORTA code only. In this case, automatic payment is requested by other suitable means, such as software instructions carried out by the point of sale device.

The optically readable transaction authorisation code consists of or comprises human readable code. In this document, 'human readable code' means encoding of data or information that can be naturally read by humans, such as the standards ASCII or Unicode. In some embodiments, the automatic payment request recognition data package also consists of or comprises human readable code.

B

The ORTA code is unique and relates to a particular transaction. The ORTA code is time limited (i.e., expires after a short duration of time), as well as size limited (i.e., the amount of bytes of the code is relatively small). Limiting the time duration of the ORTA code improves the overall security of a financial transaction.

Similarly, limiting the data size of the ORTA code also improves the overall security. In other, less secure arrangements, the ORTA code may not be time limited and/or size limited.

In this embodiment, the APRR code and ORTA code are generated by a remote server. In other embodiments, the APRR code and/or ORTA code may be generated by other devices (such as the point of sale device, mobile device or other suitable remote device(s) in the network).

With the APRR code (and thus the ORTA code) displayed on the point of sale device, the user then presents the mobile phone to a point of sale reader of a retailer 28, at which stage the mobile phone of the user reads the APRR code (including the ORTA code). Once the APRR code has been received by the mobile phone, the application causes the mobile phone to communicate with the remote server and verify the ORTA code. In this embodiment, this is achieved by comparing the ORTA code generated and sent to the point of sale device with the ORTA code received by the mobile phone (and transmitted to the remote server). In other embodiments, other suitable methods for verifying the ORTA code may be used.

The retailer enters the transaction value into their till or the point of sale device directly, and this value appears on the screen of the user's mobile phone, via an electronic signal sent from the point of sale device of the retailer to the mobile phone. The application is then arranged to request the user to confirm the transaction 30, adding a further level of security to the system. In an alternative embodiment, the user may enter the transaction value into their phone. Once the user has confirmed the transaction is legitimate, an electronic transfer of the virtual cash from the mobile phone application to a corresponding virtual account of the retailer takes place 32. The electronic transfer may be by any suitable electronic communication technique, including Bluetooth <RTM>, NFC, or RFID. The application running on the mobile phone logs the transaction, amends the funds available in the user account, and attaches a receipt to the transaction. This allows the user to identify the transaction when the application is configured in the first configuration, and the account details are provided on screen.

Figure 3 shows a process diagram for a retailer (or 'payee') conducting a transaction using the above described payment system. The retailer sets up an account with the account provider 34. As the account is set up, a point of sale device is provided to the retailer, the point of sale device also comprising a virtual wallet to contain funds transferred from the user's mobile phone to the retailer 36. The retailer may view the contents of their virtual wallet at any time, and also transfer the funds from the virtual wallet to a conventional high street bank account.

The transfer step 38 takes place instantaneously, and directly between the user s mobile phone and the retailer' s point of sale device. This is in contrast to conventional electronic payment systems, where the transaction is first reported to a debit/credit card provider (for example) and then a number of weeks later the retailer is sent the funds from the credit card provider. Therefore, the cash flow of the retailer is improved. The instant transfer of funds between the user and the retailer also removes the possibility of the retailer experiencing a charge back payment denial from the user against the retailer, as is possible in conventional payment arrangements.

Figure 4 is a schematic representation of the payment system 100 as described above, including representations of the various apparatus involved and the ways in which the apparatus interacts. The payment system 100 comprises a user 102, an account provider 104, a retailer 106, and a high street bank 108. The user 102 has a mobile phone 110 on which an application 112 has been installed. The account provider 104 has a server unit 114 which includes account information for all users of the payment system, including the identity of the various users and the funds available in their accounts.

A retailer 106 has a point of sale unit 116 linked which may communicate with a till 118. The point of sale unit comprises an optical display configured for displaying APRR codes (and the ORTA code). Alternatively or additionally, the point of sale unit may be configured for reading the ORTA code, barcodes or other designated input mechanisms. The various elements of the payment system 100 interact as follows. The mobile phone 110 of the user 110 is configured to wirelessly communicate with the server unit 114 of the account provider 104, which forms a network. The communication may include details of the transactions carried out using the mobile phone 110, and allow up to date account information, including funds available, to be displayed when using the application 112 on the mobile phone 110. The application 112 may be loaded with or linked to funds via a cash transfer from the high street bank 108, initiated by the user using a "load funds" function of the application 112.

When in the first configuration (such as a portrait orientation), the application 112 of the mobile phone is configured to display account information to the user. On transitioning the phone 110 into the second configuration (such as moving the phone into the landscape orientation), the application 112 is arranged to switch into a 'read mode' whereby the camera of the phone is activated (or enabled) for reading the APRR code (and thus the ORTA code), which is displayed by an optical display of the point of sale unit 116. As describe above, the unique APRR code includes the 12 to 19 digit account number of the user. In alternative arrangements, the application may arranged to read other types of suitable optically readable codes.

Upon entering the value of the sale into the point of sale unit 116 by the retailer, a request is made to the server unit 114 to generate the APRR code (which includes the ORTA code). Upon receiving the request, the server unit 114 is arranged to generate the APRR code and transmit the code to the point of sale unit 116. Upon receiving the APRR code, the display of the point of sale unit 116 is arranged to display the unique APRR code, which is then read by the camera of the phone. When the mobile phone camera is presented to (or within range of) the display of the point of sale unit, a transaction is initiated. The application is then arranged to transmit the read APRR code (including the ORTA code) to the server unit 114, which then verifies the integrity of the APRR code received by the mobile phone 110 by comparing the received code with the APRR code generated by the server unit 114 for the point of sale unit 116. In some embodiments, the server unit 116 is instead arranged to transmit the generated APRR code to the phone 110, which instead does the comparison.

During this comparison/verification process, the 12 to 19 digit code of the user (which forms part of the APRR code) is confirmed, confirming the user has as an account held with the account provider 104 with sufficient funds covering the value of the transaction. Once the point of sale unit 116 receives confirmation from the phone 110 that verification was successful, theThe point of sale unit 116 transmits the transaction value to the application 112. In alternative arrangements, the user may enter the transaction value directly into their mobile phone. The application 112 is then configured to request confirmation from the user that the transaction is legitimate. Assuming the response is that the transaction is legitimate, the application 112 then wirelessly transfers the funds from the application 112 to the retailer 106, completing the transaction. The wireless transfer may be by any suitable wireless electronic communication protocol or technique. The retailer may then send the money stored in the virtual wallet to a conventional high street bank 108.

Figure 5A shows the mobile phone 110 in a first portrait orientation (i.e., the first configuration) in which the application 112 displays various account information details, including but not limited to: the account number, the account name, the funds available, the funds spent that day, and the last few transaction details.

Figure 5B shows the mobile phone 110 in a second, landscape, orientation, in which the application 112 is arranged to read an APRR code (and thus read an ORTA code). When in the second landscape orientation (i.e., the second configuration) the mobile phone does not display personal account information such as that displayed when the mobile phone is in the first portrait orientation.

Whilst the present invention has been described and illustrated with reference to particular embodiments, it will be appreciated by those of ordinary skill in the art that the invention lends itself to many different variations not specifically illustrated herein. By way of example only, certain possible variations will now be described. The above-described systems concern payments made between a customer and a retailer. However, the system may be equally applicable to payments between two personal account holders (i.e., users), each having a phone including the application. Rather than the payment APRR code being read by a point of sale device, the camera on a mobile phone may be used to read the payment APRR code, and the cash transferred between the two mobile phones. Whilst APRR codes have been described, the skilled person will realise that any suitable optically readable code may be used. Alternatively, the ORTA code may be sent via a Payee and a Payor in the form of a link, by other electronic means, such as a text message, email or other social media platform.

Where in the foregoing description, integers or elements are mentioned which have known, obvious or foreseeable equivalents, then such equivalents are herein incorporated as if individually set forth. Reference should be made to the claims for determining the true scope of the present invention, which should be construed so as to encompass any such equivalents. It will also be appreciated by the reader that integers or features of the invention that are described as preferable, advantageous, convenient or the like are optional and do not limit the scope of the independent claims. Moreover, it is to be understood that such optional integers or features, whilst of possible benefit in some embodiments of the invention, may not be desirable, and may therefore be absent, in other embodiments.

Claims

CLAIMS1. An apparatus for conducting a financial transaction, the apparatus comprising: a smart device with an application, the smart device having a first configuration in which the application displays account information, and a second configuration in which the smart device is arranged to read an optically readable transaction authorisation code for verifying a financial transaction, wherein the optically readable transaction authorisation code comprises human readable code.
2. Apparatus as claimed in claim 1, wherein the optically readable transaction authorisation code is a single use code.
3. Apparatus as claimed in claim 1 or 2, wherein the optically readable transaction authorisation code is time limited.
4. Apparatus as claimed in any preceding claim, wherein the smart device is arranged to read the optically readable transaction authorisation code via a camera of the smart device.
5. Apparatus as claimed in any preceding claim, wherein a transition between the first configuration and second configuration is effected by changing the orientation of the smart device, selecting a camera read mode displayed by the application or double tapping on a screen of the smart device.
6. Apparatus as claimed in any preceding claim, wherein the optically readable transaction authorisation is generated by a remote server.
7. Apparatus as claimed in any preceding claim, wherein in response to a transition between the first configuration and second configuration being effected the smart device is configured to communicate with the remote server and verify the financial transaction.
8. Apparatus as claimed in claim 7, wherein the financial transaction is verified by comparing the transaction authorisation code read by the smart device with the transaction authorisation code generated by the server for the smart device.
9. Apparatus as claimed in any preceding claim, wherein the smart device is configured such that the application is only opened in response to a unique security input by a user.
10. Apparatus as claimed in any preceding claim, wherein the smart device is a smart phone, point-of-sale device or computer.
11. A method of conducting a financial transaction using a smart device, the method comprising: providing a smart device including an application, the application including financial data, a user opening the application in a first configuration, the first configuration such that financial information is displayed by the smart device, effecting the smart device into a second configuration such that an optically readable transaction authorisation code can be received by the smart device, the user presenting the smart device in the second configuration to a point of sale device having an optical display, the optical display displaying the optically readable transaction authorisation code, whereby a financial transaction between the smart device and point of sale device is authorised upon reading of the optically readable transaction authorisation code by the smart device, wherein the optically readable transaction authorisation code comprises human readable code.
12. A payment system, the payment system comprising: a smart device including an application; and a retail unit having a point of sale device with an optical display, wherein the point of sale device is arranged to display an optically readable transaction authorisation code; wherein smart device is arranged to read the optically readable transaction authorisation code in response to a change in configuration of the smart device; and wherein the optically readable transaction authorisation code comprises human readable code.
13. A payment system as claimed in claim 12, wherein the displayed optically readable transaction authorisation code forms part of a payment request that is displayed by the point of sale device and received by the smart device when the smart device reads the optically readable transaction authorisation code, the payment request including: the value of a transaction; and a request for an authorisation input from the user of the smart device.
14. A payment system as claimed in claim 13, wherein, in response to the authorisation input from the user, the smart device is arranged to send the retail unit an electronic signal that represents transfer of funds between the smart device and the retail unit.