GB2617327A

GB2617327A - Payment authorisation method and system

Info

Publication number: GB2617327A
Application number: GB2204724.5A
Authority: GB
Inventors: Selmani Gazmend
Original assignee: Individual
Current assignee: Individual
Priority date: 2022-03-31
Filing date: 2022-03-31
Publication date: 2023-10-11
Also published as: GB202204724D0; GB2617327A8

Abstract

A customer electronic device 12 communicates with a payment-controller electronic device to create a customer payment account and a unique payment authorisation identifier with a payment controller 14. The unique payment authorisation identifier may be alphanumeric or a biometric identifier. The customer 10 requests goods or services from a merchant 18, the merchant 18 having a merchant electronic device 20. The customer authorises payment to the merchant without use of a customer payment device by inputting the unique payment authorisation identifier into the merchant electronic device. The payment amount, merchant account data, and unique payment authorisation identifier are communicated to the payment-controller electronic device from the merchant electronic device 20. The unique payment authorisation identifier is verified and the payment controller 14 debits the customer payment account and makes a transfer to a merchant account.

Description

Payment Authorisation Method and System The present invention relates to a method of payment authorisation without requiring a customer payment device, and in particular to payment authorisation to a merchant in a bricks and mortar establishment, although other payment situations and locations may 5 be considered. The invention further relates to a payment authorisation system.

Customers can purchase goods or services from a merchant in a bricks and mortar premises using cash or payment devices. Typical payment devices may include prepaid, debit, or credit cards, a smart mobile telephone, or wearables. Such payment devices authorise or authenticate a customer's request to make payment from a customer payment account to the merchant. The customer's payment device interacts or is used as a counterpart to the merchant's payment system, known as a point of sale (POS) system. The POS system interacts with a payment card network processors, such as Visa (RTM) or Mastercard (RTM), to arrange debiting of a customer's payment account.

However, this requires a customer to carry cash or a payment device. This can be 15 inconvenient for the customer, and can result in loss or theft of the cash or payment device.

It would therefore be desirable to allow a customer to securely make a payment to a merchant without requiring cash or a customer payment device. In other words, it would be desirable to permit toolless payment authorisation.

The present invention seeks to provide a solution to these problems.

According to a first aspect of the present invention, there is provided a method of payment authorisation without requiring a customer payment device comprising: a) a customer using a customer electronic device to communicate with a payment-controller electronic device to create a customer payment account with a payment controller; b) the customer using the customer electronic device to create a unique payment authorisation identifier associated with the customer payment account, and communicating the payment authorisation identifier to the payment-controller electronic device; c) the customer requesting goods or services from a merchant in exchange for a payment amount, the merchant having a merchant electronic device; d) the payment amount and merchant payment-receiving account identification data being inputted to the merchant electronic device; and e) the customer authorising payment to the merchant without use of a customer payment device by inputting the unique payment authorisation identifier into the merchant electronic device which is communicated to the payment-controller electronic device along with the payment amount and merchant payment-receiving account identification data, the unique payment authorisation identifier being verified by the payment-controller electronic device, and the payment controller debiting the customer payment account and transferring payment to a merchant payment-receiving account associated with the merchant payment-receiving account identification data.

As such, a customer can purchase goods or services from a merchant without requiring a customer payment device, since the customer uses the merchant electronic device to enter the identifier and thereby authorise payment. This has the result that the customer is not required carry a customer payment device, which can be advantageous if the customer wishes to make a purchase after carrying out an activity during which is not convenient to carry a payment device, for example during exercise. Alternatively, the customer payment device may become lost, damaged, or run out of battery, or otherwise become inoperable. Additionally, since the customer creates the identifier using their electronic device (and is not assigned an identifier, for example), the customer may create an identifier which is easy to remember. This simplifies use of the method for the customer.

Additionally, the merchant is able to receive payment from customers without requiring card readers or other payment device readers. As such the merchant electronic device may not include such a reader. This can reduce the amount of equipment required by the merchant.

Furthermore, the payment controller is not required to issue payment devices, such as 25 credit cards, to the customer. This may reduce costs for the payment controller and the amount of material, such as plastic, waste. Therefore, the invention may have environmental benefits.

The merchant will be understood to be a provider of goods or services.

Preferably, the unique payment authorisation identifier may comprise letters, numbers 30 and/or symbols. As such, the identifier may be considered to be a password or a passcode. This may be preferable to some customers from a personal data-protection perspective, and may minimise an equipment requirement for a merchant.

Advantageously, the method may further comprise the step f) after step e) of the payment-controller electronic device deauthorising the unique payment authorisation identifier. As such, the unique payment authorisation identifier is effectively destroyed and may be considered to be a single-use identifier. The payment-controller electronic device may automatically deauthorise the identifier, or the customer may specifically request this. Such a feature promotes security and avoids the merchant or a third party becoming aware of the identifier and committing fraud. This step particularly applies if the payment authorisation identifier comprises letters, numbers and/or symbols. However, it will be appreciated that if the payment authorisation identifier is a biometric identifier, such as a facial representation, the payment authorisation identifier may still optionally be deauthorised. The customer may be provided the option of deauthorising either kind of unique payment authorisation identifier on the merchant electronic device when inputting the unique payment authorisation identifier. Alternatively, the customer may do this via the customer electronic device, for example establishing a setting where the unique payment authorisation identifier is deauthorised after each use by default.

In a preferable embodiment, the method may further comprise the step h) after step f) of the customer using the customer electronic device to create a new payment authorisation identifier associated with the customer payment account, and communicating the new payment authorisation identifier to the payment-controller electronic device. In the case of a biometric identifier, the customer may simply reauthorise the previously used identifier.

In a preferable embodiment, the method may further comprise the step g) after step b) of the payment-controller electronic device checking whether the customer payment authorisation identifier is identical to any of the pre-existing customer payment authorisation identifiers associated with customer payment accounts of the payment controller, and if the customer payment authorisation identifier matches a pre-existing customer payment authorisation identifier then the payment-controller electronic device communicates with the customer electronic device to request a new proposed customer payment authorisation identifier. Thus, the payment-controller electronic device ensures that the payment authorisation identifiers are unique.

Preferably, the merchant electronic device may run a web browser which has a webpage of the payment controller, the merchant payment-receiving account identification data, payment amount and payment authorisation identifier being entered onto the webpage.

As such, no specialised equipment is required for the merchant to participate in the payment authorisation method.

Beneficially, the payment authorisation identifier is a single data record and is the only data inputted into the merchant electronic device by the customer. Thus, the customer is not required to enter or remember multiple data records, for example a username in addition to a password. However, in some versions of the method it will be appreciated that the payment authorisation identifier comprising multiple data records may be preferred.

Advantageously, the merchant payment-receiving account is operated by the payment 10 controller. Therefore, the merchant payment-receiving account identification data may be a merchant identifier, since the merchant's bank details may already be registered with the payment controller.

Optionally, prior to step b) the payment-controller electronic device may generate a suggested payment authorisation identifier and communicates this from the payment-controller electronic device to the customer electronic device. This may assist the customer with generating a unique identifier. For example, the payment-controller electronic device may identify one or more identifiers which are not presently associated with a customer account. The customer may then select one of these identifiers to use as their payment authorisation identifier, or may use the suggested identifier as inspiration to generate a new identifier.

Preferably, the payment amount and merchant payment-receiving account identification data may be inputted to the merchant electronic device from a merchant point-of-sale device. This may allow for quicker and more convenient data entry into the merchant point-of-sale device, compared to manual data entry.

Advantageously, the payment amount and merchant payment-receiving account identification data may be inputted to the merchant electronic device via a keyboard, touchscreen, or microphone of the merchant electronic device. The microphone thereby allows the entry of the merchant payment-receiving account identification data via voice message.

Alternatively or additionally, the unique payment authorisation identifier may be a biometric identifier. This may be more convenient for the customer, since the customer may not be required to remember an identifier. Additionally, biometric reading may be quicker than password entry when purchasing goods or services.

Beneficially, the unique payment authorisation identifier may comprise a facial representation. Thus, the customer may use a camera or scanner of the customer electronic device, for example, to capture an image of the customer's face. This may then be communicated to the payment controller electronic device, in the same manner 5 as an identifier which comprises letters, numbers and/or symbols. When purchasing goods or services, the merchant may use a camera or scanner of the merchant electronic device to capture an image of the customer's face. This may then be verified at the payment controller electronic device using facial recognition software or similar. The payment controller may, for example, provide appropriate cameras or scanners to the 10 merchant. The facial representation may be code, such as encrypted code, which is representative of or generated from an image of the face, rather than an image as such.

However, although the facial representation is described as being sent to the payment controller electronic device, which is preferably via the internet, it will be appreciated that the facial representation or other biometrics may be verified without communication to the payment controller electronic device and therefore without internet access. This can be achieved by caching the payment controller system in the merchant electronic device, which may be achieved after the first approach to the payment controller electronic device or platform.

According to a second aspect of the invention, there is provided a payment authorisation 20 system specifically configured to carry out the method of the first aspect of the invention.

According to a third aspect of the invention there is provided a payment authorisation system comprising: a customer electronic device operated by a customer; a payment-controller electronic device operated by a payment controller; and a merchant electronic device operated by a merchant; the customer electronic device configured to communicate with the payment-controller electronic device to create a customer payment account with a payment controller and a unique payment authorisation identifier associated with the customer payment account; the merchant electronic device configured to communicate the unique payment authorisation identifier, a payment amount, and merchant payment-receiving account identification data to the payment-controller electronic device, and the payment-controller electronic device configured to verify the unique payment authorisation identifier so as to permit the payment controller to debit the customer payment account and transfer payment to a merchant payment-receiving account associated with the merchant payment-receiving account identification data, without use of a customer payment device.

The invention will now be more particularly described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows a representation of an embodiment of a method of payment authorisation in accordance with a first aspect of the invention; Figure 2 shows a display of a customer electronic device for creating a unique payment authorisation identifier, in accordance with a step of the first aspect of the invention; Figure 3a shows a display of a merchant electronic device for inputting a payment amount and merchant payment-receiving account identification data, in accordance with 10 a step of the first aspect of the invention; and Figure 3b shows a display of the merchant electronic device of Figure 2a for inputting a unique payment authorisation identifier in accordance with a step of the first aspect of the invention.

Referring firstly to Figure 1, there is shown a representation of a method 100 of payment 15 authorisation without requiring a customer 10 payment device in a merchant's premises.

The method 100 firstly comprises the step A of a customer 10 using a customer electronic device 12 to communicate with a payment-controller electronic device to create a customer payment account with a payment controller 14.

The customer electronic device 12 may include, for example, a smart mobile telephone, 20 a wearable, or other computing device.

The payment controller 14 may be a bank, another financial institution, and/or an organisation, such as a tech platform, which interfaces with a bank or other financial institution. The payment-controller electronic device may be a server or other computing device at the premises of, or otherwise controlled by, the payment controller 14. The customer electronic device 12 communicates with the payment-controller electronic device via a wired and/or wireless connection 16, for example via the internet. As such, the customer electronic device 12 is communicatively connected with the payment-controller electronic device.

The customer payment account will be understood to be a current or checking account 30 and/or a credit account. The customer may therefore deposit funds in the customer payment account, or request credit from the payment controller 14. The customer payment account is held by the payment controller 14, and is in the name of the customer 10. The customer payment account or customer payment account profile is opened in accordance with the highest Anti-Money Laundering (AML) standards and regulations.

It will be appreciated that the payment controller 14 may include a tech platform (which does not hold customer funds) which interfaces the customer 10 with a financial institution, such as a bank (which does hold customer funds). Alternatively, the payment controller may be solely the financial institution which interfaces directly with the customer 10.

The customer 10 may then use the customer electronic device 12 to create a payment authorisation identifier or payment authorisation identifier data associated with the customer payment account. The payment authorisation identifier is preferably unique, which is to say it is different to any other payment authorisation identifier associated with any customer payment account with the payment controller 14.

The payment authorisation identifier may comprise letters, numbers and/or symbols, and as such may be considered to be a password or passcode. As such, the creation of the identifier by the customer 10 may be via the customer 10 inputting a proposed password into the customer electronic device 12 using, for example, a keyboard or keypad of the customer electronic device 12. The customer 10 may enter the identifier in a data entry field 17, as shown in Figure 2a, and may be required to re-enter the identifier, to ensure the accuracy of the data entry.

Alternatively or additionally, the payment authorisation identifier may be a biometric identifier. In particular, the payment authorisation identifier may comprise a facial representation. As such the customer 10 may use a camera or other sensor or reader of the customer electronic device 12 to produce a facial representation. The method may also include a step of verifying the customer's identity. This may be achieved through an electronic Know Your Customer (eKYC) protocol. For example, the user may also be required to image a form of photographic identification, such as a driving licence or passport. Such an image or image data may also be transmitted to the payment controller electronic device, and then the customer's identity verified by the payment controller 14 identifying whether the person in the facial representation is the same as the person in the image of the photographic identification. Such verification may be done automatically or manually by an individual, and would be in accordance with electronic identification and trust services (el DAS) regulations.

Although a facial representation is preferred, it will be appreciated that other forms of biometric identifiers may be considered.

The payment authorisation identifier is communicated to the payment-controller electronic device. This communication may be in the same manner as previously described. The payment-controller electronic device thus receives the payment authorisation identifier from the client.

Since the payment authorisation identifier is preferably unique, the payment-controller electronic device may then verify or check that the payment authorisation identifier is unique. This may be achieved via the payment-controller electronic device checking whether the payment authorisation identifier is identical to any of the pre-existing payment authorisation identifiers associated with customer payment accounts of the payment controller 14. As such the payment-controller electronic device may have or have access to a database of payment authorisation identifiers stored on a memory device. This database can be queried to determine if any pre-existing payment authorisation identifiers matches the proposed payment authorisation identifiers.

If the payment authorisation identifier does not match any pre-existing payment authorisation identifiers, then the payment authorisation identifier is accepted and 20 associated with the customer payment account of the customer 10.

If the payment authorisation identifier matches a pre-existing payment authorisation identifier, then the payment-controller electronic device communicates with the customer electronic device 12 to request a new proposed payment authorisation identifier. As such the customer would repeat the payment authorisation identifier generation and submission process.

The above uniqueness verification steps may particularly apply if the identifier comprises letters, numbers and/or symbols. However, similar steps may also apply for the facial representation, which may prevent a customer 10 from creating multiple customer payment accounts.

To assist the customer in generating a unique identifier, the payment-controller electronic device may communicate to the customer electronic device 12 one or more suggested payment authorisation identifiers not associated with any customer payment accounts. The customer 10 may then select one of these identifiers, and/or use said identifier as inspiration for generating a suggested payment authorisation identifier.

In a further step B, the customer 10 may then enter a bricks and mortar establishment or premises of a merchant 18 who has a merchant electronic device 20. The merchant electronic device 20 may be a smart mobile telephone, a tablet, or another computing device, and is communicatively connected with the payment-controller electronic device. Such a connection 22 may be via the internet and may be wireless and/or wired. The merchant electronic device 20 would include a data entry means.

For example, the merchant electronic device 20 may include a keyboard or keypad, such as one provided on a touchscreen. Men entering the payment authorisation identifier on the merchant electronic device 20 using a keyboard, the typed characters would preferably not be seen, instead being replaced by dots or stars. This is to prevent the customer's 10 payment authorisation identifier from being determined by a third party.

Additionally, the merchant electronic device 20 may be prevented from recording the typed characters, for example by anti-keylogger software.

The merchant electronic device 20 may include a biometric reader, such as an appropriately configured camera. The camera may be configured to scan or read faces only within a range of one meter or substantially one meter. This is primarily to avoid unintentional scanning of a face of a person in the vicinity who may have a customer account with a facial unique identifier, and thereby avoid unintentionally debiting an unintended customer account. Additionally, such range limiting may protect the privacy of other persons in the vicinity. If the camera does detect more than one face in the field of view, the merchant electronic device 20 may not transmit the facial representation to avoid debiting of an unintended customer account.

The customer can then request goods and/or services from the merchant 18 in exchange for payment. The merchant 18 would provide the goods and/or services and request payment.

The merchant 18 may then access on the merchant electronic device 20 a webpage of 30 a website of the payment controller 14 via a web browser, or otherwise use appropriate software to communicate with the payment controller 14. An interface, such as that shown in Figure 2a, may then be displayed on the merchant electronic device 20. The interface may have at least two data entry fields, one entry field 24 requiring entry of the merchant payment-receiving account identification data, and one entry field 26 requiring the payment amount.

The merchant payment-receiving account identification data may include the merchant's 5 bank account number, sort code, card number, IBAN numbers, and/or BIC code, or similar identification numbers named differently in different countries. Alternatively, instead of entering the merchant 18 account details for each purchase, if the merchant 18 has already pre-registered with the payment controller 14, the merchant bank account details may already be pre-associated with the merchant electronic device 20. The 10 merchant payment-receiving account identification data details may therefore be the merchant's registration details which are entered or pre-entered into the merchant electronic device 20. The merchant 18 may have a payment receiving account with the payment controller 14 for receiving payment, although this is not necessarily required for use of the service.

The payment amount may be manually entered into the data entry field on the merchant electronic device 20, for example by using the keyboard or keypad. Alternatively, the payment amount may be directly imported via a point or sales device 28 such as an electronic till, cash register or automated money handling system.

The customer 10 may then authorise payment to the merchant 18 from their customer payment account. This is achieved without a customer payment device, since the merchant electronic device 20 is used. As such, only a single electronic device between the customer 10 and merchant 18 is required to be used to authorise payment from the customer 10.

The merchant 18 presents the merchant electronic device 20 to the customer 10. The merchant electronic device 20 may display the interface as shown on in Figure 3b, and may include a payment authorisation identifier data entry field 30 for a customer to enter their payment authorisation identifier, in the instance that the identifier is a password or passcode. The password or passcode may be entered using the keyboard or keypad, for example.

As shown in Figure 3b, the merchant electronic device 20 may also request that the customer 10 confirms if the payment authorisation identifier should be destroyed after use. In other words, whether the payment authorisation identifier should be disassociated or deauthorised with respect to the customer payment account The customer 10 may optionally request this by selecting a checkbox 32, for example.

Alternatively, in the event that the identifier is a biometric identifier, the merchant 18 may present a biometric reader to the customer 10. For example, the merchant 18 may image 5 the customer's face with a camera.

The payment amount, merchant payment-receiving account identification data and payment authorisation identifier is then communicated or transmitted to the payment-controller electronic device from the merchant electronic device 20.

In a further step C, the unique payment authorisation identifier is then verified by the payment-controller electronic device. This may be carried out by the payment-controller electronic device determining whether there is a customer payment account held by the payment controller 14 with that payment authorisation identifier. As such, the payment-controller electronic device may search through a database of payment authorisation identifiers associated with customer payment accounts.

Once the payment authorisation identifier is verified, the payment controller 14 or payment controller 14 electronic device debits the customer payment account and transfers payment 34 to a merchant 18 payment-receiving account associated with the merchant payment-receiving account identification data. This may be via an external bank transfer of funds, or an internal transfer of funds if the merchant 18 payment-receiving account is held by the same payment controller 14.

The payment controller electronic device may then communicate with the merchant electronic device 20 that the payment has been successful, and the customer may then leave the merchant's premises, having received the goods or services.

If so requested, or if configured to do so automatically, the payment controller 14 electronic device may then deauthorise or disassociate the payment authorisation identifier relative to the customer payment account. In this instance, the payment controller electronic device may then communicate with the customer electronic device 12 to request a new payment authorisation identifier, and the customer 10 may subsequently create and communicate the new payment authorisation identifier to the payment controller electronic device.

As described above, the customer payment authorisation identifier is preferably a single password, passcode, or other identification datum. However, it will be appreciated that in some instances the customer payment authorisation identifier may include multiple identification data. For example, the customer payment authorisation identifier may include a username and a password, passcode or biometric identifier.

It is therefore possible to provide a method of payment authorisation without requiring a customer payment device. The customer creates their own identifier associated with their account which is then transmitted to the payment controller. The customer can then authorise payment to a merchant without requiring a customer payment device since the merchant electronic device can be used to authenticate the customer's request for payment by transmitting the identifier, payment amount, and merchant account details to the payment controller.

The words 'comprises/comprising' and the words 'having/including' when used herein with reference to the present invention are used to specify the presence of stated 15 features, integers, steps or components, but do not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

The embodiments described above are provided by way of examples only, and various other modifications will be apparent to persons skilled in the field without departing from the scope of the invention as defined herein.

Claims

Claims 1 A method of payment authorisation without requiring a customer payment device comprising: a) a customer using a customer electronic device to communicate with a payment-controller electronic device to create a customer payment account with a payment controller; b) the customer using the customer electronic device to create a unique payment authorisation identifier associated with the customer payment account, and communicating the payment authorisation identifier to the payment-controller electronic device; c) the customer requesting goods or services from a merchant in exchange for a payment amount, the merchant having a merchant electronic device; d) the payment amount and merchant payment-receiving account identification data being inputted to the merchant electronic device; and e) the customer authorising payment to the merchant without use of a customer payment device by inputting the unique payment authorisation identifier into the merchant electronic device which is communicated to the payment-controller electronic device along with the payment amount and merchant payment-receiving account identification data, the unique payment authorisation identifier being verified by the payment-controller electronic device, and the payment controller debiting the customer payment account and transferring payment to a merchant payment-receiving account associated with the merchant payment-receiving account identification data.
2. A method of payment authorisation as claimed in claim 1, wherein the unique payment authorisation identifier comprises letters, numbers and/or symbols.
3 A method of payment authorisation as claimed in any one of the preceding claims, further comprising the step f) after step e) of the payment-controller electronic device deauthorising the unique payment authorisation identifier.
4 A method of payment authorisation as claimed in any one of the preceding claims, further comprising the step g) after step b) of the payment-controller electronic device checking whether the customer payment authorisation identifier is identical to any of the pre-existing customer payment authorisation identifiers associated with customer payment accounts of the payment controller, and if the customer payment authorisation identifier matches a pre-existing customer payment authorisation identifier then the payment-controller electronic device communicates with the customer electronic device to request a new proposed customer payment authorisation identifier.
A method of payment authorisation as claimed in any one of the preceding claims, further comprising the step h) after step f) of the customer using the customer electronic device to create a new payment authorisation identifier associated with the customer payment account, and communicating the new payment authorisation identifier to the payment-controller electronic device.
6 A method of payment authorisation as claimed in any one of the preceding claims, wherein the merchant electronic device runs a web browser which has a webpage of the payment controller, the merchant payment-receiving account identification data, payment amount and payment authorisation identifier being entered onto the webpage.
7 A method of payment authorisation as claimed in any one of the preceding claims, wherein the payment authorisation identifier is a single data record and is the only data inputted into the merchant electronic device by the customer.
8 A method of payment authorisation as claimed in any one of the preceding claims, wherein the merchant payment-receiving account is operated by the payment controller.
9 A method of payment authorisation as claimed in any one of the preceding claims, wherein prior to step b) the payment-controller electronic device generates a suggested payment authorisation identifier and communicates this from the payment-controller electronic device to the customer electronic device.
10. A method of payment authorisation as claimed in any one of the preceding claims, wherein the payment amount and merchant payment-receiving account identification data are inputted to the merchant electronic device from a merchant point-of-sale device.
11. A method of payment authorisation as claimed in any one of the preceding claims, wherein the payment amount and merchant payment-receiving account identification data are inputted to the merchant electronic device via a keyboard, touchscreen, or microphone of the merchant electronic device.
12. A method of payment authorisation as claimed in any one of the preceding claims, wherein the unique payment authorisation identifier is a biometric identifier.
13. A method of payment authorisation as claimed in claim 12, wherein the unique payment authorisation identifier comprises a facial representation.
14. A payment authorisation system specifically configured to carry out the method as claimed in any one of the preceding claims.
15. A payment authorisation system comprising: a customer electronic device operated by a customer; a payment-controller electronic device operated by a payment controller; and a merchant electronic device operated by a merchant; the customer electronic device configured to communicate with the payment-controller electronic device to create a customer payment account with a payment controller and a unique payment authorisation identifier associated with the customer payment account; the merchant electronic device configured to communicate the unique payment authorisation identifier, a payment amount, and merchant payment-receiving account identification data to the payment-controller electronic device, and the payment-controller electronic device configured to verify the unique payment authorisation identifier so as to permit the payment controller to debit the customer payment account and transfer payment to a merchant payment-receiving account associated with the merchant payment-receiving account identification data, without use of a customer payment device.