WO2022260782A1

WO2022260782A1 - Wireless terminal apparatus and method

Info

Publication number: WO2022260782A1
Application number: PCT/US2022/027583
Authority: WO
Inventors: Patrick Mestre
Original assignee: Mastercard International Incorporated
Priority date: 2021-06-10
Filing date: 2022-05-04
Publication date: 2022-12-15
Also published as: GB202108281D0; EP4352679A1

Abstract

A method of performing an interaction over a wireless communication network between a first device and a second device is described. The result of this interaction is for processing by a discrete processing system according to a set of protocols. The interaction itself may be processed by a plurality of kernels on the first device and a plurality of applications on the second device. To establish which kernel and application will be used, the following steps are taken. The first device establishes from the plurality of kernels a plurality of possible applications for processing the interaction at the second device, the first device obtaining from the kernels information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction, and provides a message to the second device identifying the plurality of possible applications and the information needed for all the plurality of possible applications. The second device selects one of the plurality of possible applications at the second device and runs that application using the information provided for that application to produce interaction data for the interaction. The second device then sends the choice of application and the interaction data to the first device. This is then provided to the appropriate kernel at the first device which uses the interaction data to obtain an interaction result for processing by the discrete processing system from said one of the plurality of kernels.

Description

WIRELESS TERMINAL APPARATUS AND METHOD

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of United Kingdom Patent Application No. 2108281.3, which was filed on June 10, 2021, the entire contents of which are hereby incorporated by reference for all purposes.

TECHNICAL FIELD

The present disclosure relates to a wireless terminal apparatus and an associated method. The method and apparatus are particularly suitable for use when one of several different applications may be used at a c lient device for interaction with the terminal device.

BACKGROUND

Payment cards such as credit cards and debit cards are very widely used for all forms of financial transaction. The use of payment cards has evolved significantly with technological developments over recent years. Originally, transactions were on paper, using an imprint of a transaction card and confirmed by a signature. This approach was largely replaced by use of a magnetic stripe of a transaction card swiped through a magnetic stripe reader on a point of sale (POS) terminal to perform a transaction. Transaction cards developed to contain an integrated circuit (“chip cards” or “smart cards”) that communicates with a smart card reader in the POS terminal. Using this approach, a transaction is typically confirmed by a personal identification number (PIN) entered by the card user. Cards of this type typically operate under the EMV® specification for interoperation of chip cards and associated apparatus (such as POS terminals and ATMs). For contact communications the EMV specifications are based on the ISO/IEC 7816 standards for operation of cards of this type. Contactless payments are now possible between suitably enabled payment cards or devices and merchant terminals by short range wireless technology proximity protocols, and the EMV specifications implement contactless communication based on the ISO/IEC 14443 standard. Payment cards and devices are provided under a transaction scheme (such as Mastercard, American Express or Visa) and the transaction mechanism is mediated by the transaction scheme infrastructure. EMV chip specifications relate to contact and contactless payment protocols and are publicly available at the EMVCo website (EMVCo is the industry' body tasked with maintaining these specifications with the support of major transaction scheme providers) - https://www.emvco.com/document-searcb/ - and would readily be consulted by the person skilled in the art. Terminology relating to EMV technology not expressly defined in this document is referenced and defined in EMV specifications, as will be appreciated by the person skilled in the art.

A transaction scheme or payment card scheme - involving a payment network linked to a payment card - is typically based on one of two models: a three- party model (adopted by American Express) or a four-party model (adopted by Visa and Mastercard). The relevant parties in the four-party model include a merchant, an acquirer, an issuer and a cardholder. Typically, the four-party model of a credit card or debit card purchase involves an exchange of authorisation request and response messages between the parties prior to the settlement of funds between the cardholder and the merchant. The messages may include transaction data such as a primary account number, a transaction amount, a merchant identifier, and a date and time of the transaction.

Merchant terminals are connected to the acquirer (acquiring bank) supporting the merchant. A transaction is routed to the acquirer from the merchant, and then through the transaction system network provided by the payment scheme provider to the issuer (issuing bank) for the consumer (cardholder). The issuer uses transaction information and its knowledge of the cardholder to determine whether to authorise the transaction, with an authorisation result being routed back through the transaction system infrastructure to the merchant.

Protocols for performing and processing transactions using payment schemes of this type are defined by payment schemes or in some cases by national bodies, with these being typically based on ISO 8583 or its replacement ISO 20022. EMV specifications enable common implementations of such protocols according to specifications developed in connection with EMVCo, with specifications being publicty available as indicated above.

A developing form of transaction is over a short range between a user device (also termed here a consumer device) and a merchant terminal using a wireless communications technology. Currently, such transactions can be conducted as contactless transactions using a contactless protocol, or as e-commerce transactions. Both of these approaches have some disadvantages when compared with a “chip-and- PIN” contact solution. As contactless transactions are triggered by proximity alone, they require special security management, and in most jurisdictions have a low transaction threshold. Online transactions also require a set of specific security protocols which will tend to make the transaction process more complex than for a contact transaction. In short range “wireless” contexts, where a user payment device can communicate locally over an appropriate protocol with a merchant terminal, the payment device will typically be a user mobile phone handset - the merchant terminal is a local computing device that may act as a client to a service provided in the cloud. In these circumstances, it would be desirable to provide a rich set of payment options for the user and to allow full use of the mobile phone interface, while for efficiency it is still desirable that communication between the payment device and the merchant terminal will be constrained. Similar to contactless transactions today, it may w'ell be that for wireless payments the consumer device supports products using different data exchange protocols wlrile the terminal also supports products using different data exchange protocols

The present disclosure has been devised to mitigate or overcome at least some of the above-mentioned problems.

SUMMARY OF THE DISCLOSURE

According to a first aspect of the present disclosure there is provided a method of performing an interaction over a wireless communication network between a first device and a second device for processing by a discrete processing system according to a set of protocols, wherein the interaction may be processed by a plurality of kernels on the first device and a plurality of applications on the second device, wherein: the first device establishes from the plurality of kernels a plurality of possible applications for processing the interaction at the second device, the first device obtaining from the kernels information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction; the first device providing a message to the second device identifying the plurality of possible applications and the information needed for all the plurality of possible applications; the first device receiving from the second device a choice of application from the possible applications and interaction data from the chosen application at the second device for processing by said one of the kernels adapted to support that application; the first device obtaining an interaction result for processing by the discrete processing system from said one of the plurality of kernels.

This approach leads to a particularly effective and flexible response which minimises the number of wireless interactions between the first device and the second device while still allowing the best choice of possible application to be made.

In embodiments, the communications to and from the second device may be mediated through a wireless entry' point, such that the kernels communicate only with the wireless entry point.

In particular embodiments, the interaction is a transaction between a merchant represented by the first device and a consumer represented by the second device acting as a payment device, wherein the discrete processing system is a payment processing network, and the interaction result is a request to authorize the transaction.

In such cases, each of the plurality of kernels may be adapted to provide merchant processing of a transaction performed with one or more payment applications, wherein a payment application is used for processing of a transaction on a payment device. Establishing from the plurality of kernels a plurality of possible applications may then comprise for at least one kernel determining and identifying allowable payment application and transaction type combinations, and it may also comprise providing from that kernel the said combinations together with transaction and merchant information needed by the payment application of each said combination for processing the transaction. This may further comprise said at least one kernel generating an unpredictable number and providing the unpredictable number with said combinations and said information.

In such cases, the interaction data received from the second device may comprise transaction data including an application cryptogram, wherein the interaction result includes a request to authorize the transaction including the application cryptogram. This interaction data may further comprise a cardholder verification strategy and result, and wherein the kernel processing the interaction data determines whether the cardholder verification strategy and result allows a legitimate request for authorization of the transaction.

In a second aspect, the disclosure provides a computing device comprising a processor, a memory, and a wireless communication means, wherein the computing device is programmed to perform the method of the first aspect as set out above. This computing device may be a merchant point-of-sale terminal.

In a third aspect, the disclosure provides a method of performing an interaction over a wireless communication network between a first device and a second device for processing by a discrete processing system according to a set of protocols, wherein the interaction may be processed by a plurality of kernels on the first device and a plurality of applications on the second device, wherein: the second device receives a message from the first device identifying a plurality of possible applications for processing the interaction at the second device and the information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction; selecting one of the plurality of possible applications at the second device; at the second device, running said one of the plurality of possible applications using the information for that possible application from the message received from the first device to produce interaction data for the interaction; and sending to the first device a response message comprising a choice of application from the possible applications and interaction data from the chosen application for processing by said one of the kernels adapted to support that application.

In particular embodiments, the interaction is a transaction between a merchant represented by the first device and a consumer represented by the second device acting as a payment device, wherein the discrete processing system is a payment processing network, and the response message is sent to enable the first device to request authorization of the transaction through the payment processing network.

In such case, receiving the message from the first device may comprise receiving a message identifying allowable payment application and transaction type combinations supported by the first device, together with for the said combinations transaction and merchant information needed by the payment application of each said combination for processing the transaction. The possible applications for processing the interaction may then be payment applications and selecting one of the plurality of possible applications may comprise selecting a payment application for processing the transaction and providing the transaction and merchant information provided in the message to the payment application for processing of the transaction at the second device. The method may further comprise determining a cardholder verification strategy and, if required by the cardholder verification strategy, performing a cardholder verification action for inclusion in the processing of the transaction. Processing of the transaction by the selected payment application may comprise determining whether to complete the transaction and providing an application cryptogram to enable authorisation of the transaction through the payment processing system.

In a fourth aspect, the disclosure provides a computing device comprising a processor, a memory, and a wireless communication means, wherein the computing device is programmed to perform the method of the third aspect as set out above. This computing device may be a payment device, and may be a handheld computing device, such as a mobile telephone handset. Such a payment device may comprise a wallet application for interaction with merchant devices and for management of payment cards associated with the cardholder, and a plurality of payment applications accessible to the wallet application.

BRIEF DESCRIPTION OF TFIE DRAWINGS

One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a transaction ecosystem including a payment system along with other parties acting and interacting in the transaction system;

Figure 2 illustrates schematically a terminal system, including its key elements and its set of interactions with other transaction ecosystem elements;

Figure 3 shows an overall transaction flow according to embodiments of the disclosure;

Figure 4 shows exemplary kernel processing of a pre process message in the transaction flow of Figure 3;

Figures 5 A and 5B show exemplary' kernel processing of a prepare authorization data message in the transaction flow of Figure 3; and

Figure 6 shows schematically a transaction system using the four-party model.

DETAILED DESCRIPTION

General and specific embodiments of the disclosure will be described below with reference to the Figures. Figure 1 shows an architecture according to an embodiment of the disclosure appropriate for interaction between a cardholder and a merchant. This embodiment relies on the four-party model for payment interactions, which will be described in more detail in Figure 4 below.

The cardholder 1 uses their computing device - which may be for example a cellular telephone handset, a tablet, a laptop, or any other suitable computing device (here a cellular telephone handset or smartphone 11 is shown) - to act either as a proxy for a physical payment card 6 or as a virtual payment card operating only in a digital domain. The conventional interaction between a physical payment card 6 and a merchant POS terminal 7 is shown, but the smartphone 11 achieves this with a mobile payment application and typically a digital wallet 17 which may be siting within the transaction scheme infrastructure 5. The smartphone 11 is here able to transact with a merchant POS terminal 7 locally wirelessly using an appropriate short range wireless technology. In embodiments of interest here, the merchant 2 may be supported by a cloud service 18 for which the merchant POS terminal 7 is acting as a client.

The transaction scheme infrastructure (transaction infrastructure) 5 here provides not only the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer 3 and the issuer 4, but also a wallet service 17 to support a digital wallet on the cardholder computing device. Other elements may be present to support digital domain transactions - for example, an internet gateway for a merchant server and a tokenisation provider for tokenising digital cards and an associated digital enablement service - but a main consideration in embodiments of the disclosure is the handling of transactions between a card or other cardholder payment device and a terminal, as the terminal to acquirer connection is under particular consideration. This may have limited ability to carry additional data, or may only be adapted for handling of transaction data according to legacy protocols- in particular, an existing terminal to acquirer connection may not be suitable to handle additional information beyond that provided in a conventional EMVCo protocol transaction.

An exemplary POS terminal for implementing an embodiment of the disclosure is shown in Figure 2, and details of a transaction flow according to an embodiment of the disclosure are set out in detail in Figure 3. Before discussing the details of this terminal and this transaction flow, it is desirable to set out the elements of a transaction between a payment device and a terminal for a transaction according to normal EMV protocols used for contact transactions, and for the modifications made for the contactless case. In contact EMV:

The terminal and payment device make an application choice. There are a number of possible payment applications on a payment device - these are proprietary to payment system providers, and a payment device may have several payment applications a vailable - in the case of a payment device such as a mobile telephone, these may be multiple payment applications from multiple issuers using multiple payment system providers. Payment applications are identified by an Application Identifier (AID).

The terminal reads data from that application.

Data is authenticated offline to make sure the card associated with the payment device is not a counterfeit.

Confirmation of the transaction and of the payment device takes place.

Cardholder verification is done for example with a PIN.

Transaction checks are made at the terminal - for example, for floor limits and the like. This is typically done if there is a choice of authorisation option, but if there is not - for example, if all authorisation will be online, as is increasingly the case - then this step may not be necessary.

The terminal requests approval for the transaction.

The card approves the transaction.

An online authorization request and authentication are completed and sent to the payment authorizer.

The transaction is finalized, and an issuing response is sent back to the card.

Some variation to this model is required for contactless and online transactions. For online transactions, the existing model has been to treat these as “cardholder not present” transactions and to add additional processes for authentication - for example, the additional verification process of 3D-Secure - to ensure security.

For contactless transactions, the process and the security model are limited by the short time period of the transaction and the reliance on physical control and proximity. In EMV protocols, the early stage of a transaction process is governed by the Entry Point specification - the Entry Point specification for contactless transactions is found at https://wwiy.enTvco.com/terms-of-use/⁹u^:::7wp- content/uploa.ds/docitments/B Entry Point Specification v2 7 Finai.pdf. This specification defines five main functional sections: preliminary transaction processing ( also called pre-processing), which is processing prior to the activation of the contactless interface of the reader and before the cardholder is invited to present a contactless card; protocol activation, which is activation of the contactless interface; combination selection, which is selection of the combination to use for the transaction; kernel activation, where Entry Point activates the selected kernel and this begins kernel processing; and outcome processing, where Entry Point processes an outcome according to the type of outcome and the values of the outcome par ameters.

Figure 2 shows the functional arrangement provided by the POS terminal 7 and its interactions with other system elements - here, this is similar to existing contactless architectures in that it also uses an entry point approach. The POS terminal 7 communicates with the transaction scheme infrastructure 5 (also referred to here as the payment scheme network) for processing of the transaction. Interaction with the consumer device 11 is through a wireless connection 20 with the wireless entry point 21 (WEP, or wireless EP) of the terminal 7. The wireless EP 21 is in communication with a number of different wireless kernels 22 (Kernel 1, Kernel 2, ... Kernel N). These wireless kernels are all adapted to interact with different payment applications - a particular payment application on the consumer device 11 will typically not be supported unless there is a wireless kernel in the terminal adapted to support it. The kernels 22 will only communicate via the wireless EP 21. The consumer device is here showm as having a number of payment applications 23 which each may or may not match one of the kernels in the terminal 7 - interaction with these payment applications 23 is by means of a wallet application 25 which also provides the user interface for the user of the consumer device 11. Here, the wireless EP 21 is used to mediate communication effectively - it will be appreciated by the skilled person that other options are also available for mediating interaction between payment applications and kernels, so embodiments of the disclosure may be constructed without an explicit wireless EP 21.

A transaction flow which achieves the intended goals of user functionality and efficient operation follows the following general approach to performing an interaction over a wdreless communication network between a first device and a second device for processing by a discrete processing system according to a set of protocols - while this appl ies to payment over a wireless communication infrastructure, it is applicable to other interactions, particularly those providing permissions or capabilities to a user interacting indirectly with a computing system. Here, the interaction may be processed by a plurality of kernels on a first device and a plurality of applications on a second device - in the payment case, the first device may be a point-of-sale terminal, and the second device a user computing device with a payment capability.

In this approach, the first device establishes from the plurality of kernels a plurality' of possible applications for processing the interaction at the second device. The first device obtains from the kernels such information as is needed for all the plurality of possible applications to enable the second device to ran each possible application to perform the interaction.

The first device then provides a message to the second device identifying the plurality of possible applications and the information needed for all the plurality of possible applications;

A choice of application from the possible applications is made at the second device and interaction data is produced the chosen application at the second device. The choice of application and the interaction data is then provided by the second device to the first device for processing by said one of the kernels adapted to support that application.

The first device then obtains an interaction result for processing by the discrete processing system from said one of the plurality of kernels. In the case of a payment system, this may be an authorisation request for a transaction.

A specific implementation of this approach in the context of the system shown in Figures 1 and 2 is shown in Figure 3. Note that for the purposes of this transaction flow, the terminal 7 is considered to be a discrete entity to the wireless entry point 21 , as are the kernels 22. Similarly, the consumer device 11 is considered discretely from the payment applications 23 that it hosts - in practice, relevant activity at the consumer device 11 is at the w'allet application 25. Exemplary message formats are provided further below, as is an exemplary flow within a specific kernel 22.

A new' transaction is initiated at the terminal 7. The terminal 7 sends an initiate Jx message 3100 to the wireless EP 21, with the amount, the amount other and the transaction type. Note that the currency is fixed and knowm by the different wireless kernels. “Amount other” is used to indicate a cashback payment - if there is no cashback as part of the transaction, it will have a value of zero.

The EP will then do the same with each kernel. For example, the exchanges with kernel 1 may be as follows:

The EP sends 3110 the pre-process message with the amount, the amount other and the transaction type to kernel 1.

Kernel 1 responds 3120 with the pre-process response message with the kernel ID - in this case, 1 - and a list of product data. The list of product data contains, for all AIDs supported by the kernel and eligible for the transaction, kernel proprietary data. The kernel proprietary data corresponding to AID(x) will be used by the payment application 1 on the cardholder device, if the cardholder chooses to process the transaction with this AID(x) and this kernel 1.

The same is done for each kernel.

The wireless EP 21 then gathers the responses 3130 from all the kernels to prepare a transact message. The EP sends 3140 the transact message with the list of pre-process responses from the kernels 22 to the terminal 7.

The terminal 7 then sends 3210 the transact message with the list of pre-process responses from the kernels 22 to the w'aliet 25. The cardholder 1 then chooses 3220 the AID and the kernel ID that will be used for the transaction. This may be done directly through a user interface, may follow a pre-established default selection, or may take place according to a process that includes other factors relevant to the immediate transaction - this selection is not directly relevant to the present disclosure, and so is not discussed further here. In the example shown in Figure 3, this sel ecti on leads to the choice of payment application 1.

The w'allet 25 sends 3230 a prepare Jx data message to the chosen payment application (here, payment application 1). This message contains the product data corresponding to the selected AID and kernel ID.

The payment application 1 prepares 3240 transaction data for the transaction, and responds wdth a transaction data message to the wallet 25, this message containing the transaction outcome and kernel proprietary' data.

The wallet sends 3250 a transact response message to the terminal 7, this message containing the transaction outcome, the selected kernel ID, the selected AID and the kernel proprietary data prepared by the payment application 23. Assuming the transaction has not been declined, the terminal 7 then sends 3310 a prepare authorization data message to the EP 21 containing the amount, the transaction type, the selected kernel ID, the selected AID and the kernel proprietary data as prepared by the payment application 23. The EP 21 sends 3320 this prepare authorization data message to the selected kernel (kernel 1 in the diagram).

The kernel responds 3330 to the EP 21 with an authorization data message containing the outcome of processing at the kernel and kernel proprietary data. Exemplary kernel processing will be discussed further below. The EP 21 forwards 3340 the authorization data message to die terminal 7. Assuming the transaction has not been declined, the terminal then proceeds with authorization 3350 in a conventional manner.

The transaction flow indicated here is a minimal version, and it can be added to in other embodiments - for example, change of card by the consumer, change of transaction type, or modification of amount for a tip - but the skilled person will appreciate how these flows could be provided. For example, with further standardisation, other data (such as currency code, transaction type and so on) may become standardised across kernels and may also be sent as part of a standard message rather than only in proprietary data. In the embodiment described in detail here, the parameters exchanged between the entities may be specified in JSON format - this may be used between the wireless EP 21 and the terminal 7, and also between the terminal 7 and the consumer device 11 (wallet 25). Generally, if the terminal cannot process the transaction according to the flow, the transaction should be aborted, and no message sent to the wireless EP.

Exemplary descriptions of each message are provided at the end of this description. A description of the operation of an exemplary kernel now follows, with reference to Figures 4 and 5A to 5C.

Exemplary Kernel Operation

The kernel processes two messages received from the EP:

• pre-process

• prepare authorization data Processing of the pre-process message requires the building of a list of all AIDs eligible for the transaction, along with the associated data for each AID that will be used by the payment application if that AID is selected.

Processing of the prepare authorization data message requires:

• Verifying that certain requirements are fulfilled

• Deciding whether to decline the transaction or not

• If the transaction is not declined, building a transaction record that can be used to prepare an online authorization.

The pre-process message and its processing will be described in more detail with reference to Figure 4. The parameters of the message are set out further below in the section on messages associated with the terminal and the entry point (as message 8). Figure 4 provides a flow diagram for the processing of the message.

First of all, the following parameters are retrieved 410 from the message:

• Amount

• Amount Other

• Transaction Type

• Transaction Date

Of these, Transaction Date is stored 420 for later prepare authorization data message processing. The Unpredictable Number is then generated 430 - this may be according to any existing EMV technique - and also stored 440 for later prepare authorization data message processing. All the AIDs in the database are then inspected in an inspection loop - after determining 450 whether there is another AID in supported and whether that AID supports the relevant transaction type key 460 in the database, product data is built 470 using any positive AID/ transaction type combination. Product data is built according to the following plan:

The specifics of kernel proprietary data are not of relevance to the present disclosure and is not discussed further here. After the product data has been constructed, the pre-process response message is built 480 in the following format:

This is a list of all the product data for all the AIDs that are usable (it is possible that this will be empty if no AIDs are usable).

This pre ^process response message is then sent 490 to the entry point. The prepare authorization data message and its processing will be described in more detail with reference to Figures 5 A to 5C. The parameters are set out further below in the section on messages associated with the terminal and the entry point (as message 12). Figures 5A to 5C provide a flow diagram for the processing of the message. As shown in Figure 5 A, the following parameters are retrieved 510 from the message:

• amount

• amount other

• transaction type · AID

• Kernel proprietary data

It is determined if an AID is supported 520. If the AID received is not supported, then an authorization data message is built 530 to indicate this as follows:

This message is sent 540 to the entry point, ending the process. Flowever, if the AID is supported, the next step is to determine 550 whether the transaction type is supported. If not, again an appropriate authorization data message is built 560 to indicate this as follows:

The message to be sent to the entry point 570 takes the same format as before, but with a different outcome value as shown above.

The next check 580 is for whether any mandatory data is missing in data recovered from kernel proprietary data. If any of this data is missing, an authorization data message is built 590 as follows:

The message to be sent to the entry point 600 takes the same format as before, but with the outcome value as shown above.

The next step is to establish 610 that the card has actually requested authorization of the transaction, which it does with an ARQC cryptogram under EMV standards - this is one of a group of application cryptograms that can be produced by the card, and is the one specifically used for a transaction which a card has accepted and wishes to be authorized. If there is no ARQC cryptogram, an authorization data message is built 620 as follows:

The message to be sent to the entry point 630 takes the same format as before, but with the outcome value as shown above.

Following this, a risk management strategy for the transaction is established 640. It is then established 650 whether there has been cardholder verification appropriate to the transaction. If this fails, an authorisation message is built 660 as follows:

On failure, the message to be sent to the entry point 670 takes the same format as before, but with the outcome value as shown above. However, if this stage is passed, a positive authorization data message can then built 680 as follows:

This message is then sent to the entry point 690 and can be used as a basis for the subsequent authorization request.

Exemplary Messages and Parameters

Parameters for messages sent to and from the terminal and the wireless entry point will be described below.

1. Terminal - initiate tx message to wireless EP

2. Terminal - transact message from wireless EP

In processing, the transaction is aborted if the status is not “OK”, or if there is not at least one AID in the list. The transact message is then prepared and sent to the consumer device.

3. Terminal - transact message to consumer device

4. Terminal - transact response message from consumer device

In processing, the transaction is aborted if the transaction outcome is not AUTHORIZE ONLINE. After this process, the prepare authorization data message is sent to the wireless EP. 5. Terminal — prepare authorization data message to the wireless

EP

6 Terminal - authorization data message from the wireless EP

In processing, the transaction is aborted if the outcome is not “AUTHORIZE ONLINE”.

7. Wireless entry point - initiate Jx message from the terminal Message parameters are described in message 1 above. In processing, the format and values of the parameters are verified.

In case of error, the transact message is sent to the terminal with the following parameter:

If there is no error, the pre-process message is prepared and sent to each kernel.

8. Wireless entry point - pre-process message to the kernels

9. Wireless entry point - pre-process response from the kernels

When all kernels have responded, all the responses are gathered to build the transact message and send it to the terminal . The value of the Status in the transact message is “OK”.

10. Wireless entry point - transact message to the terminal

Message parameters are described in message 2 above.

11. Wireless entry point - prepare authorization data message from the terminal

Message parameters are described in message 5 above. In processing, the format and values of the parameters need to be verified, with a format error handled in the same way as for message 7. If there is no format error, it is necessary to verify that the kernel ID is supported - the following message is sent on failure.

If the kernel ID is supported, the prepare authorization _data message is prepared and sent to the selected kernel.

12. Wireless entry point - prepare authorization data message to the kernel.

13. Wireless entry point - authorization data from the kernel

In processing, the authorization data message is prepared with Status value “OK” and sent to the terminal.

14. Wireless entry' point - authorization data to the terminal

The message parameters are as for message 6. Data Dictionary

A brief dictionary of terms used above follows - predominantly, these terms are standard EMV terminology, and EMV specifications are a secondary reference.

AID - Specific application identifier. Amount - Authorized amount of the transaction.

Amount other - Secondary amount associated with the transaction representing a cash back amount.

Application Cryptogram - Cryptogram returned by the Card.

Contactless AID - Application identifier for application used for a contactless transaction.

Contactless application label - The application label that was used for a contactless transaction.

Currency - ISO 4217 code for the currency.

Currency Exponent - Number of fractional digits (base 10) in the currency provided by the terminal.

Kernel ID - Identifies the kernel.

Transaction Date - coding YYMMDD

Transaction type - “PURCHASE” or “PURCHASE CASHBACK”.

Unpredictable Number - Contains a Kernel challenge

(random) to be used by the Card consumer device to ensure the variability and uniqueness to the generation of a cryptogram. Four-party Model

Figure 6 is a block diagram of a typical four-party model or four-party payment transaction scheme. The diagram illustrates the entities present in the model and the interactions occurring between entities operating in a card scheme.

Normally, card schemes - payment networks linked to payment cards - are based on one of two models: a three-party model or a four-party model (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below.

The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 110, merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110 purchases goods or services from the merchant 120. The issuer 130 is the bank or any other financial institution that issued the card to the cardholder 110. The acquirer 140 provides services for card processing to the merchant 120.

The model also comprises a central switch 150 - interactions between the issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150 enables a merchant 120 associated with one particular bank acquirer 140 to accept payment transactions from a cardholder 110 associated with a different bank issuer 130.

A typical transaction between the entities in the four-party model can be divided into two main stages: authorisation and settlement. The cardholder 110 initiates a purchase of a good or service from the merchant 120 using their card. Details of the card and the transaction are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorise the transaction. Should the transaction be considered abnormal by the issuer 130, the cardholder 110 may be required to undergo an additional verification process to verify their identity and the details of the transaction. Once the additional verification process is complete the transaction is authorised.

On completion of the transaction between the cardholder 110 and the merchant 120, the transaction details are submitted by the merchant 120 to the acquirer 140 for settlement.

The transaction details are then routed to the relevant issuer 130 by the acquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140.

Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, a service fee is paid to the acquirer 140 by the merchant 120 for each transaction, and an interchange fee is paid to the issuer 130 by the acquirer 140 in return for the settlement of funds.

In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices such as a smart phone.

Many modifications may be made to the above examples without departing from the scope of the present disclosure as defined in the accompanying claims.

Claims

1. A method of performing an interaction over a wireless communication network between a first device and a second device for processing by a discrete processing system according to a set of protocols, wherein the interaction may be processed by a plurality of kernels on the first device and a plurality of applications on the second device, wherein: the first device establishes from the plurality of kernels a plurality of possible applications for processing the interaction at the second device, the first device obtaining from the kernels information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction; the first device providing a message to the second device identify ing the plurality of possible applications and the information needed for all the plurality of possible applications; the first device receiving from the second device a choice of application from the possible applications and interaction data from the chosen application at the second device for processing by said one of the kernels adapted to support that application; the first device obtaining an interaction result for processing by the discrete processing system from said one of the plurality of kernels.

2. The method of claim 1 , wherein the communications to and from the second device are mediated through a wireless entry point, wherein the kernels communicate only with the wireless entry point.

3. The method of claim 1 or claim 2, wherein the interaction is a transaction between a merchant represented by the first device and a consumer represented by the second device acting as a payment device, wherein the discrete processing system is a payment processing network, and the interaction result is a request to authorize the transaction.

4. The method of claim 3, wherein each of the plurality of kernels is adapted to provide merchant processing of a transaction performed with one or more payment applications, wherein a payment application is used for processing of a transaction on a payment device.

5. The method of claim 4, wherein establishing from the plurality of kernel s a plurality of possible applications comprises for at least one kernel determining and identifying allowable payment application and transaction type combinations, and also comprises providing from that kernel the said combinations together with transaction and merchant information needed by the payment application of each said combination for processing the transaction.

6. The method of claim 5, further comprising said at least one kernel generating an unpredictable number and providing the unpredictable number with said combinations and said information.

7. The method of any of claims 4 to 6, wherein the interaction data received from the second device comprises transaction data including an application cryptogram, wherein the interaction result includes a request to authorize the transaction including the application cryptogram.

8. The method of claim 7, wherein the interaction data further comprises a cardholder verification strategy and result, and wherein the kernel processing the interaction data determines whether the cardholder verification strategy and result allows a legitimate request for authorization of the transaction.

9. A computing device comprising a processor, a memory', and a wireless communication means, wherein the computing device is programmed to perform the method of any of claims 1 to 8.

10. The computing device of claim 9, wherein the computing device is a merchant point-of-sale terminal programmed to perform the method of any of claims 3 to 8.

11. A method of performing an interaction over a wireless communication network between a first device and a second device for processing by a discrete processing system according to a set of protocol s, wherein the interaction may be processed by a plurality of kernels on the first device and a plurality of applications on the second device, wherein: the second device receives a message from the first device identifying a plurality of possible applications for processing the interaction at the second device and the information needed for all the plurality of possible applications to enable the second device to run each possible application to perform the interaction; selecting one of the plurality of possible applications at the second device; at the second device, running said one of the plurality of possibl e applications using the information for that possible application from the message received from the first device to produce interaction data for the interaction; and sending to the first device a response message comprising a choice of application from the possible applications and interaction data from the chosen application for processing by said one of the kernels adapted to support that application.

12. The method of claim 11, wherein the interaction is a transaction between a merchant represented by the first device and a consumer represented by the second device acting as a payment device, wherein the discrete processing system is a payment processing network, and the response message is sent to enable the first device to request authorization of the transaction through the payment processing network.

13. The method of claim 12, wherein receiving the message from the first device comprises receiving a message identifying allowable payment application and transaction type combinations supported by the first device, together with for the said combinations transaction and merchant information needed by the payment application of each said combination for processing the transaction.

14. The method of claim 13, wherein the possible applications for processing the interaction are payment applications, and wherein selecting one of the plurality of possible applications comprises selecting a payment application for processing the transaction and providing the transaction and merchant information provided in the message to the payment application for processing of the transaction at the second device.

15. The method of claim 14, further comprising determining a cardholder verification strategy and, if required by the cardholder verification strategy, performing a cardholder verification action for inclusion in the processing of the transaction.

16. The method of claim 14 or claim 15, wherein processing of the transaction by the selected payment application comprises determining whether to complete the transaction and providing an application cryptogram to enable authorisation of the transaction through the payment processing system.

17. A computing device comprising a processor, a memory, and a wireless communication means, wherein the computing device is programmed to perform the method of any of claims 11 to 16.

18. The computing device of claim 17, wherein the computing device is a payment device programmed to perform the method of any of claims 12 to 16.

19. The computing device of claim 18, wherein the computing device is a handheld computing device.

20. The computing device of claim 19, wherein the computing device is a mobile telephone handset.

21. The computing device of any of claims 18 to 20, wherein the payment device comprises a wallet application for interaction with merchant devices and for management of payment cards associated with the cardholder, and a plurality of payment applications accessible to the wallet application.