WO2019171288A1

WO2019171288A1 - Contactless communication-based financial transactions

Info

Publication number: WO2019171288A1
Application number: PCT/IB2019/051804
Authority: WO
Inventors: Gerhard Gysbert OOSTHUIZEN; Daniël Deetlefs BESTER
Original assignee: Entersekt International Limited
Priority date: 2018-03-06
Filing date: 2019-03-06
Publication date: 2019-09-12
Also published as: ZA202005316B

Abstract

A system and method for contactless communication-based financial transactions are described. In a method conducted at a consumer device, a read-only contactless communication interrogation of a contactless element associated with a merchant device is performed. A payment reference is received from the contactless element in response to the read-only interrogation. A payment authorisation confirmation message including the payment reference is generated. The payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and is transmitted, via a communication network, to a device gateway for processing the financial transaction.

Description

CONTACTLESS COMMUNICATION-BASED FINANCIAL TRANSACTIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application number 2018/01524 filed on 6 March 2018, which is incorporated by reference herein.

FIELD OF THE INVENTION

This invention relates to contactless (in particular near-field) communication-based financial transactions.

BACKGROUND TO THE INVENTION

The term “near-field communication”, or “NFC”, typically refers to a set of communication protocols that enable two electronic devices to establish wireless data communication by bringing them within a predefined range (typically about 4 cm) of each other.

There are a number of mobile phones on the market which are“NFC enabled”, meaning that they include the required hardware and software to communicate using NFC protocols. One application of NFC-enabled devices which is growing in ubiquity is for contactless payments, where a consumer can simply‘tap’ his or her NFC-enabled device on - or bring within the predefined range of - a suitably configured point of sale (POS) terminal.

Different technology providers operating in the mobile phone ecosystem provide different, typically built-in, payment applications. For example, mobile phones manufactured by APPLE INC. may include a payment application called APPLE PAY (a trade mark of APPLE INC.), mobile phones which execute the ANDROID operating system may include the GOOGLE PAY payment application (trade marks of GOOGLE, INC.) and mobile phones manufactured by SAMSUNG™ may include the so-called SAMSUNG PAY™ payment application.

Each of these payment applications typically conform to universal standards set down by the Card industries, which may include an exchange of information between the mobile phone and the POS terminal, and where the POS terminal ultimately has payment details required to submit a financial transaction through the payments system of the merchant that owns the POS terminal. Typically read/write functionality of the mobile phone’s NFC element is required to enable communication with point of sale devices.

One problem that may be associated with these‘standard’ payment applications is retailer and card issuer support. For example, for a consumer to be able to make use of APPLE PAY, the financial institution issuing his or her bank card may be required to support APPLE PAY. Further, the retailer at which the consumer wishes to transact may also be required to support APPLE PAY. Similar shortcomings may be associated with SAMSUNG PAY and GOOGLE PAY. These shortcomings may be felt particularly in secondary markets in which the entities do not support this functionality, at least initially.

This is less of a problem with mobile phones which run open operating systems, such as ANDROID. Such operating systems typically allow third party software application developers to develop payment applications which make use of the NFC functionality of the mobile phone to make contactless payments. The operating systems may for example make the full functionality of the NFC element of the mobile phone (thus including read/write functionality thereof) available to the software developers so that the software developers can build payment applications which function in almost exactly the same way as the standard payment applications.

However, restrictive operating systems, such as APPLE INC.’s IOS (a trade mark of APPLE INC.) typically restrict access to the mobile phone’s NFC element to third party software developers. These restrictions may include restricting access to the NFC element’s read/write functionality and only allowing access to the read-only functionality thereof.

This means that in secondary markets, third parties may be able to create payment ecosystems for users of open operating system-based mobile phones that they cannot create for users of more restrictive operating-system based mobile phones.

There is accordingly 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

In accordance with an aspect of the invention there is provided a computer-implemented method conducted at a consumer device comprising: performing a read-only contactless communication interrogation of a contactless element associated with a merchant device; receiving a payment reference from the contactless element in response to the read-only interrogation; generating a payment authorisation confirmation message including the payment reference, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant; and, transmitting, via a communication network, the payment authorisation confirmation message to a device gateway for processing the financial transaction.

Further features provide for the method to include prompting for and receiving a payment credential selection; for the payment authorisation confirmation message to include the payment credential selection; and, for prompting for payment credential selection to be in response to receiving the payment reference.

A still further feature provides for generating the payment authorisation confirmation message to include generating a cryptogram including or based on one or both of payment credentials and transaction related data.

An even further feature provides for the method to include prompting for and receiving consumer authentication; for the authentication to be biometric authentication and for receiving consumer authentication to include receiving and validating a consumer biometric; for prompting for consumer authentication to be in response to receiving payment credential selection; and, for generating and transmitting the payment authorisation confirmation message to be automatically in response to receiving consumer authentication.

Even further features provide for performing the read-only interrogation to include: creating an NDEF reader session and providing a delegate; and, the reader session polling for contactless elements and calling the delegate when it finds a contactless element containing an NDEF message.

Still further features provide for receiving the payment reference to include in response to the reader session calling the delegate when it finds the contactless element containing an NDEF message: the reader session passing the NDEF message to the delegate, the NDEF message including the payment reference; and, the delegate reading the NDEF message to obtain the payment reference.

In accordance with a further aspect of the invention there is provided a computer-implemented method conducted at a merchant device comprising: providing a payment reference via a contactless element configured for read-only contactless communication interrogation by a consumer device, the payment reference being provided for submission by the consumer device to a device gateway to process a financial transaction between a consumer and a merchant; and, receiving a payment confirmation message confirming processing of the financial transaction.

A further feature provides for the method to include: generating a payment request message including the payment reference and optionally an amount in respect of the financial transaction; and, transmitting the payment request message to the device gateway via a communication network.

A still further feature provides for the method to include: receiving a payment response message from the device gateway, wherein the payment response message includes payment credentials associated with the consumer; generating a payment authorisation request message including the payment credentials; and, transmitting the payment authorisation request message to an acquirer payment processor for processing the financial transaction against the payment credentials in favour of the merchant.

In accordance with a further aspect of the invention there is provided a computer-implemented method conducted at a device gateway comprising: receiving, via a communication network, a payment authorisation confirmation message from a consumer device, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and includes a payment reference having been obtained by the consumer device using a read-only contactless communication interrogation of a contactless element associated with a merchant device; validating the payment reference; and, if the payment reference is valid, processing the financial transaction using the payment reference and payment credentials.

Further features provide for the method to include: receiving, via a communication network, a payment request message from the merchant device, wherein the payment request message includes the payment reference, and wherein one or both of the payment authorisation confirmation message or the payment request message includes an amount in respect of the financial transaction, and wherein validating the payment reference includes validating the payment references received from the consumer device and merchant device respectively.

Further features provide for each of the payment authorisation confirmation message and payment request message to be associated with a time to live and for validating the payment references to include validating that both messages are received within the time to live.

A further feature provides for validating the payment references to include comparing the payment references for a match.

A further feature provides for the method to include transmitting a transaction detail approval message to the consumer device, the transaction detail approval message including transaction details and prompting the consumer for his or her approval of the transaction details; and, receiving a transaction detail approval response from the consumer device indicating the consumer’s approval or denial as the case may be.

An even further feature provides for the method to include retrieving payment credentials associated with the consumer device.

A still further feature provides for processing the financial transaction to include processing the financial transaction against the payment credentials in favour of a merchant associated with the payment reference.

An even further feature provides for the payment authorisation confirmation message to include consumer authentication data associated with the payment credentials, such as a mobile PIN or card PIN.

In one embodiment, processing the financial transaction includes transmitting a payment response message including the payment credentials to the merchant device, and for the merchant device to forward the payment credentials to a payment processing network for processing of the financial transaction against the payment credentials in favour of the merchant.

In another embodiment, processing the financial transaction includes: submitting the payment credentials to a payment processing network for processing the financial transaction against the payment credentials in favour of the merchant; and, receiving a payment confirmation message from the payment processing network, confirming processing of the financial transaction; and, forwarding the payment confirmation message to the merchant device to confirm processing of the financial transaction against the payment credentials in favour of the merchant.

In accordance with a further aspect of the invention there is provided a system including a consumer device having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the consumer device comprising: a contactless interrogation component for performing a read-only contactless communication interrogation of a contactless element associated with a merchant device; a payment reference receiving component for receiving a payment reference from the contactless element in response to the read-only interrogation; a payment message generating component for generating a payment authorisation confirmation message including the payment reference, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant; and, a payment authorisation confirmation message transmitting component for transmitting, via a communication network, the payment authorisation confirmation message to a device gateway for processing the financial transaction.

In accordance with a further aspect of the invention there is provided a system including a merchant device having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the merchant device comprising: a contactless element configured to provide a payment reference to a consumer device via read only contactless communication interrogation of the contactless element by the consumer device, the payment reference being provided for submission by the consumer device to a device gateway to process a financial transaction between a consumer and a merchant; and, a messaging component for receiving a payment confirmation message confirming processing of the financial transaction.

In accordance with a further aspect of the invention there is provided a system including a device gateway having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the device gateway comprising: a payment authorisation confirmation message receiving component for receiving, via a communication network, a payment authorisation confirmation message from a consumer device, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and includes a payment reference having been obtained by the consumer device using a read-only contactless communication interrogation of a contactless element associated with a merchant device; a validating component for validating the payment reference; and, a transaction processing component for, if the payment reference is valid, processing the financial transaction using the payment reference and payment credentials.

In accordance with a further aspect of the invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: performing a read-only contactless communication interrogation of a contactless element associated with a merchant device; receiving a payment reference from the contactless element in response to the read-only interrogation; generating a payment authorisation confirmation message including the payment reference, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant; and, transmitting, via a communication network, the payment authorisation confirmation message to a device gateway for processing the financial transaction.

In accordance with a further aspect of the invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, via a communication network, a payment authorisation confirmation message from a consumer device, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and includes a payment reference having been obtained by the consumer device using a read-only contactless communication interrogation of a contactless element associated with a merchant device; validating the payment reference; and, if the payment reference is valid, processing the financial transaction using the payment reference and payment credentials.

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 A is a schematic diagram which illustrates an exemplary system for contactless financial transactions;

Figure 1 B is a swim-lane flow diagram which illustrates an overview of an exemplary method for contactless financial transactions;

Figure 2A is a swim-lane flow diagram which illustrates an exemplary method for contactless financial transactions in greater detail;

Figure 2B is a swim-lane flow diagram which illustrates one exemplary method for processing a financial transaction;

Figure 2C is a swim-lane flow diagram which illustrates another exemplary method for processing a financial transaction;

Figure 3 is a block diagram which illustrates exemplary components which may be provided by a system for contactless financial transactions; and

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

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Aspects of this disclosure provide a system and method for contactless communication-based financial transactions. In some implementations, the contactless communications may use read only protocols (e.g. as opposed to read/write protocols). For example, in some implementations, a consumer device may be configured to conduct a financial transaction with a merchant device by performing a read-only interrogation of an NFC tag associated with the merchant device. Aspects of the present disclosure are described below with reference to exemplary transactions between a consumer and a merchant. It should however be appreciated that aspects of the present disclosure may find application in person-to-person (or P2P) payments as well, in which the consumer may be considered the“payor” and the merchant the“payee”.

In some implementations, the user experience associated with the financial transaction may be the same as conventional NFC-based financial transactions. In other words, from the perspective of the consumer, the transaction may appear to be a conventional NFC-based financial transaction whereas the underlying operations may be (substantially) different.

Figure 1 A is a schematic diagram which illustrates an exemplary system (100) for contactless financial transactions. The system may include a consumer device (102), a merchant device (104) and a device gateway (106). The consumer device (102) and merchant device (104) may be configured to communicate with the device gateway (106) via a suitable communications network (108). In some implementations, there may be a device gateway for each of the consumer device and merchant device (e.g. a consumer device gateway and a merchant device gateway) which may communicate with each other via the communications network.

The communications network (108) may include one or more networks suitable for the exchange of information, data and messages between the merchant device (104), consumer device (102) and device gateway (106). For example, the communications network (108) may include the Internet, the publically switched telephone network, one or more proprietary payment networks (such as VISANET™, BANKSERV™ etc.) and the like. It should be appreciated that the consumer device (102) and merchant device (104) may communicate with the device gateway (106) via different networks.

The consumer device (102) may be any suitable computing device capable of communicating on the communications network (108). The consumer device (102) may be a mobile computing device, such as a mobile phone (e.g. smartphone), tablet computer, wearable device, portable digital assistant or the like. The consumer device (102) may have a contactless element, such as an NFC, RFID or BLE chip, via which short range, or proximity, communications with compatible devices or tags may be enabled. In some implementations, the consumer device (102) may include a secure element in which payment credentials (in the form of payment card data elements or a pointer to payment card data elements) and/or authentication data may be stored.

The consumer communication device (102) may execute a payment application (103). The payment application (103) may be configured to use the contactless element of the consumer device (102) to conduct financial transactions with participating merchants. The payment application (103) may be developed by a third party and may be available for download from an application repository accessible by the consumer device (e.g. APP STORE, a trade mark of APPLE INC.). The consumer device and/or payment application may be associated with a unique device identifier which may be usable by the device gateway to uniquely identify and/or authenticate the consumer device.

The merchant device (104) may be provided by a suitable computing device which may be capable of communicating on the communications network. The merchant device (104) may for example be in the form of a point of sale terminal (e.g. in the form of a card reader/PIN entry device, etc), a mobile computing device (e.g. a mobile phone, tablet computer, wearable device, portable digital assistant, etc.) or the like. The merchant device (104) may include or be associated with a contactless element, such as an NFC, RFID or BLE chip, via which short range, or proximity, communications with compatible devices may be enabled. The contactless element of the merchant device may be an NFC tag. In some implementations, the contactless element may be a passive contactless element while in other implementations the contactless element may be an active contactless element. In some implementations, the merchant device (104) and contactless element may be physically and/or logically separated from one another, but nevertheless associated with each other (e.g. the contactless element may be in the form of an NFC tag which is linked to the merchant and/or merchant device). In other implementations, the contactless element may be physically and/or logically integrated with the merchant device (104).

The device gateway (106) may be provided by one or more computing devices and may be configured for processing financial transactions between consumers and merchants.

In some implementations, the device gateway (106) may be in communication with a payment processing network including, for example separate payment processors associated with each of an issuing financial institution (an issuer payment processor - 1 10) and an acquiring financial institution (an acquirer payment processor - 1 12) which communicate with each other via a payment network. In some implementations, some or all of the functionality of the device gateway (106) may be provided by a third party and may be integrated into an issuing financial institution’s backend.

The device gateway (106) may have access to a database (1 14) in and from which information and data may be stored and accessed. The database (1 14) may include a merchant record for each merchant registered to make use of the system. Each merchant record may be associated with one or more merchant device identifiers which are uniquely associated with respective merchant devices operated by the merchant. Each merchant record may also include merchant payment information which facilitates the processing of financial transactions in favour of the merchants. The merchant payment information may for example include details of a merchant bank account maintained by an acquiring financial institution on the merchant’s behalf and the like. The database (1 14) may also store records of registered consumers.

The system (100) may enable a contactless financial transaction to be conducted between a consumer associated with the consumer device (102) and a merchant associated with the merchant device (104). The transaction may be initiated by the consumer device (102) performing a read-only contactless interrogation (1 16) of the merchant device (104) (or an associated tag) to obtain a payment reference which is usable in processing the transaction in favour of the merchant. The payment reference may include one or both of a merchant device identifier (typically static) or a transaction identifier (typically dynamic). In some implementations, the payment reference may include or be derived using a cryptographic function which can be validated to ensure that the payment reference is valid.

The system (100) described above may implement a method for contactless financial transactions. The method described in Figure 1 B provides an overview of an exemplary method for contactless financial transactions, while Figure 2 elaborates on aspects relating to this method.

The merchant device (104) may determine (150) transaction details relating to a transaction between a consumer and a merchant. The transaction details are elaborated on below and may include a merchant identifier, an amount, time and date of the transaction and the like. The merchant device (104) may generate (152) or otherwise obtain a payment reference representing the transaction. The merchant device (104) may publish (154) the payment reference for acquisition by the consumer device (for example an NDEF token, as described in greater detail below).

The consumer device (102) may obtain (156) the payment reference from the merchant device (104) (e.g. by reading the NDEF token) and may provide (158) the payment reference to the device gateway (106) via the communication network (108).

The device gateway (106) may receive (160) the payment reference and identify (162) the originating merchant (e.g. by querying the database (1 14) using the payment reference or another identifier). The device gateway (106) may resolve (164) the payment reference, which may include retrieving key transaction information from the merchant device (104), device gateway (106), database (1 14) or the like. The device gateway (106) may retrieve (166) payment credentials associated with the consumer device. The device gateway (106) may obtain consumer consent (168) and may optionally prompt the consumer device (102) for input (e.g. allowing the consumer to select/add missing information about transaction ; asking for consent (of transaction details) and the like). The device gateway (106) may generate cryptographic proof of consumer participation and consent and may submit (170) the transaction details for processing on the payment network.

An exemplary method for contactless financial transactions is illustrated in greater detail in the swim-lane flow diagram of Figure 2A in which respective swim-lanes delineate steps, operations or procedures performed by respective entities or devices.

In one exemplary scenario, a user may be physically present at a merchant and may wish to pay for goods or services being purchased from the merchant. In doing so, the consumer may approach a point of sale having a merchant device (104). The consumer may bring his or her consumer device (102) into contact with or proximity to the merchant device (104). That is, the consumer may‘tap’ the merchant device (104) with the consumer device (102).

The consumer device (102) may perform (202) a read-only contactless communication interrogation of the merchant device (104). The contactless communication interrogation may be an NFC-based contactless communication interrogation. Performing (202) the read-only interrogation may include creating (204) an NFC Data Exchange Format (NDEF) reader session and providing (206) a delegate. The reader session may poll (208) for contactless elements (e.g. NFC tags) which are within range and may call (210) the delegate when it finds a contactless element containing an NDEF message. That is, when the consumer device (102) detects the contactless element of the merchant device (104), the reader session may call the delegate.

The consumer device (102) may receive (212) a payment reference from the merchant device (104) in response to the read-only interrogation. Receiving (212) the payment reference may include the reader session, in response to calling the delegate when it finds a contactless element containing an NDEF message, passing (214) the NDEF message to the delegate. The NDEF message may include the payment reference and optionally other data (e.g. transaction details such as an amount associated with the financial transaction, other merchant identifying information (e.g. a merchant category code, etc.) and the like). Receiving (212) the payment reference may include the delegate reading (216) the NDEF message and handling conditions that can cause a session to become invalid. Such functions or procedures may be accessible via a contactless element API provided by or associated with operating system software of the consumer device (102).

It should be appreciated that communication between the merchant device (104) and consumer device (102) in interrogating for and receiving the payment reference (and optionally other data) may be using read-only contactless communication techniques and thus does not require access to the read/write functionality of a contactless element of the consumer device (102). In other words, the consumer device (102) may not pass any information or data to the merchant device (104) via the contactless communication interface. Accessing the payment reference may therefore be possible using consumer devices which execute more restrictive operating systems, such as IOS which executes on consumer devices manufactured by APPLE INC. As mentioned above, such restrictions may include restricting access to the contactless element of the device to its read-only functionality to third-party developers, for example.

In some implementations, other data, such as transaction details, may accompany the payment reference. In other implementations, the consumer device (102) may interrogate the device gateway (106) to lookup such other data which may be associated with the payment reference.

The consumer device (102) may prompt for and receive (218) a payment credential selection from the consumer. For example, in some implementations, the consumer may register multiple sets of payment credentials (e.g. corresponding to multiple bank cards, credit cards, etc.). Prompting for the payment credential selection may be in response to receiving the payment reference. In other words, the consumer device (102) may be configured to automatically prompt the consumer for his or her payment credential selection in response to receiving a payment reference.

The consumer device (102) may prompt for and receive (220) consumer authentication. The authentication may be biometric authentication and receiving consumer authentication may include receiving and validating a consumer biometric. The consumer biometric may include data relating to a fingerprint or face of the consumer or the like. Validating the consumer biometric may include validating the biometric against biometric validation data stored in a secure element associated with the consumer device (102). In other implementations, authentication may be provided by a passcode or the like. In some implementations, prompting for consumer authentication may be in response to receiving payment credential selection or in response to receiving the payment reference (e.g. in a case where no payment credential selection is required). In some implementations, the consumer may be required to input authentication data relating to the payment credentials (e.g. a card PIN).

In some implementations, the consumer device (102) may prompt for and receive an amount associated with the financial transaction between the merchant and the consumer. In other implementations, this may be received together with the payment reference or obtained from the device gateway (106).

If the consumer is authenticated (e.g. if consumer authentication data is valid), the consumer device (102) may generate (222) a payment authorisation confirmation message. The payment authorisation confirmation message may include the payment reference and optionally other data such as the amount associated with the financial transaction, the unique device identifier, consumer authentication data, a payment credential selection, other data obtained from the merchant device and the like. In some implementations, payment credentials may be included in the message (which may be the selected payment credentials). In some implementations, generating the payment authorisation confirmation message may include generating a cryptogram including or based on the payment credentials and/or other transaction related data (e.g. transaction details, etc.). The cryptogram may be generated by the secure element using the payment credentials (e.g. in the form of a payment token or tokenized PAN) and/or other transaction related data. The cryptogram may be an application cryptogram configured for submission to the payment processing network (in particular the issuer payment processor) for verification to confirm the legitimacy of the transaction. The cryptogram may be in the form of a transaction certificate or equivalent generated by the security element indicating approval of the transaction. Generating the payment authorisation confirmation message may include including the cryptogram in the message.

In some cases, the payment authorisation confirmation message may include confirmation of consumer authentication. The confirmation may be verifiable confirmation. In some implementations, for example, the payment authorisation confirmation message may be signed using a private key that is stored in the secure element and which is only accessible upon consumer authentication. The signed message may be verified by the device gateway (106) using a corresponding public key accessible to the device gateway and optionally associated with the consumer device. The consumer device (102) may transmit (224) the payment authorisation confirmation message to a device gateway (106) for processing the financial transaction. Transmission may be via the communication network (108). In some implementations, transmitting (224) the message may include establishing a secure communication channel with the device gateway (106) and transmitting the message to the device gateway via the secure communication channel. The secure communication channel may be an SSL/TLS communication channel or may be established by encrypting the payload including the message such that only the device gateway can decrypt the payload. In some implementations, the consumer device (102) is uniquely identifiable to the device gateway (106) via the secure communication channel. This may be by way of any one or more of: the unique device identifier, a device digital certificate which is uniquely associated with the device and by using encryption/decryption keys which are uniquely associated with the consumer device (102).

The consumer device (102) may generate (222) and transmit (224) the payment authorisation confirmation message automatically (e.g. without any further user intervention) in response to receiving consumer authentication.

In some implementations, substantially in parallel to the above operations, the merchant device (104) may generate (230) a payment request message. This may be in response to generating or determining transaction details and other data associated with the transaction. The payment request message may include the payment reference and optionally other data, such as an amount associated with the financial transaction, transaction details (which may include the amount and other information), additional merchant-related information (e.g. merchant identifier) and the like. The payment request message may request payment credentials for processing the financial transaction or may request that the financial transaction be processed by the device gateway (106) using payment credentials which the device gateway obtains from the consumer device (102) or a core banking back-end associated with the issuer. Generating the payment request message may include generating the payment reference (e.g. in implementations in which an active contactless element is used in the merchant device (104)) and providing the payment reference to the contactless element of the merchant device for acquisition by the consumer device (102). In some implementations, the payment reference is obtained from the device gateway (106), which may have generated the payment reference and associated it with other data associated with the transaction.

The merchant device (104) may transmit (232) the payment request message to the device gateway (106) via a communication network (108). Transmission may be via a secure communication channel established between the merchant device and the device gateway.

In another implementation, the merchant device (104) may not generate and transmit a payment request message and instead the merchant record stored in the database (1 14) may be relied upon.

The device gateway (106) may receive (240) the payment authorisation confirmation message from the consumer device (102). The message may be received via the communication network (108). In some cases, the payment authorisation confirmation message may be received via a secure communication channel established between the device gateway (106) and the consumer device (102). The consumer device (102) may be uniquely identifiable to the device gateway (106) over the secure communication channel (e.g. by way of the unique device identifier, a device digital certificate and/or encryption/decryption keys). Receiving (240) the payment authorisation confirmation message may include verifying the message, for example using a public key accessible to the device gateway (106) and corresponding to a private key uniquely associated with the consumer device (102) and having been used to sign the message.

The payment authorisation confirmation message relates to the financial transaction between the consumer and the merchant and may include the payment reference and optionally additional data, such as an amount associated with the transaction, consumer authentication data, the unique device identifier, a payment credential selection (or some cases payment credentials) and the like. In some implementations, the payment authorisation confirmation message may include a cryptogram which may have been generated by a secure element in the consumer device (102). As mentioned above, the consumer device (102) may have obtained the payment reference using a read-only contactless communication interrogation of the merchant device (104).

The device gateway (106) may validate (242) the payment reference. Validating (242) the payment reference may include performing an operation on the payment reference to check that it is valid. The operation may for example be a cryptographic operation (e.g. encryption/decryption/hash) to ensure that the identifier is valid. Validating (242) the payment reference may include using the payment reference to query the database (1 14) to identify a merchant record associated with the payment reference. In some cases, validating (242) the payment reference may include comparing the device identifier with a list of registered device identifiers to check whether or not the received payment reference is valid. In some implementations, the device gateway (106) may receive (244) a payment request message from the merchant device (104) via a communication network (108). The payment request message may include the payment reference and optionally other data such as the amount associated with the financial transaction, transaction details and the like.

Validating (242) the payment reference may then include validating (246) the payment references received from the consumer device (102) and merchant device (104) respectively. Validating (246) the payment references may include comparing the payment references for a match. In some implementations, each of the payment authorisation confirmation message and payment request message may be associated with a time to live and validating (246) the payment references may include validating that both messages are received within the time to live. The time to live may for example begin upon receipt of the first message and may require the corresponding second message to be received before expiry of the time to live.

In some implementations, validating the payment reference may include resolving the payment reference, which may include retrieving data (such as transaction details, merchant related data, etc.) associated with the payment reference.

If (248) the payment reference is not valid, the method may terminate (249). If (248) the payment reference is valid, the device gateway (106) may process (250) the financial transaction. Processing (250) the financial transaction may include initiating or scheduling a transfer of funds from a financial account associated with the consumer in favour of a financial account associated with the merchant. In some implementations, processing the financial transaction may include forwarding the cryptogram and other related data (e.g. payment credentials, transaction details, etc.) to the payment processing network for processing the transaction.

In some implementations, processing (250) the financial transaction may include a hardware security module (HSM) generating a cryptogram usable by the payment network to initiate and/or schedule the transfer for funds. The cryptogram may for example be a three-domain secure compatible cryptogram which is passed to the merchant device and/or acquirer payment processor (1 12).

Different implementations may effect processing (250) of the financial transaction differently. In one implementation, the device gateway (106) may provide payment credentials associated with the consumer to the merchant device (104) for submission to a payment processing network (e.g. to an acquirer payment processor (1 12)) in order to initiate or schedule the transfer of funds (e.g. as described below with reference to Figure 2B). In another implementation, the device gateway (106) may provide the payment credentials directly to the payment processing network (e.g. to an acquirer payment processor (1 12)) on behalf of the merchant device (104) in order to initiate or schedule the transfer of funds (e.g. as described below with reference to Figure 2C).

In some implementations, processing the financial transaction may be preceded by the device gateway (106) and/or issuer payment processor (1 10) transmitting a transaction detail approval message to the consumer device (102), the transaction detail approval message including transaction details (e.g. amount, nature of transaction, recipient identifier, etc.) and prompting the consumer for his or her approval of the transaction details (e.g.“Do you agree to pay merchant A $507”), and receiving a transaction detail approval response from the consumer device (102) indicating the consumer’s approval or denial as the case may be. Consumer approval may be input in the form of ‘yes’/’no’ input, authentication (e.g. passcode/biometric) input or the like. In some implementations, the transaction detail approval message may include a prompt for missing information (e.g. a loyalty identifier, etc.). The transaction detail approval message may provide the consumer with an opportunity to consent to the transaction. In other cases, the consumer performing the tap may constitute the consent.

In some implementations, the device gateway (106) may generate cryptographic proof of consumer participation and consent. This may include digitally signing a data record including one or more of: the payment reference, the transaction details and other data associated with the transaction, the unique consumer device identifier, the transaction detail approval message, the transaction detail approval response, confirmation of verification of the payment authorisation confirmation message, and the like.

Once the financial transaction has been processed, payment confirmation messages may be transmitted (252) to one or both of the consumer device (102) and merchant device (104). The devices (102, 104) may receive (254, 256) their respective payment confirmation messages. Receipt of the payment confirmation message at the merchant device (104) may indicate to the merchant that the transfer of funds has been initiated or scheduled and that the merchant may release the goods or services to the consumer.

Figures 2B and 2C illustrate two possible implementations for processing (250) the financial transaction. In the example embodiment of Figure 2B, the device gateway (106) may retrieve (260) payment credentials associated with the unique device identifier of the consumer device (102). Retrieving (260) the payment credentials may include retrieving the payment credentials from a core banking back-end associated with the issuer payment processor (1 10) or retrieving the payment credentials from a secure element associated with the consumer device (102). In some implementations, retrieving the payment credentials may include retrieving a payment token configured for use as single-use payment credentials (which may be generated by the core banking back-end or the secure element).

The device gateway (106) may generate (262) a payment response message which may include the payment credentials and optionally other data such as the payment reference, transaction details, etc. The device gateway (106) may transmit (264) the payment response message to the merchant device (104). Transmission may be via the communications network (108).

The merchant device (104) may receive (266) the payment response message from the device gateway (106). The merchant device (104) may forward the payment credentials to a payment processing network for processing of the financial transaction against the payment credentials in favour of the merchant.

This may include the merchant device (104) using the payment response message to generate (268) a payment authorisation request message. In some implementations, the payment authorisation request message may be generated at the merchant device (104) in a manner which corresponds to the manner in which an authorisation request message would conventionally be generated if a payment card PIN retrieval and reading had taken place at the merchant device. The payment authorisation request message may include the payment credentials, and optionally other data such as the payment reference, a merchant identifier, transaction details, other merchant-related information and the like. In some implementations, the payment authorisation request message may be in the form of (or resemble) an ISO 8583 authorisation request message which includes the payment credentials.

The merchant device (104) may transmit (270) the payment authorisation request message to the acquirer payment processor (1 12) for processing the financial transaction. This may include transmitting the payment authorisation request message to the acquirer payment processor (1 12) for on forwarding to the issuer payment processor (1 10) via a payment network. In other words, the payment authorisation request may be processed as a conventional (e.g. ISO 8583) authorisation request message.

The acquirer payment processor (1 12) may receive (272) the payment authorisation request message and may forward (273) the message to the issuer payment processor (1 10). The issuer payment processor (1 10) may receive (274) the message and may initiate or schedule (275) the transfer of funds from a financial account associated with the payment credentials and in favour of a financial account associated with the merchant. This may include performing the required authorisations, balance checks and the like. The transfer of funds may be initiated or scheduled in accordance with the particulars of the message. Initiating or scheduling (275) the transfer of funds may include an exchange of suitable messages (e.g. ISO 8583 messages) between the issuer payment processor (1 10) and acquirer payment processor (1 12) via the payment network and may be followed by reconciliation, settlement, etc.

The issuer payment processor (1 10) may transmit (276) a payment confirmation message confirming that the financial transaction has been processed against the payment credentials in favour of the merchant account. The payment confirmation message may be transmitted to either or both of the consumer device (102) and the merchant device (104). Transmission of the payment confirmation message to the merchant device (104) may be via the acquirer payment processor (1 12) and payment network.

The merchant device (104) may receive (278) the payment confirmation message confirming that the financial transaction has been processed against the payment credentials in favour of the merchant account. Once the payment confirmation messages have been received, the merchant may for example release goods associated with the financial transaction to the consumer.

In the example embodiment of Figure 2C, the device gateway (106) may retrieve (280) payment credentials associated with the unique device identifier of the consumer device (102). Retrieving (280) the payment credentials may be performed in a manner which is similar to that which is described above with reference to Figure 2B. The device gateway (106) may then submit the payment credentials to a payment processing network for processing the financial transaction against the payment credentials in favour of the merchant.

This may include the device gateway (106) generating (282) a payment authorisation request message. In some implementations, the payment authorisation request message may be generated at the device gateway (106) in a manner which corresponds to the manner in which an authorisation request message would conventionally be generated if a payment card PIN retrieval and reading had taken place at the merchant device (104). The payment authorisation request message may include the payment credentials, and optionally other data such as the payment reference, transaction details, a merchant identifier, other merchant-related information and the like. In some implementations, the payment authorisation request message may be in the form of (or resemble) an ISO 8583 authorisation request message which includes the payment credentials.

The device gateway (106) may transmit (284) the payment authorisation request message to the payment processing network for processing the financial transaction. Transmitting the message to the payment processing network may include transmitting the message to the acquirer payment processor (1 12) or the issuer payment processor (e.g. so as to act as and/or bypass the acquirer payment processor). This may include transmitting the payment authorisation request message to the acquirer payment processor (1 12) for on forwarding to the issuer payment processor (1 10) via a payment network. In other words, the payment authorisation request may be processed as a conventional (e.g. ISO 8583) authorisation request message.

The payment processing network may receive the payment authorisation request message and may process the financial transaction in accordance with the particulars included in the message. Processing the financial transaction may include an exchange of suitable messages (e.g. ISO 8583 messages) between the issuer payment processor and acquirer payment processor via the payment network. The payment processing network may generate and transmit a payment confirmation message to the device gateway (106). The payment confirmation message may confirm that the financial transaction has been processed against the payment credentials in favour of the merchant account. The payment processing network processing the financial transaction may entail performing operations similar to (272) to (275) described above with reference to Figure 2B.

The device gateway (106) may receive (286) the payment confirmation message from the payment processing network.

The device gateway (106) may forward (288) the payment confirmation message to the merchant device (104). The message may be forwarded to the merchant device (104) via the communications network (108). The merchant device (104) may receive (290) the payment confirmation message confirming that the financial transaction has been processed against the payment credentials in favour of the merchant account. The merchant device (104) may complete the transaction based on the payment confirmation message. The payment confirmation message may resemble a payment network-based payment confirmation message (e.g. an authorisation response message or other appropriate ISO 8583 message). Thus from the perspective of the merchant device (104), the payment confirmation message may resemble a standard message confirming success of the financial transaction and allowing the merchant to release the goods or otherwise finalise the transaction.

In some implementations, the transaction may be submitted via an alternate channel (e.g. from mobile side only) and the payment confirmation message may be returned to the merchant device (104) only.

It should be appreciated that from the perspective of the consumer the above-described method may be substantially the same as a conventional contactless-based transaction. However, as mentioned, the transaction may be conducted using read-only functionality of the contactless element of the consumer device (102). The method may therefore find broad application, in particular on devices with restrictive operation systems which only provide read-only access to their associated contactless elements.

Various components may be provided for implementing the method described above with reference to Figures 2A to 2C. Figure 3 is a block diagram which illustrates exemplary components which may be provided by a system (300) for contactless financial transactions. The system (300) may include a consumer device (102), a merchant device (104) and a device gateway (106).

The consumer device (102) may include a processor (302) for executing the functions of components described below, which may be provided by hardware or by software units executing on the consumer device (102). The software units may be stored in a memory component (304) and instructions may be provided to the processor (302) to carry out the functionality of the described components. Some or all of the components may be provided by a payment application (103) downloadable onto and executable on the consumer device (102).

The consumer device (102) may include a secure element (308). The secure element (308) may provide a secure memory and/or processor and may be configured for secure storage and process of data. The secure element (308) may store one or more of payment credentials, consumer authentication data, the unique device identifier, a device digital certificate, encryption keys, and the like. The secure element may be configured to perform cryptographic operations, generate payment tokens (which may function as pointers to payment credentials), encryption keys, encrypt and decrypt data and the like.

The consumer device (102) may include a contactless element (309). The consumer device (102) may include a contactless interrogation component (310) arranged to perform a read-only contactless communication interrogation of a merchant device (104). The contactless interrogation component (310) may interface with the contactless element (309). In some implementations, the contactless interrogation component (310) may interface with the contactless element via an API (31 1 ) provided by or integrated with operating system software of the consumer device (102). The API (31 1 ) may expose read-only functionality of the contactless element. The API (31 1 ) may provide functions and/or procedures for creating NDEF (NFC Data Exchange Format) reader sessions, providing delegates, handling messages and the like.

The consumer device (102) may include a payment reference receiving component (312) which may be arranged to receive a payment reference from the merchant device in response to the read-only interrogation.

The consumer device (102) may include a payment message generating component (314) which may be arranged to generate a payment authorisation confirmation message including the payment reference (and optionally other data as well). The payment message generating component (314) may be configured to access the payment credentials from the secure element (308), in some implementations in response to the consumer authenticating him- or herself, in response to a request from the device gateway or the like.

The consumer device (102) may include a payment authorisation confirmation message transmitting component (316) which may be arranged to transmit, via a communication network, the payment authorisation confirmation message to the device gateway (106) for processing the financial transaction.

The consumer device (102) may include any further components required to perform the methods described above with reference to Figures 2A to 2C. The merchant device (104) may include a processor (332) for executing the functions of components described below, which may be provided by hardware or by software units executing on the merchant device (104). The software units may be stored in a memory component (334) and instructions may be provided to the processor (332) to carry out the functionality of the described components. Some or all of the components may be provided by a software application downloadable onto and executable on the merchant device (104).

The merchant device (104) may include or be associated with a contactless element (336). The contactless element (336) may be configured to provide a payment reference to a consumer device (102) via read-only contactless communication interrogation of the contactless element by the consumer device. The payment reference may be provided for submission by the consumer device (102) to the device gateway (106) to process a financial transaction between a consumer and a merchant.

The contactless element (336) may be an active or passive contactless element. In the case of an active contactless element, the contactless element may be physically and/or logically associated with the merchant device (104). The merchant device may for example include a contactless element interface (337) by way of which information and/or data may be exchanged between, e.g., the processor and the contactless element. In other implementations, the contactless element may be in the form of a passive tag which is physically and/or logically isolated from the merchant device (104). In such a case, the payment reference may be hardcoded into the contactless element (336).

The merchant device (104) may include a device gateway interface (338) via which the merchant device may exchange messages and data with the device gateway (106). The merchant device (104) may also include a payment processing network interface (340) via which the merchant device may exchange messages and data with one or more payment processing networks (including, e.g., an acquirer payment processor).

The merchant device (104) may include a messaging component (342) arranged to exchange messages between the device gateway (106) and/or a payment processing network, via the appropriate interfaces. The messaging component (342) may for example be configured to receive a payment confirmation message confirming processing of the financial transaction. The messaging component (342) may be configured to generate and transmit a payment request message, receive a payment response message and the like. The merchant device (104) may include any further components required to perform the methods described above with reference to Figures 2A to 2C.

The device gateway (106) may include a processor (352) for executing the functions of components described below, which may be provided by hardware or by software units executing on the device gateway (106). The software units may be stored in a memory component (354) and instructions may be provided to the processor (352) to carry out the functionality of the described components. In some cases, software units arranged to manage and/or process data on behalf of the device gateway (106) may be provided remotely and/or distributed across multiple computing devices.

The device gateway (106) may include a consumer device interface component (356) and a merchant device interface component (358), each of which is configured to exchange messages and data with the consumer device (102) and merchant device (104) respectively. The consumer device interface may be configured to establish a secure communication channel with the consumer device via which the consumer device may be uniquely identifiable to the device gateway (e.g. by way of the unique device identifier, a device digital certificate and/or encryption/decryption keys). The device gateway (106) may include a payment processing network interface (360) configured to exchange messages and data with a payment processing network (including, e.g., issuer and acquirer payment processors, etc.).

The device gateway (106) may include a messaging component (362) arranged to exchange messages between the consumer device (102), merchant device (104) and/or a payment processing network, via the appropriate interfaces.

The device gateway messaging component (362) may for example include a payment authorisation confirmation message receiving component (364) which may be arranged to receive, via a communication network, a payment authorisation confirmation message from the consumer device (102). The payment authorisation confirmation message may relate to a financial transaction between a consumer and a merchant and may include a payment reference and optionally other data. As mentioned, the consumer device (102) may have obtained the payment reference using a read-only contactless communication interrogation of a merchant device (104).

The device gateway (106) may include a validating component (366) which may be arranged to validate the payment reference.

The device gateway (106) may include a transaction processing component (368) which may be arranged to process, if the payment reference is valid, the financial transaction using the payment reference and payment credentials.

The device gateway (106) may include any further components required to perform the methods described above with reference to Figures 2A to 2C.

Aspects of this disclosure may enable a merchant to submit a payor details request (in the form of a payment authorisation request) to the device gateway (106), together with a payment reference, and receive, from the device gateway, the correct card details linked to the consumer device (102) that scanned the corresponding payment reference, allowing the merchant device (104) to submit the transaction.

Figure 4 illustrates an example of a computing device (400) in which various aspects of the disclosure may be implemented. The computing device (400) 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 (400) 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 (400) to facilitate the functions described herein. The computing device (400) may include subsystems or components interconnected via a communication infrastructure (405) (for example, a communications bus, a network, etc.). The computing device (400) may include one or more processors (410) and at least one memory component in the form of computer-readable media. The one or more processors (410) 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 (400) 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 (415), 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 (415) including operating system software. The memory components may also include secondary memory (420). The secondary memory (420) may include a fixed disk (421 ), such as a hard disk drive, and, optionally, one or more storage interfaces (422) for interfacing with storage components (423), 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 (400) may include an external communications interface (430) for operation of the computing device (400) in a networked environment enabling transfer of data between multiple computing devices (400) and/or the Internet. Data transferred via the external communications interface (430) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (430) may enable communication of data between the computing device (400) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (400) via the communications interface (430).

The external communications interface (430) 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 (430) 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 (400). One or more subscriber identity modules may be removable from or embedded in the computing device (400).

The external communications interface (430) may further include a contactless element (450), 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 (450) may be associated with (e.g., embedded within) the computing device (400) and data or control instructions transmitted via a cellular network may be applied to the contactless element (450) 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 (450). The contactless element (450) 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 (400) and an interrogation device. Thus, the computing device (400) 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 (410). A computer program product may be provided by a non-transient computer-readable medium, or may be provided via a signal or other transient means via the communications interface (430).

Interconnection via the communication infrastructure (405) allows the one or more processors (410) 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 (400) either directly or via an I/O controller (435). One or more displays (445) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (400) via a display (445) or video adapter (440).

The computing device (400) may include a geographical location element (455) which is arranged to determine the geographical location of the computing device (400). The geographical location element (455) may for example be implemented by way of a global positioning system (GPS), or similar, receiver module. In some implementations the geographical location element (455) 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 (400). In some implementations, the geographical location element (455) 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 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, Java™, 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.

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, which is set forth in the following claims.

Finally, throughout the specification unless the contents 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

CLAIMS:

1. A computer-implemented method conducted at a consumer device comprising:

performing a read-only contactless communication interrogation of a contactless element associated with a merchant device;

receiving a payment reference from the contactless element in response to the read-only interrogation;

generating a payment authorisation confirmation message including the payment reference, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant; and,

transmitting, via a communication network, the payment authorisation confirmation message to a device gateway for processing the financial transaction.

2. The method as claimed in claim 1 , including prompting for and receiving a payment credential selection, wherein the payment authorisation confirmation message includes the payment credential selection, and wherein prompting for payment credential selection is in response to receiving the payment reference.

3. The method as claimed in claim 1 or claim 2, wherein generating the payment authorisation confirmation message includes generating a cryptogram including or based on one or both of payment credentials and transaction related data.

4. The method as claimed in any one of the preceding claims, including prompting for and receiving consumer authentication, wherein the authentication is biometric authentication and wherein receiving consumer authentication includes receiving and validating a consumer biometric, wherein prompting for consumer authentication is in response to receiving payment credential selection, and wherein generating and transmitting the payment authorisation confirmation message is automatically in response to receiving consumer authentication.

5. The method as claimed in any one of the preceding claims, wherein performing the read only interrogation includes:

creating an NDEF reader session and providing a delegate; and,

the reader session polling for contactless elements and calling the delegate when it finds a contactless element containing an NDEF message.

6. The method as claimed in claim 5, wherein receiving the payment reference includes, in response to the reader session calling the delegate when it finds the contactless element containing an NDEF message:

the reader session passing the NDEF message to the delegate, the NDEF message including the payment reference; and,

the delegate reading the NDEF message to obtain the payment reference.

7. A computer-implemented method conducted at a merchant device comprising:

providing a payment reference via a contactless element configured for read-only contactless communication interrogation by a consumer device, the payment reference being provided for submission by the consumer device to a device gateway to process a financial transaction between a consumer and a merchant; and,

receiving a payment confirmation message confirming processing of the financial transaction.

8. The method as claimed in claim 7, including:

generating a payment request message including the payment reference and optionally an amount in respect of the financial transaction; and,

transmitting the payment request message to the device gateway via a communication network.

9. The method as claimed in claim 7 or claim 8, including:

receiving a payment response message from the device gateway, wherein the payment response message includes payment credentials associated with the consumer;

generating a payment authorisation request message including the payment credentials; and,

transmitting the payment authorisation request message to an acquirer payment processor for processing the financial transaction against the payment credentials in favour of the merchant.

10. A computer-implemented method conducted at a device gateway comprising:

receiving, via a communication network, a payment authorisation confirmation message from a consumer device, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and includes a payment reference having been obtained by the consumer device using a read-only contactless communication interrogation of a contactless element associated with a merchant device;

validating the payment reference; and,

if the payment reference is valid, processing the financial transaction using the payment reference and payment credentials.

1 1 . The method as claimed in claim 10, including:

receiving, via a communication network, a payment request message from the merchant device, wherein the payment request message includes the payment reference, and wherein one or both of the payment authorisation confirmation message or the payment request message includes an amount in respect of the financial transaction,

and wherein validating the payment reference includes validating the payment references received from the consumer device and merchant device respectively.

12. The method as claimed in claim 1 1 , wherein validating the payment references includes comparing the payment references for a match.

13. The method as claimed in any one of claims 10 to 12, including:

transmitting a transaction detail approval message to the consumer device, the transaction detail approval message including transaction details and prompting the consumer for his or her approval of the transaction details; and,

receiving a transaction detail approval response from the consumer device indicating consumer approval or denial.

14. The method as claimed in any one of claims 10 to 13, including retrieving payment credentials associated with the consumer device.

15. The method as claimed in claim 14, wherein processing the financial transaction includes processing the financial transaction against the payment credentials in favour of a merchant associated with the payment reference.

16. A system including a consumer device having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the consumer device comprising:

a contactless interrogation component for performing a read-only contactless communication interrogation of a contactless element associated with a merchant device; a payment reference receiving component for receiving a payment reference from the contactless element in response to the read-only interrogation;

a payment message generating component for generating a payment authorisation confirmation message including the payment reference, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant; and,

a payment authorisation confirmation message transmitting component for transmitting, via a communication network, the payment authorisation confirmation message to a device gateway for processing the financial transaction.

17. A system including a merchant device having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the merchant device comprising:

a contactless element configured to provide a payment reference to a consumer device via read-only contactless communication interrogation of the contactless element by the consumer device, the payment reference being provided for submission by the consumer device to a device gateway to process a financial transaction between a consumer and a merchant; and, a messaging component for receiving a payment confirmation message confirming processing of the financial transaction.

18. A system including a device gateway having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the device gateway comprising:

a payment authorisation confirmation message receiving component for receiving, via a communication network, a payment authorisation confirmation message from a consumer device, wherein the payment authorisation confirmation message relates to a financial transaction between a consumer and a merchant and includes a payment reference having been obtained by the consumer device using a read-only contactless communication interrogation of a contactless element associated with a merchant device;

a validating component for validating the payment reference; and,

a transaction processing component for, if the payment reference is valid, processing the financial transaction using the payment reference and payment credentials.

19. A computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: performing a read-only contactless communication interrogation of a contactless element associated with a merchant device;

20 A computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of:

validating the payment reference; and,