WO2023281451A1

WO2023281451A1 - Contactless payment methods and systems

Info

Publication number: WO2023281451A1
Application number: PCT/IB2022/056318
Authority: WO
Inventors: Roger BUKURU
Original assignee: Lipa Payments (Pty) Ltd
Priority date: 2021-07-09
Filing date: 2022-07-08
Publication date: 2023-01-12
Also published as: ZA202400549B

Abstract

A computer-implemented method, system, and computer program product for contactless payments. The method performed at a first computing device includes: adopting a role of payee or a role of payor in a payment transaction; establishing a Bluetooth Low Energy (BLE) data connection with a second computing device, wherein the second computing device adopting the other of the role of the payor or payee in the payment transaction; and exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value from which or to which payment is to be made, the token being obtained for submission to a payment gateway for processing the payment transaction.

Description

CONTACTLESS PAYMENT METHODS AND SYSTEMS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application number 2021/04795 filed on 9 July 2021 , which is incorporated by reference herein.

FIELD OF THE INVENTION

This invention relates to methods and systems enabling payment by means of contactless processes between computing devices.

BACKGROUND TO THE INVENTION

Contactless payment methods enjoy widespread use in a world that is increasingly transacting cashless.

Traditional non-cash payment methods like magnetic strip or chip payment cards require some form of physical interaction. In some scenarios, the customer hands the card to the merchant, who inserts or swipes the card using a card payment terminal. This creates a first physical contact, as the card is eventually handed back to the customer. The customer may also be required to key in a PIN onto the card payment terminal. This creates a second physical contact, where the customer is required to physically interact with a payment terminal touched by hundreds of customers before. The global COVID-19 pandemic has placed such methods under the spotlight, as it creates a risk of spreading disease.

Besides such health considerations, which is a hot topic at the time of writing, contactless payments are also much more convenient and may enable a payment to be concluded faster than conventional payment methods.

Examples of non-contact payment methods include Near-Field Communication-based (NFC) payment methods. Remaining with a card-based method as example, it has become standard for payment cards to be provided with a radio-frequency identification (RFID) tag, which may be read by an NFC-enabled payment terminal. The customer places the card in close proximity to the payment terminal to enable a data exchange. NFC-enabled smartphones may be used in a similar manner, with various payment facilities providing support for NFC payment. In this scenario, the user places their NFC-enabled smart phone in close proximity with the payment terminal, which enables a data exchange. In most of these contactless scenarios, the merchant is equipped with a payment terminal, which may allow various payment methods, including traditional magnetic strip cards, chip cards, RFID cards, and the like. These may also generally be referred to as a point of sale (POS) terminal or payment card terminal.

The requirement for such a payment terminal may be excluding parts of the economy. For example, informal trade (also referred to as “street trade”) could benefit from cashless payment. Fewer people carry cash on their person, and street traders may miss out on possible business for the simple reason of not having cashless payment facilities. As the world is increasingly becoming cashless, this sector of the economy will face increasing pressure. In 2015, informal traders contributed approximately 5.2% of South Africa’s gross domestic product (GDP). Similarly, informal trade constitutes a considerable portion of the economy of other developing countries.

The Applicant considers there to be scope for improvement. The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.

SUMMARY OF THE INVENTION

According to an aspect of the present invention there is provided a computer-implemented method performed at a first computing device and comprising: adopting a role of payee or a role of payor in a payment transaction; establishing a Bluetooth Low Energy (BLE) data connection with a second computing device, wherein the second computing device adopting the other of the role of the payor or payee in the payment transaction; and, exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value from which or to which payment is to be made, the token being obtained for submission to a payment gateway for processing the payment transaction.

The method may include a pre-transaction method of: consuming a software development kit for an application at the first computing device; and providing a secure connection channel between the application a backend server providing the payment gateway and including assess to a token vault for maintaining the BLE tokens. The backend server may provide an attestation service and the method includes determining a security status of the application using the attestation service.

The method may include handling asynchronous notifications on BLE connection events, user interface events, and online transaction result events. Handling asynchronous notifications may include implementing callback interfaces with the callback interfaces allowing asynchronous communication of results of BLE connection events once completed. Handling asynchronous notifications may include using a blocking queue to serially run BLE connection events.

The method may include dynamically creating a GATT server instance to handle a payment request and resolve this with an online payment processing.

The method may include a second computing device submitting the token to the payment gateway includes: transmitting a payment authorisation request to the payment gateway, the request including a payor token, a payee token, and a payment amount; receiving a payment authorisation response indicating an approval or denial of the payment request; and sending an indication of the approval or denial of the payment request via the BLE data connection to the first computing device.

Establishing the BLE data connection may include: starting a BLE advertisement; and accepting a BLE data connection with the second computing device, the second computing device having performed a BLE scan, discovered the BLE advertisement, and initiated the BLE data connection.

Establishing the BLE data connection may include: starting a BLE scan; discovering a BLE advertisement of the second computing device; and initiating a BLE data connection with the second computing device, the second computing device accepting the connection. Discovering a BLE advertisement of the second computing device and initiating a BLE data connection may include calculating a physical distance between the first and second computing device; determining that the distance between the first and second computing communication is less than a payment region threshold distance; and initiating the BLE data connection.

According to another aspect of the present invention there is provided a system including a first computing device including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the first computing device comprising: a role component for adopting a role of payee or a role of payor in a payment transaction; a BLE component for establishing a BLE data connection with a second computing device, wherein instruction having been received on the second computing device to be the other of the role of the payor or payee in the payment transaction; and, a data exchange component for exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value at a payment gateway from which or to which payment is to be made, the token being obtained for submission to the payment gateway for processing the payment transaction.

The system may include a second computing device in the form of a peer computing device to the first computing device, wherein the second computing device including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the second computing device comprising a role component for adopting the other of a role of payee or a role of payor in a payment transaction.

The system may include a second computing device in the form of point of sale device, wherein the second computing device including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the second computing device comprising a role component for adopting the other of a role of payee in a payment transaction.

The system may include a backend server in communication with the first computing device via a secure communication channel, wherein the backend server provides a payment gateway including assess to a token vault for maintaining the BLE tokens. The payment gateway may include or provide access to a payment service backend that can handle open and closed loop transactions.

The first computing device may include: a user interface component configured to prompt a user for a selection between either performing the role of payee or the role of payor, receiving a selection input from the user, and determining the selection of the user to be the role of payee or that of payor; a data exchange component arranged to exchange a payor token, a payee token, and a payment amount; a payment component configured to send a payment authorisation request to a payment gateway, the request including the payor token, the payee token, and the payment amount, and configured to receive a payment authorisation response indicating the approval or denial of the payment request; and the data exchange component being further arranged to send an indication of the approval or denial of the payment via the BLE data connection to the other device.

The first computing device may include: a token storage component configured to store a payor token associated with a store of value, and a payee token associated with a store of value to which a payment can be credited.

The first computing device may include a distance determining module for discovering a BLE advertisement of the second computing device and initiating a BLE data connection and including: calculating a physical distance between the first and second computing device; and determining that the distance between the first and second computing communication is less than a payment region threshold distance.

The user interface component may be arranged to display data representing an advertiser derived from a discovered BLE advertisement, receiving input selecting the advertiser, and a data connection with the advertiser.

According to a further aspect of the present invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: adopting a role of payee or a role of payor in a payment transaction; establishing a BLE data connection with a second computing device, wherein the second computing device adopting the other of the role of the payor or payee in the payment transaction; and exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value at a payment gateway from which or to which payment is to be made, the token being obtained for submission to the payment gateway for processing the payment transaction.

According to a further aspect of the present invention there is provided a software development kit for a contactless Bluetooth Low Energy (BLE) payment service for providing payment functionality to an application on a computing device, the software development kit being a computer program product comprising a computer-readable medium having stored computer- readable program code comprising: a plurality of central mode components for providing functionality to the application to perform the role of a payor in a transaction over a BLE connection; a plurality of peripheral mode components for providing functionality to the application to perform the role of a payee in a transaction over the BLE connection; a profile component for providing functionality for a profile including a BLE token for a store of value used in a transaction, wherein the BLE token forms part of the transaction data provided over the BLE connection between a central role device and a peripheral role device; and a notification handling component for providing functionality for handling asynchronous notifications on BLE connection events, user interface events, and online transaction result events for the application. The software development kit may include an online communication component for providing a secure communication from the application to a backend server providing a payment gateway and including assess to a token vault for maintaining the BLE tokens.

The software development kit may include a payment protocol component for handling a message exchange between a central device and a peripheral device and a message exchange between a peripheral device and an online payment processing.

The online payment processing may include using an external payment processing system or a custom processing system.

The peripheral mode components may include an advertiser application programming interface (API) for initiating BLE advertising to provide a BLE connection; and the central mode components may include a locator application programming interface (API) for initiating BLE scanning to locate an advertised BLE connection.

The central mode components may include: a Generic Attribute Profile (GATT) client API for connection to a peripheral device; and a transaction API for initiating a transaction with the peripheral device and receiving a result of the transaction; and the peripheral mode components may include: a Generic Attribute Profile (GATT) server API for initiating a transaction from the peripheral device and communication with a backend server.

The notification handling component may include implementing callback interfaces in the application with the callback interfaces allowing asynchronous communication of results of BLE connection events once completed. The notification handling component may include an operation queue component for using a blocking queue to serially run BLE connection events.

The software development kit may include a payment processing component for dynamically creating a GATT server instance to handle the payment request and resolve this with an online payment processing.

The software development kit may include a payment payload component for providing the transaction data in a message payload for communication via the BLE connection, wherein the message payload is convertible between binary format and ASCII for transport.

The software development kit may include a distance determining component for determining a payment region within which a BLE connection is made. The software development kit may include a plurality of BLE interface components providing multi platform integration with device Bluetooth capabilities.

The software development kit may be provided for one of: a mobile device in the form of a custom application or an extension to an existing application; or a point-of-sale device in the form of a kernel application.

Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

Figure 1 is a schematic diagram of an embodiment of an exemplary system for facilitating contactless payment;

Figure 2A is a block diagram showing an example embodiment of a software development kit for providing the described functionality to a computing device;

Figure 2B is a block diagram showing an example embodiment of functional units of a computing device;

Figure 3 is a block diagram of an embodiment of an exemplary system for facilitating contactless payment;

Figure 4A is a schematic diagram of an exemplary GATT server;

Figure 4B is a table illustrating an exemplary structure of a payment authorisation request and response;

Figure 5A is a flow diagram of an example embodiment of an aspect of the described method of providing contactless payment; Figure 5B is a flow diagram of an example embodiment of another aspect of the described method of providing contactless payment;

Figure 5C is a flow diagram of an alternative example embodiment of the aspect of the described method of Figure 4B;

Figure 6A is a swim-lane flow diagram of a method of performing a payment;

Figure 6B is a swim-lane flow diagram of a method of performing a payment and an adaptation of that of Figure 4; and

Figure 7 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Example embodiments of payment methods, systems and computer program products are described below for providing Bluetooth Low Energy (BLE) contactless mobile payments.

A software development kit (SDK) is described that provides a BLE payment functionality as a mobile payment contactless acceptance solution where the contactless functionality is performed using the BLE interface that is native to and embedded in a commercial Bluetooth enabled off the shelf mobile device (such as a smartphone or tablet). The SDK provides location based payment- acceptance capabilities that plug into a custom payment gateway ecosystem or an external payment gateway in order to process Bluetooth enabled payments.

The SDK provides a BLE payment functionality to a final application (such as a banking application or a dedicated application), abstracting the handling of different BLE functionalities and online transaction processing. The application will receive asynchronous notifications on key BLE events, user interface events, as well as transaction result events.

In one embodiment, the BLE payment function provided by the SDK may be peer-to-peer where the payments are made between two mobile devices with one acting as a payee and one acting as a payor. Each of the mobile devices may optionally have functionality provided by the SDK to act as both a payee and a payor. The SDK may be multi-platform enabled such that it be used in iOS, Android and Web applications.

In another embodiment, the BLE payment function provided by the SDK may operate between a mobile device and a point of sale (POS) device with the SDK provided as a kernel application that can be loaded on a POS terminal.

The transactions are processed online using a payment protocol described below, that interacts with a back-end or payment gateway, in order to resolve the transaction online. The transactions use a token. Tokens or tokenization, in the context of data security, comprises the substituting of sensitive data with a non-sensitive equivalent, referred to as a “token”. The token has no extrinsic or exploitable meaning or value, but is merely a reference, identifier, or pointer that may be used to map back, look up, or retrieve the sensitive data associated with the token. The sensitive data may be stored in a secure data vault (e.g. a secure database, etc.) provided by the payment system, accessible only to the secure system administering the data vault. The token may, for example, be used as a key in a database record mapped to the original sensitive data.

In an example embodiment of a method, the method may be performed between mobile devices of users. At a high level, the methods described herein may for example include, at a first mobile device: receiving an instruction to perform the role of payee or the role of payor in a payment transaction; establishing a BLE radio-frequency (RF) data connection with a second mobile device, wherein instruction having been received on the second mobile device to be the other of the role of the payor or payee in the payment transaction; and, exchanging data with the second mobile device via the BLE data connection such that one of the first mobile device or second mobile device obtains a token from the other of the second mobile device or the first mobile device. The token is associated with a store of value at a payment gateway from which or to which payment is to be made. The token is obtained for submission to the payment gateway for processing the payment transaction.

Without imposing limitation, such a mobile device may be a smartphone, tablet, wearable device (smart watch, etc.), and the like. The mobile device may be programmed with instructions provided by the SDK to enable it to execute the steps of the method. The instructions may be integral to an operating system of the relevant mobile device, may be incorporated in a native application installed on the device, or may be made available by a third party for download and installation from an application repository. Such third-party application may be provided by financial institutions, and the instructions to perform the method may be incorporated into a banking application, for example.

The mobile device may be provided with a user interface through which information and prompts are presented to a user, and through which the user may provide input. The user may be prompted to make a selection between participating in a payment transaction in the role of payee, or in the role of payor. The method therefore provides the user with a choice of making payment or receiving payment on the same device. The user may input their selection via the user interface and the selection may be determined based on the input provided. For example, the mobile device may provide the user with a transaction options menu, which may present the user with graphic buttons representing the selection of performing payment, or receiving payment, respectively.

Payment by definition involves a payee and a payor, and a second user (or at least a second mobile device) may also be involved in the transaction. Where selection had been made to transact as payor, the second mobile device will act as payee, and vice versa. Similarly as aforesaid, a prompt for the selection of the role of payor or payee may be presented on the second mobile device, and selection input made to participate in the payment transaction in the capacity as the other or the payor or payee made on the first mobile device. A peer-to-peer BLE radio frequency (RF) data connection may be established with the second mobile device.

The mobile device may store one or more payor token, and may store one or more payee token. The storage of these tokens may be done locally on the data storage or memory of the mobile device. Each payor token may be associated with a store of value of the payor. For example, a first payor token may be associated with a payment card payment facility, a second payor token may be associated with a wallet, a third payor token may be associated with a virtual card, etc. Each payee token may be associated with a store of value of the payee to which the requested payment must be credited. For example, a first payee token may be associated with a cheque account, a second payee token may be associated with a payment card account, etc.

To be able to conclude a payment transaction, the relevant payment gateway (described in more detail below) must know the source facility of the payment, and the destination. The payment gateway must therefore be provided with both the payor token representing the relevant facility from which payment is made, and the payee token representing the relevant account or facility to which payment must be made.

The method by which the token is generated, and the mapping between the original data and token, must be such that none of the original data may be derived from the token value by means of direct attack, cryptoanalysis, side channel analysis, token mapping table exposure or brute force techniques. The token may therefore be (or partly consist of) a randomly generated number, for example. In some embodiments, the token is a cryptographic token configured for cryptographic verification. For example, the token may be signed (or encrypted) using a cryptographic key known only to the secure system such that tokens received from mobile devices may be validated (or decrypted) using the cryptographic key. The token may be static (e.g. a “use many” token) or dynamic (e.g. single-use token). Only the secure system hosting and/or administering the secure data vault can tokenize data to create tokens or detokenize back to redeem sensitive data, and only under strict security controls. Tokenization may be used to safeguard sensitive data such as, bank account information, financial statements, medical records, criminal records, and other types of personally identifiable information.

Tokenization may be used in payment card processing. The Payment Card Industry (PCI) Security Standards Council defines tokenization as a process by which the primary account number (PAN) is replaced with a surrogate value called a token. De-tokenization is the reverse process of redeeming a token for its associated PAN value. In the present case, the payor token and payee token may be used in the same or similar way in which the source store of value and destination store of value details are replaced with the surrogate payor token and payee token, respectively.

Data is exchanged via the BLE data connection such that at least one of the first mobile device or second mobile device is in possession of the payor token associated with a store of value of the payor, the payee token associated with a store of value of the payee to which the requested payment must be credited, and the payment amount.

In the scenario where the mobile device (in this case being a first mobile device) receives selection to act as payor in the payment transaction, depending on the particular embodiment implemented in the method, the first mobile device may either receive the payee token from the second mobile device; or may send the payor token to the second mobile device. Similarly, an exchange and approval of the payment amount may be exchanged between the two mobile devices. The same may apply in the scenario where the first communication device receives selection to function as payee in the payment transaction.

The mobile device that, through this exchange, comes into possession of both the payor token and the payee token, as well as the payment amount, may send a payment authorisation request to a payment gateway. The request may include the payor token, the payee token, and the payment amount.

The payment gateway may then engage with the issuer (i.e. the financial institution or bank that maintains the payor’s store of value) and the acquirer (i.e. the financial institution or bank that maintains the payee’s store of value) to broker the exchange of funds. In some embodiments, the present payment methods and systems may be implemented in a closed-loop system. That is to say that the issuer and acquirer are the same financial institution. In such a case, the payment gateway may merely be a back-end system of the relevant financial institution. In other embodiments, the present payment methods and system may be implemented in an open-loop system and the payment gateway may determine if the payments are allowed to be processed by an external payment gateway and/or external payment processing system.

The relevant mobile device may receive a payment authorisation response indicating the approval or denial of the payment request back from the relevant payment gateway. Indication of the approval or denial of the payment may then be sent to the other device via the RF data connection.

Figure 1 shows a schematic diagram of an example embodiment of an exemplary system (100) facilitating the present payment systems and methods. The system includes a first mobile device (102) and the second mobile device (104) that will participate as the payor and payee in the payment transaction. The first and second mobile devices (102, 104) may both consume an SDK with the payment functionality provided to either a custom application or an existing application on the device such as that of a payment card issuing organization. In the present example, the mobile devices (102, 104) are both smartphones. In other embodiments, the payee device may be a point of sale (POS) device which consumes or is provided with a kernel application provided by the SDK.

Each of the mobile devices has a mobile application (103) installed thereon. The mobile application (103) may be a payment application and may for example be provided by the relevant user’s financial institution. In some scenarios, for example in a closed-loop implementation, each device executes its own instance of the same mobile application (103). For example, the same mobile application may be downloaded and installed by each device from an application repository. In other scenarios, for example in an open-loop implementation, each device may execute a different mobile application (e.g. in cases where each user has a different financial institution), in which case each of the applications may implement the same SDK so as to be compatible for interacting with each other to make and receive payments as described herein. In such an open-loop environment, the different applications may be able to exchange payments with each other with the backend server acting as the verification mechanism of the token and hence processing the payment. In an open-loop environment using an external payment processing, the different applications may exchange payments with each other with an external payment system processing the payment.

The first mobile device (102) has a user interface which is shown to prompt a user to make a selection between participating in a payment transaction in the role of payee, or in the role of payor. In the present example, the user interface is a touch screen that presents two graphic buttons providing the option to “make payment”, or “receive payment”. In the present example, the selection to “make payment” has been made by the user of the first mobile device (102), as is illustrated by the thick border around the relevant button.

Similarly, the second mobile device (104) is shown to prompt the making of a selection between participating in a payment transaction in the role of payee, or in the role of payor. The selection to “receive payment” has been made by the user of the second mobile device (104), as is illustrated by the thick border around the relevant button.

Both the first and second mobile devices (102, 104) are equipped with a contactless element (106) that is configured to establish a BLE data connection. A BLE data connection may be established between the two mobile devices (102, 104). In the present example, the RF receiver/transmitters (106) are Bluetooth receiver/transmitters, and the BLE data connection is a peer-to-peer RF data connection between two similar mobile devices (102, 104). In an alternative embodiment, the second device may be a dedicated POS terminal device that may only be able to play the role of a payee.

Referring back to Figure 1 , the mobile device (102) may store one or more payor tokens, and may store one or more payee tokens. Figure 1 illustrates that the first communication device stores a token (110). This token is a payor token (110), which is a surrogate representing the store of value from which the user of the first mobile device (102) wishes to make payment. For example, the user may wish to make payment from a wallet (and may make such a selection from a subsequent menu provided on the user interface). The payor token (110) may therefore represent the user’s wallet payment facility. Similarly, the second mobile device (104) may store one or more payee and/or payor tokens. Figure 1 illustrates a payee token (112), representing the account to which payment must be credited.

Data is exchanged via the BLE data connection (108) such that at least one of the first mobile device (102) or second mobile device (104) is in possession of the payor token, the payee token, and the payment amount. The device in possession of all these data items may then initiate a payment authorisation request (114) to a remote backend server (114). The backend server (114) may be hosted by a payment service provider or financial institution.

In the scenario where the first mobile device (102) receives selection to act as payor in the payment transaction, depending on the particular embodiment implemented in the method, the first mobile device may either receive the payee token from the second mobile device (104); or may send the payor token to the second mobile device. Similarly, an exchange and approval of the payment amount may be exchanged between the two mobile devices. The same may apply in the scenario where the first communication device (102) receives selection to act as payee in the payment transaction. Various role players in this exemplary system may be in communication with each other via a communication network. In the present example, the communication network is the internet (105). The first and second mobile devices (102, 104) may be connected to the internet (105) via a mobile communication network (107). The mobile devices (102, 104) may therefore communicate by means of any mobile communication technology (including 5G-, 4G-, or 3G-technology, and the like) with the mobile communication network (107) which, in turn, connects these devices to the internet (105).

The mobile device that, through this exchange, comes into possession of both the payor token and the payee token, as well as the payment amount, may send a payment authorisation request to a payment gateway (116). In the exemplary scenario illustrated in Figure 1 , the second mobile device (104) has selected the role as payee, is acting as the GATT server (or BLE server / peripheral device), and is the device that will perform communication with the backend server (112). As mentioned above, the present example embodiment may have an intermediate backend server (114) which may perform a number of the back-end functions during the payment request process.

The backend server (114) may incorporate or be in secure data communication with a secure token vault (115). The token vault (115) stores a mapping between the surrogate token values, and the sensitive information relating to the store of value or facility with which the relevant token is associated. The non-sensitive token may therefore be used to lookup information such as the PAN of the relevant account to which the token relates. The PAN may then be provided to other role-players downstream to complete the payment transaction. The backend server (114) may also perform a number of further administrative and security-related functions pertaining to tokens. The backend server (114) may issue tokens during an enrollment process (described in further detail below). The backend server (114) may also validate tokens, including during attestation steps as described in further detail below. The backend server (114) may also revoke tokens. This may be done periodically in order to renew tokens from time to time for security reasons, on instruction (for example if a security breach is reported), or if the validation of a token fails.

A payment gateway (116) is one such role-player with which the back-end server (114) is in data communication. The payment gateway (116) may broker the exchange of funds between the issuer (120) and the acquirer (122). In some embodiments, the backend server (114) and payment gateway (116) may be provided by the same entity, or the backend server (114) may also perform the functionality of payment gateway (116). These alternative architectures may be particularly relevant in closed-loop systems where the issuer (120) and acquirer (122) are the same financial entity (or bank). In such cases, the issues (120), acquirer (122), payment gateway (116) and backend server (114) illustrated in Figure 1 may be under the control of the same entity, which may perform all the functions and roles of each of these entities described herein.

BLE data connections used defined profiles in the form of specifications of how a computing device works in a particular application using BLE data connections. The low energy application profiles are based on the Generic Attribute Profile (GATT) that is a general specification for sending and receiving short pieces of data, known as attributes, over a low energy link.

Referring to Figure 2A, a block diagram shows an example embodiment of an SDK (210) providing BLE payment functionality to computing devices (250). A computing device (250) may be a mobile device (102, 104) (such as a smart phone or tablet) or may be a POS terminal.

A computing device (250) to which the functionality of the SDK may be provided may include a processor (251) for executing the functions of components, which may be provided by hardware or by software units executing on the computing device (250). The software units may be stored in a memory component (252) and instructions may be provided to the processor (251 ) to carry out the functionality of the components. The computing device (250) may include a hardware user interface (253). The computing device (250) may include a BLE module (255) for Bluetooth communication including BLE data communication. The computing device (250) may include cellular communications module (254), particularly if it is a mobile device (102, 104).

The computing device (250) includes an application (260) that may be entirely provided by the SDK (210) or may be an existing application (such as a banking application) that includes additional functionality provided by the SDK (210). This is illustrated as the SDK functionality (262). The application (260) may also include a custom application functionality (261).

In the embodiment of the computing device (250) being a POS terminal, the application (260) may be a kernel application that can be loaded on the POS terminal.

The SDK (210) provides a high-level abstraction interface for a contactless payment transaction to be performed via BLE, including online authorization. The SDK (210) provides a payment functionality to the application (260), abstracting the handling of different BLE functionalities and the online transaction processing. The application (260) will be enabled to receive asynchronous notifications on key BLE events, user interface events, as well as transaction result events.

An example SDK functionality (262) when processing a transaction, may include performing the following key functionalities: • Providing a channel of communication over Bluetooth between the central acting device (sender) and the peripheral acting device (receiver);

• Allowing a central device (sender) ability to search for receivers, and send transaction data once connected via Bluetooth;

• Allowing the peripheral device (receiver) to advertise its signal so that it can be found and thereafter allowing it to receive transaction information over Bluetooth from a central device (sender);

• Passing attestation health-check data about the backend server and the application/SDK to the back-end monitoring system.

The components described below of the SDK (210) may be in the form of application programming interfaces (APIs) or other software components for providing the functions of the component to an application (260) on a computing device (250).

The SDK (210) may be multi-platform enabled such that it can be used on iOS, Android and Web applications and therefore provides an Android Bluetooth interface (231 ), an iOS Bluetooth interface (232) and a Web Bluetooth Interface (233). A BLE component (230) is configured to provide BLE data transfer via the Bluetooth interfaces (231 , 232, 233) that may be arranged to perform a BLE advertisement and accept a BLE data connection request, or to perform a BLE scan for a BLE advertisement, discovering an advertiser, and requesting a BLE connection with the advertiser.

The SDK (210) may include SDK APIs (220) providing function to the application (260). The SDK (210) may include a plurality of central mode components for providing functionality to the application (260) to perform the role of a payor in a transaction over a BLE connection and a plurality of peripheral mode components for providing functionality to the application to perform the role of a payee in a transaction over the BLE connection. An application (260) may consume the SDK (210) including the functionality of both roles of payor and payee. In some embodiments, an application may only use the functionality for one role, for example, at a POS terminal where only the role of payee is required.

The SDK APIs (220) may include a GATT server component (221), and a GATT client component (222) to provide the GATT server and client functionality to the application (260) for BLE data transfer. The SDK APIs (220) may include a BLE profile component (223) configured to uniquely identify the computing device (250) when performing a transaction and includes managing a BLE token associated with the computing device (250). The SDK APIs (220) may include an advertiser component (225) and a locator component (224) to provide functionality for advertising and scanning for advertisement to form a BLE data connection. The SDK APIs (220) may provide definitions that relate to the sender side (central mode) role and those that relate to the receiver side (peripheral mode) role. Such definitions are elaborated on below. The SDK APIs (220) may also include a transaction component (226) responsible for initiating a contactless BLE transaction over the BLE connection and waiting for this to be resolved online.

The GATT server component (221) may be configured to be activated when the BLE component (230) is configured as the BLE peripheral device, performing BLE advertising. The GATT client component (222) may be configured to be activated when the BLE component (230) is configured as the BLE central device, performing BLE scanning. The BLE component (230) may work in conjunction with the GATT client and server components (221 , 222) to establish and manage a BLE data connection.

The SDK (210) may include further components relating to the operation of the BLE payment transactions. Some of these components relate to the operation of the application (260) with the computing device (250). The SDK (210) may include a Bluetooth activation component (216) to provide an ability to turn the BLE module (255) on and off at the computing device (250). This may be used, for example, if it is determined to be off before advertising and scanning during operation of the SDK functionality (270). The SDK may also include a location activation component (217) to provide an ability to turn on location services at the computing device (250) before making a payment as this is required.

The SDK (210) may contain a software protection component (214) to provide software protection mechanisms to maintain its own integrity against attack. The SDK may be developed with security concepts and activities throughout the entire software lifecycle, including inception through development, deployment, operation, maintenance, and decommission.

Some of the SDK components relate to the operation of the BLE data transfer. The SDK (210) may include a data exchange component (211) may provide functionality for exchanging one or more of a payor token, a payee token, and a payment amount with another computing device. The functionality of the data exchange component (211 ) may use the BLE component (230) as the transport layer for the data exchange. The data exchange component may be further arranged to send an indication of an approval or denial of a payment via a BLE data connection using the BLE component (230) as the transport layer to another computing device. The data exchange component (211) may form part of or reside within the GATT server component (221 ) when in a peripheral mode or within the GATT client component (222) when in a central mode.

The SDK (210) may include a notification handling component (219) configured to handle the nature of the asynchronous APIs presented by various different mobile device operating systems (e.g. Android, iOS). The SDK (210) may include an operation queue component (215) for BLE operations. The BLE operations i.e. advertising, scanning, connecting etc. may be arranged to run serially by making use of a blocking queue (which may be termed an ’operation queue’) so that the results of these key operations are returned via the custom SDK callbacks to the application calling code. This ensures that there are no unexpected behaviours across different application implementations.

The SDK (210) may include a token/payload storage component (212) to configure the application (260) to store one or more payor token associated with a store of value or stores of value, and configured to store one or more payee token associated with a store of value or stores of value to which a payment may be credited.

The SDK (210) may include a distance determining component (218) that may be configured to provide a distance determination between computing devices (250). The distance determining component (218) may be configured to determine or calculate a physical distance between the computing device (250) and another computing device (250). The distance determining component (218) may determine whether the distance between the computing devices (250) is less than a payment region threshold distance. The distance determining component (218) may cause the BLE component (230) to activate the BLE data connection. The distance determining component (218) may calculate a physical distance between the computing devices (250) based on relative Bluetooth signal strength.

Some of the SDK components relate to the online attestation and transaction processing of the application (260).

The SDK (210) may include a secure channel component (234) configured to deliver sensitive data in an encrypted format through a secure channel to the back-end processing environment to be decrypted in order for it to be passed for subsequent transaction processing. The SDK (210) may include an attestation component (235) for online security status attestation of the application (262).

The SDK (210) may include a payment protocol component (213) to configure the application (260) to send a payment authorisation request to a payment gateway, the request including the payor token, the payee token, and the payment amount, and configured to receive a payment authorisation response indicating the approval or denial of the payment request. The payment protocol component (213) may be configured for a custom payment gateway or an external payment gateway. The payment protocol component (213) may be configured for a closed-loop payment or an open-loop payment. The payment protocol component (213) may be configured use a cellular communications module (254) of the computing device (250) as transport layer for sending and receiving payment authorisation requests and responses. The payment protocol component (213) may further be configured to govern communication over the BLE data connection, for example by facilitating the exchange of an authorisation request (GATT server request) and authorisation response (GATT server response) between two computing devices (250) via the BLE data connection.

Figure 2B is a block diagram which illustrates exemplary components which may be provided by a system for facilitating a payment method according to aspects of the present disclosure. The system includes a computing device (250), such as the first mobile device (102) or the second mobile device (104), in which the SDK functionality has been provided in an application (262).

The computing device (250) may include a processor (272) for executing the functions of components described below, which may be provided by hardware or by software units executing on the computing device (250). The software units may be stored in a memory component (274) and instructions may be provided to the processor (272) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the computing device (250) may be provided remotely. Some or all of the components may be provided by an application (or “app”) (103) downloadable onto and executable on the computing device (250).

The app may implement a customisable user interface (273) and customisable business logic (275). The customisable user interface (273) may be displayed on and receive input via a hardware user interface component (276). The customisable user interface (273) may be configured to prompt a user for input via the hardware user interface (276). The customisable user interface (273) may be configured to receive input from a user and determine the user’s input or selection from the received input. The customisable user interface component (273) is configured to prompt a selection between either performing the role of payee or the role of payor, receiving a selection input from the user, and determining the selection of the user to be the role of payee or that of payor. The customisable user interface component (273) may also be configured to prompt the user to select a store of value (when participating in the payment transaction in the capacity of payor); or select an account to which the payment must be credited (when participating in the payment transaction in the capacity of payee). The customisable user interface component (273) may also be configured to display status updates during the payment methods, and displaying a payment authorisation result. The customisable user interface component (273) may be configured to display discovered BLE advertisers where the method performs a BLE scan, and may receive input selecting a particular discovered BLE advertiser to establish a BLE data connection with.

The app (260) may include SDK functionality (262) including the following components. Additional functionality may also be provided by the SDK consumed in the application (260) as described in Figure 2A.

The SDK functionality (262) may include a BLE data module (281) configured to establish a BLE data connection with another computing device on which selection is made of the role of the other of the payee or payor. The BLE data module (281 ) may comprise, or may include one or more of: a Bluetooth module (280A), an Android Bluetooth interface (280B), an iOS Bluetooth interface (280C) and a Web Bluetooth Interface (280C) depending on the type of computing device (250) and its operating system. The Bluetooth module (280A) may be arranged to perform a BLE advertisement and accept a BLE data connection request, or to perform a BLE scan for a BLE advertisement, discovering an advertiser, and requesting a BLE connection with the advertiser.

The SDK provides a payment functionality to the application, abstracting the handling of different Bluetooth Low Energy (BLE) functionalities and the online transaction processing. The application will receive asynchronous notifications on key BLE events, user interface events, as well as transaction result events. The SDK may be multi-platform enabled i.e. can be used in both iOS, Android and Web applications.

The SDK functionality (262) may include consumed SDK APIs (288) providing a (peripheral device) GATT server component (292), and a (central device) GATT client component (294). The GATT server component (292) may be activated when the Bluetooth module (280A) is configured as the BLE peripheral device, performing BLE advertising by an advertiser component (297). The GATT client component (294) may be activated when the Bluetooth module (280A) is configured as the BLE central device, performing BLE scanning by a locator component (296). The Bluetooth module (280A) may work in conjunction with the GATT client and server components (292, 624) to establish and manage a BLE data connection. The SDK functionality (262) may include a BLE profile component (295) configured to create a BLE profile specific to the instance of the app (103) installed and executed on the relevant computing device.

The SDK functionality (262) further includes providing a token storage component (282) configured to store one or more payor token associated with a store of value or stores of value, and configured to store one or more payee token associated with a store of value or stores of value to which a payment may be credited.

The SDK functionality (262) further includes a data exchange component (284) configured to exchange one or more of a payor token, a payee token, and a payment amount with another computing device. The data exchange component (284) may use the RF data module (278), or Bluetooth module (280A) as the transport layer for the data exchange. The data exchange component may be further arranged to send an indication of an approval or denial of a payment via the BLE data connection (the BLE data connection using the Bluetooth module (280A) as the transport layer) to another computing device. The data exchange component (284) may form part of or reside within the GATT server component (292) when in a peripheral mode and may make use of the P2P RF data module (278) to facilitate the data exchange between the central and peripheral device.

The SDK functionality (262) may include a distance determining module (287) for determining if the computing device (250) is in an allowed radius of another computing device for a transaction to be processed. The distance determining module (287) may be arranged to determine or calculate a physical distance between the computing device (250) and another computing device. The distance determining module may determine whether the distance between the computing device (250) and the other computing device is less than a payment region threshold distance. The distance determining module may cause the Bluetooth module to initiate the BLE data connection. The distance determining module may calculate a physical distance between the computing device (250) and the other computing device based on relative Bluetooth signal strength.

The SDK functionality (262) may include an attestation component (288) for determining a security status of the application (260) by communication to an attestation back-end service.

The SDK functionality (262) also includes a payment protocol component (286) configured to send a payment authorisation request to a payment gateway, the request including the payor token, the payee token, and the payment amount, and configured to receive a payment authorisation response indicating the approval or denial of the payment request. The payment protocol component (286) may use a cellular communications module (277) of the computing device (250) as transport layer for sending and receiving payment authorisation requests and responses. The payment protocol component (286) may further be configured to govern communication over the BLE data connection, for example by facilitating the exchange of an authorisation request (GATT server request) and authorisation response (GATT server response) between two computing devices via the BLE data connection.

Where the computing device (250) is a POS terminal this may access the required data to process a transaction without needing to hit the token storage component. The POS terminal may directly communicate with an external payment processor. Referring to Figure 3, a block diagram shows another example embodiment of a contactless payment system including a first computing device in the role of a central device (310) and a second computing device in the role of a peripheral device (320). The central device (310) and the peripheral device (320) use a secure encryption connection channel (340) established with back-end systems (350).

The back-end systems (350) may include a payment gateway (360) providing custom support systems for the described payment functionality. In one embodiment, this may include payment processing systems (362) for a closed-loop customised payment system. In another embodiment, the payment gateway (360) may provide a gateway to an external payment processing system (370) based on external servers of financial institutions to provide an open-loop payment system.

The payment gateway (360) may include a monitoring and attestation environment (361) for attesting the security of the central device (310) and peripheral device (320). The payment gateway (360) may also provide access to or store a token vault (351) with stored tokens of the stores of value associated with the central device (310) and the peripheral device (320).

The central device (310) and the peripheral device (320) each execute a payment application (330) that uses a BLE controller (331) for communication between the two devices (310, 320). The payment application (330) includes functions provided by an SDK as described. The SDK provides functions to the payment applications (330) for both the roles of a payor as required by a central device (310) and a payee as required by a peripheral device (320). In Figure 3 only the functions of the payment application (330) required for each role are shown.

The payment applications (330) on the central device (310) and the peripheral device (320) include an attestation component (332) for attesting the security status of payment platform provided by the payment application (330) by communication with the monitoring and attestation environment (361) via the secure encryption connection channel (340). The attestation process is performed as required by a standard for the payment processing. The payment applications (330) include software protection components (335).

The payment applications (330) also include a payment protocol component (338) for communication with the custom or external payment processing systems (362, 370) via the secure encryption connection channel (340) and via the payment gateway (360).

The payment application (330) on the peripheral device (320) includes an advertiser component (336) for advertising a locator component (333) for scanning for advertisements to initiate a BLE connection between the two devices (310, 320). The payment application (330) on the peripheral device (320) includes a GATT server component (327) for starting a BLE GATT server for a transaction as described further below. The payment application (330) on the central device (310) includes a GATT client component (334) for communication with the GATT server.

The SDK API may provide definitions that relate to the sender or the central mode role and those that relate to the receiver side i.e. peripheral mode role. Such definitions are elaborated on below.

BLE terminology

The following terminology may be used herein with reference to BLE communication.

In order to establish the BLE data connection, one of the computing devices starts a BLE advertisement. In the example of Figure 1 , it is the second mobile device (104) which was selected to act in the capacity of payee in the payment transaction and the second mobile device (104) therefore acts as the “peripheral device” in BLE terminology, and runs the Generic Attribute Profile (GATT) server. For payment processing to occur, there needs to be communication between the GATT client and the GATT server. Every BLE device sold must include at least a basic GATT server that can respond to (BLE) client requests, even if only to return an error response.

In the present method, a GATT server may be dynamically created on the peripheral device. It is this GATT server that handles the payment-related data exchange between the first and second mobile devices (102, 104) via the BLE data connection (108). Once transaction information has been received, the GATT server resolves the request online, returns the response to the peripheral device and a SUCCESS or FAILED GATT event is returned to the GATT client.

The data in a GATT server is typically arranged in a hierarchy. The attributes in a GATT server are grouped into services, each of which can contain zero or more characteristics. These characteristics, in turn, can include zero or more descriptors. This hierarchy is strictly enforced for any device claiming GATT compatibility (essentially, all BLE devices sold), which means that all attributes in a GATT server are included in one of these three categories, with no exceptions.

Figure 4A shows an exemplary payment GATT server (400) that may be implemented. The GATT server (400) is dynamically created when an application consuming the SDK is in the peripheral mode role. The GATT server (400) shows the services implemented on the relevant GATT server, and the characteristics and descriptors of each service. In the present example, the GATT server implements a payment service (410) that includes a user secrete generation (420), a wallet payment (430), a credit card payment (440), and a virtual card payment (450) each with characteristics and descriptors.

Figure 4B illustrates the contents of the data packet or payload (470) that forms (or forms part of) the payment protocol and the authorisation request (112) according to aspects of the present disclosure. The payment protocol is responsible for the message exchange between mobile devices (102, 104) and thereafter the message exchange between one of the mobile devices and the backend server (114). The protocol is intended to be based on open standards, for which libraries exist for any platform. It may be lightweight. Although financial messages may not comprise large chucks of data, keeping them within a small size is important in order to keep transfer time to a minimum. The payment protocol is selected to be easy to debug. Enabling the tracing of the information flow between all components of the system with minimal tools is essential for fast problem-solving. As illustrated in Figure 4B, the payment protocol may be based on a request/response model.

The fields in solid lines shown in Figure 4B illustrate the request (480), and the additional fields in broken lines indicate an exemplary format of a payment authentication response (490). The request may include at least the payor token, the payee token, and the payment amount. Additional information and meta-data may be included in the request. The request may include an indication of the transaction type, for example whether it is a purchase or a withdrawal transaction. This may be a string value (e.g. “PURCHASE”), or may be a binary value in which different bit positions correspond to different transaction types. The server may also include a transaction medium, for example whether the medium is a payment card (e.g. credit card) or wallet. The request may include a unique identifier of the computing device. The request may include a merchant or payee reference, as well as a sender or payor reference. The request may also include a cryptographic hash or message authentication code (MAC) of the data in the request to enable the recipient (such as the backend server to perform an integrity check on the data). The payload as a whole may be encrypted as the Bluetooth connection may be unsecured.

The messages may be JSON compliant, with pure ASCII used as transport. For example, a data exchange format of IS08583 messaging may be used that is similar to JSON and which is a data exchange format. When exchanging binary data, this must be converted into ASCII prior to being part of the message. Likewise, the receiving end must convert it back to binary when operating with environments that expect the data in its original binary format. It is expected that the back end can do a straightforward conversion from JSON to the actual protocol and likewise on the acquirer/payment gateway.

As indicated in Figure 1 , the payment authentication response (118) is returned to the mobile device that sent the request (112). The response (118) may include all the data items of the request (112), further including a result, and a reason. The data paths of the payment authentication request and response (112, 118) are shown in broken lines to indicate the logical communication path. It will be understood that the data may be routed via the mobile communication network (107), internet (105), and likely a number of further communication paths between the data sender and receiver. The payment authentication response (118) may include a message authentication code (MAC) to check against the request’s MAC to ensure that there was no data tampering.

The relevant mobile device that sent the request (112) receives the payment authorisation response (118). In the present exemplary scenario, this is the second mobile device (104). Indication of the approval or denial of the payment may then be sent to the other device (the first mobile device (102)) via the BLE data connection (108).

Referring to Figures 5A, 5B and 5C, flow diagrams show example embodiments of the described method of contactless payment. An example payment flow of the mobile application SDK enablement and a subsequent payment transaction are described according to aspects of the present disclosure. Figure 5A shows a flow diagram showing an example embodiment of aspects of the described method including a pre-processing stage (500) in which an application on a computing device consumes (501) the SDK providing the contactless payment functionality or an application including the SDK functionality is accessed by or downloaded on the computing device. In the following steps the method may be referred to as carried out by the application and this includes using the SDK functionality within the application.

The application develops (502) a secure connection channel between the SDK functionality and an attestation service provided at a back-end server over a network connection. The attestation service may determine (503) a security status of the SDK functionality.

An aspect of the method (510) is shown as carried out at the time of a transaction. The application on a computing device in the role of the central device (i.e. the payor) choses (511) a store of value (i.e. an account, a wallet, cryptocurrency, etc.) associated with the computing device and a BLE token for a transaction is obtained from a token vault at a back-end system. The back-end system connects to the token vault that makes use of tokenization encryption on the account data. A payload is generated (512) and stored for a potential transaction.

A BLE payment connection is established between the central device and the peripheral device. This includes the application on central device scanning (513) for BLE enabled computing devices. The application on the peripheral device begins to advertise (514) to central devices. A BLE payment connection is initiated from the central device to the peripheral device and a BLE connection is then established (515). The application on the central device sends (516) the BLE token as well as the transaction amount to the peripheral device via the BLE connection.

These steps may be initiated in two distinct ways: by manually selecting to connect to a peripheral and then sending the transaction data; or, by automatically connecting to the peripheral when in a given payment region and then sending the transaction data. These options are described further below in relation to Figures 6A and 6B.

The peripheral device makes a call to the back-end systems using the application to process a payment. Two embodiments of this payment processing are described in Figures 5B and 5C.

Figure 5B shows a flow diagram (520) of transaction processing from the application at the peripheral device using a custom payment processing service using stores of value at a back-end server. The application on the peripheral device makes (521 ) a call to the custom payment service to process the payload including both the BLE tokens associated with the central device and the peripheral device. The custom payment service requests (522) the store of values of the devices using the supplied tokens. The amount is deducted (523) from the central device’s store of value and added to the store of value of the peripheral device. The custom payment service then communicates (525) the result of the transaction to the peripheral device with callback methods in the BLE SDK functionality. Further details of custom payment service embodiments are described in Figures 6A and 6B.

Figure 5C shows a flow diagram (530) of transaction processing from the application at the peripheral device using an external payment processing service using stores of value provided by external providers using an open-loop payment system.

The application on the peripheral device makes a call (531) to a custom backend such as a payment gateway to ascertain if the external payment can be processed. When external payments are possible, the underlying store of value token elements are requested (532). The BLE tokens are passed to the backend in order to obtain the underlying store of values token elements for both the peripheral device and the central device. A payload that includes the respective token element is fed back (533) to the applications on the peripheral device by the SDK functionality for processing as external payments by the payment services application. The calling application processes (534) the payment and propagates the result to the peripheral device via callback methods, which then communicates (535) the result to the central device via the already established BLE connection.

Figure 6A is a swim-lane flow diagram illustrating steps in an example method of performing a payment according to aspects of the present disclosure with reference to the embodiment of Figure 1. Different lanes in the diagram indicate steps executed at the relevant device, i.e. the first mobile device (102), the second communication device (104), and the backend server (114). In this exemplary scenario of the method, the first communication device (102) is instructed to perform payment, while the second communication device (104) is instructed to receive payment.

The first communication device (102) prompts (602) the user to make a selection between performing payment (as payor) or receiving payment (as payee). The communication device (102) may display the options on a graphical user interface on a touch screen and receive input (604) of the selection via a touch input. Other prompt and input methods are also envisaged, such as a voice prompt, and voice input. The first communication device (102) determines (606) the selection to be that of making payment as payor. If multiple payment facilities are available, the first communication device (102) may prompt the user to select (608) the store of value from which payment should be made. For example, the first communication device (102) may have been configured, through an enrolment process, with a payment card payment facility, and a wallet payment facility. During such an enrolment process, a (payor) token may have been generated as a surrogate for the sensitive account information, and the token stored on the first communication device (102). A similar enrolment procedure may have been performed for accounts to which payment may be made, in example scenarios where the first communication device (102) acts in the capacity of payee.

The first communication device (102) retrieves (608) the payor token associated with the selected (or default) store of value. The first communication device (102) starts (610) a BLE scan in order to detect a counterparty to the transaction. The user interface of the first communication device (102) may be updated to display discovered BLE advertisers.

The second communication device (104) also prompts (612) a user (of the second communication device) to make a selection between performing payment (as payor) or receiving payment (as payee). The second communication device (104) may similarly display the options on a graphical user interface on a touch screen and receive input (614) of the selection via a touch input or other input methods, such as voice input. The second communication device (104) determines (616) the selection to be that of receiving payment as payee. If multiple accounts are available to which the received payment may be credited, the second communication device (104) may prompt the user to select (618) the account to which payment should be credited.

For example, the second communication device (104) may have been configured, through an enrolment process, with a cheque account, and a wallet account. During such an enrolment process, a (payee) token may have been generated as a surrogate for the sensitive account information, and the token stored on the second communication device (104). A similar enrolment procedure may have been performed for facilities from which payment may be made, in example scenarios where the second communication device (104) acts in the capacity of payor.

At various intervals along the payment method (600), either or both of the first and second communication devices (102, 104) may send information regarding the integrity of the device hard and software, and various other security-related data to the backend server (114) for attestation purposes. The backend server (114) may also challenge either of the devices for such information at any point. For example, for security purposes it may be required that the version of the operating system, or of a mobile application in which the method (600) is embodied, to be updated to a latest version. The backend server (114) may confirm the attestation data and may allow the transaction to proceed if the attestation step is successful, or may alternatively terminate the transaction upon attestation failure. The second communication device (104) retrieves (618) the payee token associated with the selected (or default) account to be credited. The second communication device (104) starts (620) a BLE advertisement in order to make it discoverable through BLE scanning. The second communication device (104) is therefore then configured as the “peripheral” device, and running a BLE GATT server. The user interface of the second communication device (104) may be updated to display that it is ready to accept payment.

The steps performed by the second communication device (104) from prompting (612) to starting (620) BLE advertising may be performed prior, in parallel, or after the first communication device (102) has proceeded to the step of starting (608) BLE scanning.

The first communication device (102) may then calculate (608) a distance between it and one or more discovered BLE advertisers, including the second mobile device (104) presently performing BLE advertising (620). The first communication device (102) may await it determining (620) to be within a payment region, i.e. a preconfigured distance, from the second communication device (104) or a radius between the device performing BLE advertising (peripheral device) and the device performing BLE scanning (central device). For example, the payment region may be preconfigured as 50mm. If the first communication device (102) calculates (618) the distance between it and the second communication device (104) to be smaller than 50mm, it may determine (620) it (102) to be within the payment region of the second communication device (104). The payment region may be even smaller, such that a near-touch between the devices is required to be in the payment region.

Once the first communication device (102) determines (620) it to be within the payment region of the second mobile device (104), it initiates (622) a BLE data connection by requesting a BLE connection to the GATT server of the second communication device (104). The second mobile device (104) may then accept (624) the BLE data connection request, thereby establishing the BLE RF data connection between the two devices (102, 104).

A data exchange is performed between the two mobile devices (102, 104) via the BLE RF data connection. The payee may input an amount requested for payment on the second mobile device (104), which may send (626) the amount to the first communication device (102). The first mobile device (102) may confirm (622) the amount tendered for payment and send (628) the payor token via the BLE data connection to the second communication device (104), which receives (630) the data. The second mobile device receives the payor token and may obtain the payee token (e.g. by retrieving it from storage). Through this data exchange, the second mobile device (104) comes to be in possession of the payor token, the payee token, and the payment amount. The second communication device (104) may then prepare a payment authorisation request similarly to the format shown in the example request illustrated in Figure 4B. The payment authorisation request may be sent (632) to the backend server (114). The backend server (114) may receive (634) the authorisation request and extract the payor token, and payee token, and payment amount. The backend server (114) may validate the received tokens and may use them to retrieve (636) the source (payor) and destination (payee) store of value information, which may be stored in the secure token vault (115). With the payor a payee store of value information retrieved, the backend server may cause the payment to be brokered (638). This may include further communication with downstream payment gateways and the like. The brokering (638) of the payment transaction may be successful, or may have been denied, declined or failed for a number of reasons. Failure may be due to technical difficulties, like a communication timeout for example. The transaction may be declined due to insufficient funds, for example.

The result and the reason, where applicable, may be compiled into a payment authorisation response message, as illustrated in Figure 4B. The payment authorisation response message may be sent (640) to the device from which the payment authorisation had been received which, in the present scenario, is the second mobile device (104). The second mobile device may receive the authorisation response and may update its user interface to reflect the result. It may send (642) the authorisation response, or a message derived therefrom, to the first mobile device via the BLE RF data connection (108). The first mobile device (102) may receive (644) the message via the BLE data connection (108) reflecting the result of the payment. The first mobile device (102) may update its user interface to reflect the result of the payment. The BLE data connection (108) may then be terminated.

Figure 6B shows an alternative implementation of the payment method (650). Like reference numerals used in Figure 6B correspond to like features and steps in Figure 6A. The steps in this method (650) differ in that the mobile device acting as BLE GATT client does not request a BLE connection based on distance between it and the discovered BLE GATT server (i.e. by means of the “payment region” method). In this embodiment of the method (650), the second mobile device (104) starts (620) its BLE advertising, and the first mobile device (102) starts (610) a BLE scan. The first mobile device (102) then discovers (652) and displays the discovered peripheral devices, i.e. devices performing BLE advertising within Bluetooth reception range.

The user then inputs a selection, and the first mobile device (102) receives (654) the selection of the BLE advertiser selected to make payment to. The first mobile device then initiates (622) the BLE data connection, and the method may proceed as described above with reference to Figure 6A. In the embodiments of the payment method (600, 650) described above, the payee device was configured as a BLE GATT server (peripheral device). It is envisaged, however, that the BLE roles may be reversed. Similarly, the BLE data exchange between the two devices may be such that either of the two devices comes into possession of the payor token, payee token, and payment amount. Either of the devices may therefore send and receive the payment authorisation request and response to and from the backend server (114), and then communicate the received result to the other device via the BLE data connection.

As mentioned above, the payor token(s) and payee token(s) may be configured during an enrolment process. In embodiments where the method steps are embodied in a mobile application, the relevant device (e.g. smartphone) may download and install the relevant application from a data repository, such as an “app store”. The mobile application may be executed on the device, which may establish a secure communication channel with the backend server (114) and its attestation systems. A store of value, e.g. a payment card, may then be enrolled. The backend server (114) may generate a surrogate token, and may store the sensitive store of value data and personal data of the user in its secure storage, including its secure token vault (115). Similarly, an account may be enrolled (i.e. an account to which received payments may be credited), and a token created associated with the enrolled account. The generated tokens may be communicated back to the device, which may store the tokens for subsequent use in the payment methods (600, 500) as described above.

Aspects of the present disclosure may find application in the ordering of goods or services in a physical establishment, such as a restaurant. For example, in some embodiments an SDK and/or application may be provided for the ordering of goods or services in a physical establishment. In such an embodiment, BLE tokens and/or payloads may be exchanged for the purpose of accessing a listing of goods or services available (such as a menu) and/or for placement of an order for a good or service. In some embodiments, a self-service terminal may be configured as a peripheral device and may advertise to allow central devices to discover it and, subsequently, to establish a data connection with it. Customers may have an application and/or SDK provided on their personal computing devices, which may configure the personal computing device to act as a central device to initiate a connection to the peripheral device. The peripheral device may send a token via the BLE connection that is established between the device (e.g. in accordance with the foregoing description, mutatis mutandis) to the central device. The token may include or provide access to a listing of goods or services. For example, the token may include a URL which directs the central device to a website or other data repository hosting the listing. In some embodiments, the central device may send a token to the peripheral device, for example including data elements indicating one or more of: items selected for order; a table or seat number corresponding to a table or seat at which a consumer associated with the central device is or will be seated; payment information (e.g., as described in the foregoing), or the like. In other embodiments, the self-service terminal may be associated with a table number (e.g. there may be one self-service terminal provided at each table in the physical establishment).

SDK API Definitions

Application programming interfaces (APIs) are exposed by the SDK to be consumed by the final application making use of the SDK services. There are SDK API definitions that relates to the sender or the central mode role and those that relate to the receiver side i.e. peripheral mode role.

Software units or functions used to implement the methods described herein may be implemented as computer program code using a suitable computer language such as, for example, Kotlin™. In particular, the software units or functions used to implement methods executed at the computing devices may be implemented using Kotlin™, as it lends itself to the development of multi-platform software libraries. As such, it may enable the developer to implement business logic on, for example, Android- and iOS-based mobile devices using a single codebase.

What follows is a documentation of an exemplary codebase framework that may be used to implement steps in the methods described above. The first section of this documentation relates to the scenario in which the computing device is operated as the BLE central device, i.e. in which it acts as BLE GATT client. The second section of this documentation relates to the scenario in which the computing device is operated as the BLE peripheral device, i.e. in which it acts as BLE GATT server.

Central Mode Role

LocatorManager class

This class may be used to implement the initiating of BLE scanning, resolving the BLE scanning (i.e. determining whether it has started or not) and communicating the result to the calling code.

Methods

• startScanning(): Unit

Description: Fires an asynchronous BLE scanning request to start on the central device.

• stopScanningQ: Unit Description: Fires an asynchronous stop scanning request on the central device.

• isScanning(): Boolean

Description: Verifies whether the central device is scanning or not

CentralGattClientManager class

This class may be used to implement initiating a connection with the peripheral device, resolving the connection and communicating the result to the calling code.

Methods

• connect(peripheralAddress: String): Unit

Description: Fires an asynchronous connection request to the given peripheral Bluetooth address.

• disconnect(peripheralAddress: String): Unit

Description: Fires an asynchronous disconnect request to the given peripheral Bluetooth address.

• isConnected(peripheralAddress: String): Boolean

Description: Verifies whether the central device is connected to the given peripheral Bluetooth address

TransactionManager class

This class may be used to implement initiating a contactless BLE transaction with the peripheral device. This is started by sending the transaction data over the BLE network, waiting for the transaction to be resolved online by the peripheral device and then communicating the result to the calling code.

Methods

• startTransaction(connectedPeripheral:ConnectedPeripheral, bleTransactionData:

BLETransactionData< K; V >): StartResult

Description: Initiate a transaction asynchronously replying with “OK” as result if it could be started, ERROR otherwise.

Peripheral Mode Role AdvertiserManager class

This class may be used to implement initiating BLE advertising, resolving the advertising (i.e. determine whether it has started or not) and communicating the result to the calling code.

Methods

• startAdvertising(): Unit

Description: Fires an asynchronous BLE advertising request to start on the peripheral device.

• stopAdvertising(): Unit

Description: Fires an asynchronous stop advertising request on the peripheral device.

• isAdvertising(): Boolean

Description: Verifies whether the peripheral device is advertising or not.

PeripheralGattServerManager class

This class may be used to implement initiating BLE GATT server management, resolving the opening and closing of the server, adding GATT services and communicating the result to the calling code.

Methods

• startServer(): Unit

Description: Fires an asynchronous request to start a BLE GATT Server on the peripheral device.

• stopServer(): Unit

Description: Fires an asynchronous request to stop the BLE GATT server on the peripheral device.

• getServices(): List<Any>

Description: Returns the services offered by the BLE GATT Server.

Other SDK API Definitions BLEProfileManager class

This class may be used to implement the creation of a BLE profile online. This profile may provide the necessary information for a central and peripheral device to uniquely identify each other when performing transactions. A key component that may be provided by this class is what may be referred to herein as a “BLE Token”, which forms part of the transaction data sent over the BLE network and acts as a unique payer identifier. This token permits the transaction to be resolved online, as the sender can then be identified. Specific reference of BLE Tokens is made herein to “payor token” and “payee token”, which are in fact references to BLE Tokens in the different contexts they are used.

Methods

• createBLEProfile(cellPhoneNumber:String): Unit

Description: Fires an asynchronous request to create a BLE Profile online for the user, the profile contains what is called a BLEToken. This may be called during an enrolment process in which a particular payment facility (or store of value) is associated with a token.

• getBLEProfile(cellPhoneNumber:String): Unit

Description: Fires an asynchronous request to request online for the BLE profile with the given cell phone number.

Managing asynchronous BLE behaviour

BLE by nature is asynchronous. As a result each API class defined above consumes a callback interface implementation from the calling application that allows the asynchronous communication of the results of each of the given methods once completed. So for example, when connect(peripheralAddress: String) is called by the final application without a callback interface the main thread from the calling application could return to the calling application before a proper connection could be established with the peripheral. An approach proposed to address these aspects includes blocking the main thread for a given time-out. However the time delay can be unpredictable across different operating systems.

Therefore, it may be advantageous to make use of these callback interfaces such that when, for example, the connect(peripheralAddress: String) is called by the application it does not block the main thread. Instead, a ’IConnectedGattClientResult’ callback interface exposed by the API may have been implemented within the final application such that upon a successful connection with the peripheral this would be communicated to the calling app via a method by the name of onConnectedQ. In this manner the final application has a tight integration with the API to effectively manage the asynchronous behaviour that comes with BLE.

The systems and methods disclosed herein therefore provide the capability of using the same mobile device to both perform payments, and receive payments, using contactless payment methods. The ability to use the same device to make and accept payment may enable the unbanked or under-banked to participate in commerce in a society trending towards cashless payments.

Callback Interfaces

Above it is discussed how the SDK manages the asynchronous behaviour of BLE when integrating with custom applications. It was highlighted that the SDK makes uses of callbacks to asynchronously communicate the results of each asynchronous method when called from the final application. The callback interfaces are described further below.

Central Mode: Callback Interfaces

ICentralGattClientResult interface

This interface callback informs the calling application the results of the methods called in the

CentralGattClientManager class, by communicating the result to the calling code.

Callback Methods

• onConnected(connectedPeripheral: ConnectedPeripheral) Description: Successful connection to a peripheral;

• onConnectionError(errorMsg: String, peripheralAddress:String) Description: Failure to connect to the given peripheral Bluetooth address;

• onDisconnected(peripheralAddress: String) Description: Successful disconnect from a peripheral;

• onFailedToDisconnectFromReceiver(errorMsg: String) Description: Failure to disconnect to from a peripheral.

ISenderT ransactionResult interface

TransactionManager class, by communicating the result to the calling code.

Callback Methods

• onTransactionStarted(msg: String);

• Description: Successful start of a transaction from the sender i.e central device;

• onFailedToSendTransactionDataToReceiver(errorMsg: String) Description: Failure to send transaction data over BLE network to the receiving device; • onTransactionResult(transactionResult: TransactionResult) Description: Communicates the result of the transaction result to the sender.

ILocatorResult interface

This interface callback informs the calling application the results of the methods called in the LocatorManager class, by communicating the result to the calling code.

Callback Methods

• onStartedScanning(msg: String);

Description: Successfully started to scan for peripheral devices;

• onFailedToStartScanning(errorMsg: String);

Description: Failure to start scanning for peripheral devices;

• onFoundDevices(foundDevices: Map<String, LocatedDevice>);

Description: Returns the found/located peripheral device(s);

• onStoppedScanning(msg: String);

Description: Successfully stopped scanning;

• onFailedToStopScanning(errorMsg: String);

Description: Failure to stop scanning.

Peripheral Mode: Callback Interfaces lAdvertiserResult interface

This interface callback informs the calling application the results of the methods called in the AdvertiserManager class, by communicating the result to the calling code.

Callback Methods

• onStartedToAdvertise(msg: String);

Description: Peripheral successfully started to advertise;

• onFailedToStartAdvertising(errorMsg: String);

Description: Peripheral failed to start advertising;

• onStoppedAdvertising(msg: String);

Description: Peripheral successfully stopped advertising;

• onFailedToStopAdvertising(errorMsg: String);

Description: Failure to stop advertising.

IGattServerResult interface

This interface callback informs the calling application the results of the methods called in the PeripheralGattServerManager class, by communicating the result to the calling code.

Callback Methods

• onGattServerStarted(msg: String) Description: Peripheral successfully started its GATT server

• onFailedToStartGattServer(errorMsg: String)

Description: Peripheral failed to start its GATT server

• onGattServerStopped(msg: String)

Description: Peripheral successfully closed its GATT server

Peripheral GATT Server Callbacks

The peripheral GATT server has a special callback interface called the UIListener which allows the GATT server to inform the calling application that it has to display a specific message to the peripheral device user.

UIListener interface

This class informs the calling application that it has to display a specific message to the peripheral device user.

Callback Methods

• onEvent(uiEvent: UIEvent)

Description: Returns the Ul event to be displayed

Other Callbacks

The other callbacks to take note of at this is that which comes from the BLEProfileManager.

IBLEProfileResult interface

This interface callback informs the calling application the results of the methods called in the BLEProfileManager class, by communicating the result to the calling code.

Callback Methods

• onBLEProfileResult(bleProfileResult: BLEProfileResult, blePro-fileResponse: BLEProfileResponse)

Description: Returns the result of the BLE profile result online.

Callback Considerations

BLE functionality for some operating systems (for example, Android) may include additional management in the SDK as the BLE can be difficult to maintain in light of some of the following challenges: undocumented/unclear limitations; location required for scanning; connection instability; frequent, obscure errors (GATT ERROR 133); and unbalanced lifecycle calls. These challenges are effectively managed in the SDK.

A main challenge that the SDK handles well is the nature of the asynchronous APIs presented by some operating systems (such as Android). To effectively account for this, BLE operations are designed and implemented i.e. advertising, scanning, connecting, etc. to run serially by making use of a blocking queue which is called an ’operation queue’ and the result of these key operations are returned via the custom SDK callbacks to the application calling code as described earlier. This ensures that there are no unexpected behaviours across different application implementations.

Figure 7 illustrates an example of a computing device (700) in which various aspects of the disclosure may be implemented. The computing device (700) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

The computing device (700) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (700) to facilitate the functions described herein. The computing device (700) may include subsystems or components interconnected via a communication infrastructure (705) (for example, a communications bus, a network, etc.). The computing device (700) may include one or more processors (710) and at least one memory component in the form of computer-readable media. The one or more processors (710) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (700) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.

The memory components may include system memory (715), which may include read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (715) including operating system software. The memory components may also include secondary memory (720). The secondary memory (720) may include a fixed disk (721 ), such as a hard disk drive, and, optionally, one or more storage interfaces (722) for interfacing with storage components (723), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

The computing device (700) may include an external communications interface (730) for operation of the computing device (700) in a networked environment enabling transfer of data between multiple computing devices (700) and/or the Internet. Data transferred via the external communications interface (730) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signals. The external communications interface (730) may enable communication of data between the computing device (700) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (700) via the communications interface (730).

The external communications interface (730) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry. The external communications interface (730) may include a subscriber identity module (SIM) in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the computing device (700). One or more subscriber identity modules may be removable from or embedded in the computing device (700).

The external communications interface (730) may further include a contactless element (750), which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer element, such as an antenna. The contactless element (750) may be associated with (e.g., embedded within) the computing device (700) and data or control instructions transmitted via a cellular network may be applied to the contactless element (750) by means of a contactless element interface (not shown). The contactless element interface may function to permit the exchange of data and/or control instructions between computing device circuitry (and hence the cellular network) and the contactless element (750). The contactless element (750) may be capable of transferring and receiving data using a near field communications capability (or near field communications medium) typically in accordance with a standardized protocol or data transfer mechanism (e.g., ISO 14443/NFC). Near field communications capability may include a short-range communications capability, such as radio frequency identification (RFID), Bluetooth™, infra-red, or other data transfer capability that can be used to exchange data between the computing device (700) and an interrogation device. Thus, the computing device (700) may be capable of communicating and transferring data and/or control instructions via both a cellular network and near field communications capability. The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (710). A computer program product may be provided by a non-transient or non-transitory computer- readable medium, or may be provided via a signal or other transient or transitory means via the communications interface (730).

Interconnection via the communication infrastructure (705) allows the one or more processors (710) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (700) either directly or via an I/O controller (735). One or more displays (745) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (700) via a display or video adapter (740).

The computing device (700) may include a geographical location element (755) which is arranged to determine the geographical location of the computing device (700). The geographical location element (755) may for example be implemented by way of a global positioning system (GPS), or similar, receiver module. In some implementations the geographical location element (755) may implement an indoor positioning system, using for example communication channels such as cellular telephone or Wi-Fi™ networks and/or beacons (e.g. Bluetooth™ Low Energy (BLE) beacons, iBeacons™, etc.) to determine or approximate the geographical location of the computing device (700). In some implementations, the geographical location element (755) may implement inertial navigation to track and determine the geographical location of the communication device using an initial set point and inertial measurement data.

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient or non-transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Kotlin™, Java™, Python™, C++, or Perl™ using, for example, conventional or object- oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations, such as accompanying flow diagrams, are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention set forth in any accompanying claims.

Finally, throughout the specification and any accompanying claims, unless the context requires otherwise, the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Claims

1 . A computer-implemented method performed at a first computing device and comprising: adopting a role of payee or a role of payor in a payment transaction; establishing a Bluetooth Low Energy (BLE) data connection with a second computing device, wherein the second computing device adopting the other of the role of the payor or payee in the payment transaction; and, exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value from which or to which payment is to be made, the token being obtained for submission to a payment gateway for processing the payment transaction.

2. The method as claimed in claim 1, including a pre-transaction method of: consuming a software development kit for an application at the first computing device; and providing a secure connection channel between the application a backend server providing the payment gateway and including assess to a token vault for maintaining the BLE tokens.

3. The method as claimed in claim 1 or claim 2, wherein the backend server provides an attestation service and the method includes determining a security status of the application using the attestation service.

4. The method as claimed in any one of claims 1 to 3, including handling asynchronous notifications on BLE connection events, user interface events, and online transaction result events.

5. The method of claim 4, wherein handling asynchronous notifications includes implementing callback interfaces with the callback interfaces allowing asynchronous communication of results of BLE connection events once completed.

6. The method of claim 4 or claim 5, wherein handling asynchronous notifications includes using a blocking queue to serially run BLE connection events.

7. The method of any one the preceding claims, including dynamically creating a GATT server instance to handle a payment request and resolve this with an online payment processing.

8. The method of any one of the preceding claims, including a second computing device submitting the token to the payment gateway includes: transmitting a payment authorisation request to the payment gateway, the request including a payor token, a payee token, and a payment amount; receiving a payment authorisation response indicating an approval or denial of the payment request; and sending an indication of the approval or denial of the payment request via the BLE data connection to the first computing device.

9. The method as claimed in any one of the preceding claims, wherein establishing the BLE data connection includes: starting a BLE advertisement; and accepting a BLE data connection with the second computing device, the second computing device having performed a BLE scan, discovered the BLE advertisement, and initiated the BLE data connection.

10. The method as claimed in any one of the preceding claims, wherein establishing the BLE data connection includes: starting a BLE scan; discovering a BLE advertisement of the second computing device; and initiating a BLE data connection with the second computing device, the second computing device accepting the connection.

11. The method as claimed in claim 10, wherein discovering a BLE advertisement of the second computing device and initiating a BLE data connection includes calculating a physical distance between the first and second computing device; determining that the distance between the first and second computing communication is less than a payment region threshold distance; and initiating the BLE data connection.

12. A system including a first computing device including a memory for storing computer- readable program code and a processor for executing the computer-readable program code, the first computing device comprising: a role component for adopting a role of payee or a role of payor in a payment transaction; a BLE component for establishing a BLE data connection with a second computing device, wherein instruction having been received on the second computing device to be the other of the role of the payor or payee in the payment transaction; and, a data exchange component for exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value at a payment gateway from which or to which payment is to be made, the token being obtained for submission to the payment gateway for processing the payment transaction.

13. The system as claimed in claim 12, including a second computing device in the form of a peer computing device to the first computing device, wherein the second computing device including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the second computing device comprising a role component for adopting the other of a role of payee or a role of payor in a payment transaction.

14. The system as claimed in claim 12, including a second computing device in the form of point of sale device, wherein the second computing device including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the second computing device comprising a role component for adopting the other of a role of payee in a payment transaction.

15. The system as claimed in any one of claims 12 to 14, including a backend server in communication with the first computing device via a secure communication channel, wherein the backend server provides a payment gateway including assess to a token vault for maintaining the BLE tokens.

16. The system as claimed in claim 15, wherein the payment gateway includes or provides access to a payment service backend that can handle open and closed loop transactions.

17. The system as claimed in any one of claims 12 to 16, wherein the first computing device includes: a user interface component configured to prompt a user for a selection between either performing the role of payee or the role of payor, receiving a selection input from the user, and determining the selection of the user to be the role of payee or that of payor; a data exchange component arranged to exchange a payor token, a payee token, and a payment amount; a payment component configured to send a payment authorisation request to a payment gateway, the request including the payor token, the payee token, and the payment amount, and configured to receive a payment authorisation response indicating the approval or denial of the payment request; and the data exchange component being further arranged to send an indication of the approval or denial of the payment via the BLE data connection to the other device.

18. The system as claimed in any one of claims 12 to 17, wherein the first computing device includes: a token storage component configured to store a payor token associated with a store of value, and a payee token associated with a store of value to which a payment can be credited.

19. The system as claimed in any one of claims 12 to 18, wherein the first computing device includes a distance determining module for discovering a BLE advertisement of the second computing device and initiating a BLE data connection and including: calculating a physical distance between the first and second computing device; and determining that the distance between the first and second computing communication is less than a payment region threshold distance.

20. The system as claimed in any one of claims 17 to 19, wherein the user interface component is arranged to display data representing an advertiser derived from a discovered BLE advertisement, receiving input selecting the advertiser, and a data connection with the advertiser.

21. A computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: adopting a role of payee or a role of payor in a payment transaction; establishing a BLE data connection with a second computing device, wherein the second computing device adopting the other of the role of the payor or payee in the payment transaction; and exchanging data with the second computing device via the BLE data connection such that one of the first computing device or second computing device obtains a token from the other of the second computing device or the first computing device, the token being associated with a store of value at a payment gateway from which or to which payment is to be made, the token being obtained for submission to the payment gateway for processing the payment transaction.

22. A software development kit for a contactless Bluetooth Low Energy (BLE) payment service for providing payment functionality to an application on a computing device, the software development kit being a computer program product comprising a computer-readable medium having stored computer-readable program code comprising: a plurality of central mode components for providing functionality to the application to perform the role of a payor in a transaction over a BLE connection; a plurality of peripheral mode components for providing functionality to the application to perform the role of a payee in a transaction over the BLE connection; a profile component for providing functionality for a profile including a BLE token for a store of value used in a transaction, wherein the BLE token forms part of the transaction data provided over the BLE connection between a central role device and a peripheral role device; and a notification handling component for providing functionality for handling asynchronous notifications on BLE connection events, user interface events, and online transaction result events for the application.

23. The software development kit of claim 22, including an online communication component for providing a secure communication from the application to a backend server providing a payment gateway and including assess to a token vault for maintaining the BLE tokens.

24. The software development kit of claim 22 or claim 23, including a payment protocol component for handling a message exchange between a central device and a peripheral device and a message exchange between a peripheral device and an online payment processing.

25. The software development kit of any one of claims 22 to 24, wherein the online payment processing includes using an external payment processing system or a custom processing system.

26. The software development kit of any one of claims 22 to 25, wherein the peripheral mode components include: an advertiser application programming interface (API) for initiating BLE advertising to provide a BLE connection; and wherein the central mode components include: a locator application programming interface (API) for initiating BLE scanning to locate an advertised BLE connection.

27. The software development kit of any one of claims 22 to 26, wherein the central mode components include: a Generic Attribute Profile (GATT) client API for connection to a peripheral device; and a transaction API for initiating a transaction with the peripheral device and receiving a result of the transaction; and wherein the peripheral mode components include: a Generic Attribute Profile (GATT) server API for initiating a transaction from the peripheral device and communication with a backend server.

28. The software development kit of any one of claims 22 to 27, wherein the notification handling component includes implementing callback interfaces in the application with the callback interfaces allowing asynchronous communication of results of BLE connection events once completed.

29. The software development kit of any one of claims 22 to 28, wherein the notification handling component includes an operation queue component for using a blocking queue to serially run BLE connection events.

30. The software development kit of any one of claims 22 to 29, including a payment processing component for dynamically creating a GATT server instance to handle the payment request and resolve this with an online payment processing.

31. The software development kit of any one of claims 22 to 30, including a payment payload component for providing the transaction data in a message payload for communication via the BLE connection, wherein the message payload is convertible between binary format and ASCII for transport.

32. The software development kit of any one of claims 22 to 31 , including a distance determining component for determining a payment region within which a BLE connection is made.

33. The software development kit of any one of claims 22 to 32, including a plurality of BLE interface components providing multi-platform integration with device Bluetooth capabilities.

34. The software development kit of any one of claims 22 to 33, provided for one of: a mobile device in the form of a custom application or an extension to an existing application; or a point- of-sale device in the form of a kernel application.