EP3692488A1

EP3692488A1 - Method and system for carrying out a payment transaction on a bank terminal using an electronic device

Info

Publication number: EP3692488A1
Application number: EP18779687.5A
Authority: EP
Inventors: François Lemaire; Jean Lambert
Original assignee: Thales DIS France SA
Current assignee: Thales DIS France SAS
Priority date: 2017-10-03
Filing date: 2018-10-02
Publication date: 2020-08-12
Also published as: US11720868B2; US20200356968A1; WO2019068742A1; EP3467743A1

Abstract

The invention relates to a method for carrying out a payment transaction on a bank terminal (2, POS) using an electronic payment device (1), said device comprising at least two payment applications (1-4), said method comprising: - a step of data communication (STATUS) from the device to the terminal during a transaction, said data comprising at least information of a first type (ADF) identifying each payment application of the device; - a step of configuring the device so that said data comprise information of a first type (ADF) relative to at least one disabled payment application (1, 3). The invention likewise relates to the corresponding system.

Description

Method and system for performing a payment transaction on a banking terminal with an electronic device.

Field of the invention

The invention relates to a method and a system for performing a payment transaction on a banking terminal with an electronic device comprising a plurality of payment applications. More particularly, the method or system implements (or is configured to perform) communication of information relating to a plurality of payment applications. Preferably, the invention is compliant or compatible with banking standards, in particular the EMV standard. The invention more particularly relates to electronic devices equipped with electronic transaction software applications. Transactions include, but are not limited to, contactless or contactless electronic payment transactions. It targets Near Field Communication (N C) proximity transactions, for example through radiofrequency communications according to ISO 14443. It can target transactions involving (QR code) (two-dimensional bar code).

These devices include electronic communication devices (mobile phone, tablet, PDA personal assistant, electronic accessories to wear such as communicating watches or NFC). The payment device can also be any payment application support or any payment device, including the smart card. Some smart cards may include user interfaces (screen, keyboard, biometric sensor ...) and / or various communication interfaces

(NFC, ISO 7816, Bluetooth ...)

These devices are for some intended for electronic transactions, including financial, such as purchases that can be made online via the internet on merchant sites, but also locally at merchants using a POS payment terminal (Point of Sale Terminal in English terminology), automatic teller machines (ATMs) or ATMs (Automatic Teller Machines in English terminology), vending machines for goods such as fuel, beverages, etc., in company restaurants, shops, etc.

Prior art.

Currently, there is a method of performing a payment transaction on a bank terminal with an electronic payment device (mobile phone) comprising several payment applications. This method is in accordance with the EMV standard and is illustrated in Figures 1 and 2.

The method known above provides that the terminal issues a query query (SELECT) of a list of banking applications present and activated by a user on the device; It also provides that the payment device issues a response (STATUS) to this request. The response, in particular EMV compliant, includes information relating to at least one payment application if the latter has been activated.

US 2009/0112766 A1 discloses a method for selecting one or more payment applications from a point-of-sale terminal and that provides consumer benefits among a plurality of payment applications and using the one selected to perform a transaction. of payment. According to one embodiment, the selection can be automatic to select an optimized advantage. Technical problem.

The inventors have observed that the EMV payment method is poorly adapted, limited and impractical for making commercial offers based on the banking applications present in a payment device of a client user.

The current payment method constrains the possibilities or transaction features.

Objective of the invention.

The invention particularly aims to solve the aforementioned drawbacks or satisfy the need suggested above. In particular, the invention aims to allow merchants to influence a client user in the choice of a payment software application or an electronic electronic banking card, to perform the next proximity payment transaction among those present.

It is also an object of the invention to provide an improved user experience in making payment transactions while avoiding complex and costly changes in the existing payment infrastructure, preferably relying on an established EMV framework.

The invention also aims to allow the user to choose and / or execute a transaction more easily according to its own criteria, among one or the other present payment application. Summary of the invention.

In one aspect, the invention includes associating benefits (or any other incentive) with at least one of the present payment applications to induce one choice of payment application over another.

Advantageously, the choice of the user can be expanded despite limitations of voluntary use or not, fortuitous or not the user. The user's choice can be made among activated and / or non-activated payment software applications located in a payment device of the user. In other words, the invention makes it possible to propose different special offers depending on the choice of the payment application activated or not activated that the client user chooses for the transaction.

The invention also makes it possible to provide a set of various information relating to activated and unactivated payment applications in the payment device. The invention allows more flexibility and option widening in the selection of payment application while respecting operating constraints standards including EMV. For this purpose, the subject of the invention is a method for carrying out a payment transaction on a banking terminal with an electronic payment device, said device comprising at least two payment software applications, said method comprising: a step of communicating data from the device to the terminal during a transaction, said data comprising at least information of a first type identifying each payment application of the device;

The method is characterized in that it comprises a step of configuring the device so that said data comprises first type information (ADF) relating to at least one non-activated payment application.

According to other characteristics or preferred modes

the method implements a step of associating economic values of advantages (or other measure) for the use of one and / or the other payment application and a step of configuring the terminal to make a selection direct of the user (in particular the user's manual interaction during the transaction) or automatic in the terminal of a payment application based on these advantages (or an associated measure);

The data may preferably include information of a first type relating to at least one non-activated application; Thus, thanks to this very practical feature, all applications, even if not activated, are detected by a POS without intervention of the user.

And the selection of an application on the moment of the transaction is also more convenient for a user because he did not have to intervene beforehand to activate it and to know information associated with the application.

The invention also makes it possible to mitigate an omission of initial application activation by the user, or reactivation following a problem of momentary blocking of the application by the user or the authorization server. The invention provides flexibility in the operation of the system for detecting and selecting an existing application in a user's electronic payment device.

The method may comprise a step of storing said data in a directory of the device reserved for activated applications;

- The data may include information of a second type indicating whether an unactivated application is blocked at the authorization server;

The method may comprise a step of configuring the device so that said communicated data comprises information of a third type relating to categories of preferential advantages (PR, Pb, Pc). They can be preselected by a user in his device.

- The communicated data may be preferably placed in a discretionary data field of the FCI transmitters (Tag 'BFOC), in a field of the directory entries (Tag' 61 ') or in a field of stored proprietary application selection data. (ASRPD, Tag '9F0A').

The invention also relates to a system corresponding to the method above. In particular, it relates to a system for carrying out a payment transaction on a banking terminal with an electronic payment device, said device comprising at least two payment software applications, said system being configured for:

performing a data communication from the device to the terminal during a transaction, said data comprising at least information of a first type identifying each payment application of the device;

The system is characterized in that the device is configured such that said data comprises first type information (ADF) relating to at least one unactivated payment application.

According to other features, the system may comprise a bank server center and / or a merchant host center and in that it is configured so that, during a transaction, the device and / or the terminal interrogates (nt ) one of said hosts to have additional economic information or to interact with these servers.

The invention has the advantage that it can be fully compatible with the existing EMV infrastructure, that is, the payment device equipped with this solution will still operate in a normal EMV infrastructure.

The invention has the advantage of providing an opportunity for the merchant to regain control of the payment application used for the transaction. It does this by obtaining information about the payment applications available in the user's electronic wallet (activated or not, priority or not) and by proposing more commercially favorable payment alternatives. Thus, the merchant can, for example, avoid a payment application with high transaction costs and offer less expensive alternatives. The difference in fees may possibly be divided between the merchant and the user, in a manner decided by the merchant: direct price reduction, refund, loyalty points, coupons, coupons, etc.

The payment application in the payment device can be dynamically updated by the issuing bank of the user, with information such as the activation status, a whitelist of merchants, a blacklist of merchants, the membership in a loyalty program etc.

In addition, the user can set a more or less automatic transaction flow. It can also select / set its economic preferences for the merchant POS to take into account (or a POS-related remote merchant host).

Brief description of the figures.

- Figures 1 and 2 illustrate the method and current payment transaction system between a POS and a mobile phone with electronic payment application contactless, consistent with the prior art;

FIG. 3 illustrates a first preferred embodiment of the electronic payment transaction method of the invention (and corresponding system);

FIG. 4 illustrates a second mode of implementation of the electronic payment transaction method of the invention (and corresponding system);

FIG. 5 illustrates a third mode of implementation of the electronic payment transaction method of the invention (and corresponding system);

FIGS. 6 and 7 respectively illustrate an electronic block diagram of the payment device 1 and the payment terminal 2;

FIGS. 8 and 9 respectively illustrate steps (according to a preferred embodiment of the invention), a corresponding method or program for the payment device 1 and for the payment terminal 2. Description.

The same references from one figure to another, indicate identical or similar constituents.

FIG. 1 illustrates a common method and system, illustrating the prior art, for performing a payment transaction between a POS (1) and a mobile phone (2) with non-contact electronic payment applications (3). .

The POS payment terminal is in line with the market. It includes a secure structure and standardized / EMV (Europay Mastercard Visa) functions, which is the international standard for secure payment transactions. The POS can be provided in particular with a card reader contact or contactless, and human / machine interface (s) such as keyboard, screen and contactless communication means including NFC (Near Field Communication - proximity radio) with the telephone 2. It may preferably be equipped with a SAM electronic chip security module and encrypted electronic means for communicating with a central bank server (in particular for a periodic collection of transaction information and / or update), or a server of (or for) merchants.

The payment device (called electronic payment wallet), meanwhile, can constitute or include any payment device with payment banking applications, simulating / emulating bank cards

(eg smart watch, badge, electronic wallet bracelet ...). Device 1 is here in the form of a telephone. It may include a non-contact card emulation function according to the ISO 14443 and / or ISO / IEC 18092 standard so as to communicate with the POS by being perceived by it as a contactless smart card.

It also incorporates electronic circuits or chips integrated circuit. It integrates a human / machine interface here in the form of a touch screen. It integrates applications or application operating programs, stored in memory including EEPROM or flash for particular to perform banking, loyalty or other. These application programs are executed by a main processing unit μ02 or in one or more electronic circuits or electronic chips with associated integrated circuits such as an electronic security element "eSE".

According to the EMV standard, the method or system implements a "SELECT" request from the POS terminal 1 to the telephone (or payment device) and a "status" response from the payment device 2 to the POS; This response includes first information relating to at least one payment application only if the latter is activated. In fact, the EMV stream includes the command "SELECT PSE or PPSE" (this is the directory application) from the POS to the device then the device sends a reply with "STATUS" and then the POS sends the command "SELECT APP. To select an application. The "SELECT" command mentioned in the figures corresponds more precisely to the "SELECT PPSE" command. In the example fig. 1, illustrating the prior art, the telephone 1 comprises three banking payment transaction applications simulating electronic cards 1-3 of which only the card or payment application 2 is activated.

According to the invention, the term "activated" for a banking application means that the user has selected from banking applications present in his device an application that he wishes to use during a next transaction. From the technical point of view, in the sense of the EMV standard and corresponding software, an "activated" application status causes the storage of information / characteristics of an application in a PPSE register (Proximity Payment System Environment). Only applications that are activated (and not blocked by a bank issuer) are listed in this PPSE.

In the "STATUS" response to a "SELECT" request, it is the information of the activated applications comprising an "ADF" application identifier, contained in this register, which are transmitted to the POS by the device. When the device is a contactless card, the PPSE contains a list of all credit card applications supported by the contactless interface; Its contents are returned by the card in response to a SELECT command from the reader. If there are several applications in the list of candidates, either the terminal chooses the application that it prefers, or the selection is given to the bearer. After completion of this step, the terminal proceeds to select the application. During a first exchange, (including an ATR), the card (or the phone) returns a "status" with information concerning the bank card or payment application 2. The information here includes at least the "ADF Name". "(Application Definition File, Tag MF ') as defined in the EMV standards:" EMV Contactless Specifications for Payment Systems - Book B - Entry Point Specification). Other data such as the label of the application (Tag ^Λ 50 ', optional) or the Application Priority Indicator (Tag ^Λ 87', conditional) can be returned. The "ADF Name" allows the payment terminal to identify the payment means (payment software application) on the electronic device, as specified by the EMV standard.

Upon receipt of the STATUS information, subsequent EMV processing logic is executed by the POS. If the POS supports the payment application 2 (or bank card 2), then the payment application 2 is used by the POS for the next payment transaction. Otherwise, the payment transaction is canceled. The POS 2 here has no knowledge of the unactivated banking applications 1 and 3 present in the telephone 1.

In Figure 2, the system or method differs in that it comprises four applications or payment cards among which the bank application 3 high priority 1 and the banking application 1 low priority 2 are activated.

The "status" is transmitted to the POS in the same way as before but here indicating two activated applications 3 and 1 as well as their priority level

(1 and 2) . In this case, and according to the most conventional embodiment in the EMV standard, the EMV processing logic below is executed by the POS. If the POS supports the banking application 3 with higher priority 1, then the banking application 3 is used; If the POS does not support the banking application 3 but supports the banking application 1 with lower priority 2, then the banking application 1 is used; If the POS does not support either, then the transaction is canceled. There may be override modes in the EMV standard, where the payment terminal has been configured to force the use of the second priority application. It is specified here that the POS 2 ignores all of the non-activated banking applications 2 and 4 present in the telephone 1. (The PPSE does not contain their identifier (ADF) according to the EMV standard since they are not activated). Description of generalities relating to Figures 3-5.

FIGS. 3-5 illustrate different modes of implementation of the method of the invention for carrying out a payment transaction on a bank terminal (2, POS) with an electronic payment device (1).

According to one characteristic, the device 1 comprises at least two payment software applications (1-4). They can be both activated (example Ibis) or not activated, priority or non priority. One can be activated while the other is not activated (example 2bis). All applications can be un-activated (example 3bis).

According to another characteristic, the method comprises a step of communicating data from the device to the terminal during a transaction. This data comprises at least information of a first type (ADF2) identifying each payment application of the device 2.

In a first example Ibis (not illustrated by the figures), at least two payment applications are activated (preferably directly by the user or without excluding an activation otherwise, for example, by a server including via OTA) in the device. This activation can cause insertion of at least their ADFx ID, ADFy in a PPSE register of the device. This makes it possible to make the applications activated by the POS 2 banking terminal during a transaction visible in a known manner (as in FIG. 2 for the banking applications 1 and 3).

According to another characteristic, the method may also comprise a step of associating economic values of advantage (s) (or incentives) with the use of one or the other payment application. In the examples, these economic benefits or benefit values (incentives) may be allocated by an electronic credit card issuer (or payment software application) such as any bank. These advantages can be introduced into the mobile of the user being associated with the electronic payment application (or card).

The benefits may be the result of a commercial agreement between a sign / merchant and an issuing bank of the application or an electronic credit card or the issuer of an electronic wallet hosting multiple applications or payment cards.

For example, first benefits (VI-V4) may be introduced by means of an update or OTA (Over the Air) communication with the mobile from an OTA host of a sending bank or entity acting on behalf of the issuing bank. These advantages can be added directly to each payment application, in particular in the PPSE register, and taken into account during a transaction, during a development of communication fields with the POS. Fields and data formats are preferably as provided by the EMV standard. The data downloaded by OTA can be placed in all the fields of the PPSE register targeted by the invention. Where appropriate, second benefits (Vt) can be introduced (alternatively or cumulatively to the first benefits Vt) in the bank terminal 2. The introduction can be performed by the managing entities of the payment terminal park and be associated with applications. bank payments or means of payment (Visa Electron, Visa Blue Card, Visa Premier ...) or payment system. These second benefits (Vt) can be downloaded or updated in the terminal 2 by any means of communication, including OTA communication or during a connection with a server center via any computer network or radio telecommunication. These second benefits (Vt) can favor banks issuing payment applications.

Alternatively, where appropriate, the invention may provide an additional program DEX1 in the device, configured with instructions for developing "STATUS" responses with data fields (preferably those targeted by the invention) including VI-benefits. V4 associated with each application when they exist. This can be done with applications enabled or not. According to a feature of a preferred embodiment of the invention, the method may comprise a terminal configuration step for making a selection in the terminal of a payment application based on these advantages. The selection can be carried out manually by a user or automatically. Concretely, the terminal 2 is configured with a POSnEx program explained below to perform the above function. The POSnEx program may include instructions configured to extract fields from the received communications:

data comprising information of a first type containing identifiers ADF1, ADF3 of software applications (or electronic payment cards or means of payment),

and the first VI-V4 advantages associated with each identifier ADF1, ADF3.

Alternatively, POSnEx can extract only information of the first type ADF1, ADF3 .... Then POSnEx can associate, if necessary, second advantages (Vt not shown) already contained in the terminal (previously loaded) or loaded during a connection and interaction with a server center (30, 31) referred to at the end of the description). Thus, the invention provides that these advantages VI-V4, Vt can be introduced respectively into the device 1 and / or the terminal 2. POSnEx can thus associate first (V1-V4) and / or second advantages (Vt) respectively from of the device 1 and / or received in the terminal 2 before or during the transaction.

The program "POSnEx" may also include instructions for proposing in the terminal 2 (FIG 3, step 130) a manual selection of a payment application based on these first (VI-V4) and / or second benefits (Vt ). For this purpose, the POS can display for each application the resulting advantage and include a human / machine interaction interface

(button, touch screen ...) allowing a selection of the payment application by the user.

Advantageously (see FIG. 5), the POSnEx program may be supplemented by other instructions to become a "POSauto" program so as to automatically select the application or electronic payment card. Given the same category of benefits (called information of the third type), associated with two applications AF1, AF2 ..., "POSauto" can operate by retaining the most important benefit of office to select the payment software application (or payment method) the most interesting for the user and / or the merchant. For example, for both, it may be an immediate discount "Tr", or for both a delayed discount "Te", or for both of the "Tb" loyalty points.

Alternatively, the user can choose a preferred benefit category (information of the third type) with respect to others. For example, he may prefer in the order an immediate discount "Tr" or a delayed delivery "Te", or loyalty points "Tb". This third type of information may also be included in the data communicated by the device 1 to the terminal 2. It may in particular be placed in one of the fields defined / enabled by EMV, at a predetermined location (or fields described later) of the message, known by the program "POSauto" for its extraction then interpretation and execution. This third type of information can also alternatively be pre-loaded and activated in the terminal 2 to be proposed to the user via the terminal or be automatically applied by default. (However, preferably, it is the user who chooses this on his device without the need for a pre-loading in the terminal).

The invention here differs from the prior art defined by EMV which can provide automatic selection and automatic processing in the POS terminal of a payment software application (or means of payment) priority over another non-priority application all two activated. This prior art is not related to benefits associated with each payment software application. As a result, the user can not privilege the application providing the best advantage over the moment of the transaction.

Specific description of Figure 3.

FIG. 3 illustrates an example 2bis of a preferred embodiment of the electronic payment transaction method (or system configuration) of the invention, in which at least one application among at least two applications, is not activated; The POS 2 and the telephone 1 may be in accordance with the modes described above (FIGS. 1 and 2), with the following differences. According to a very advantageous characteristic of the preferred mode, the data communicated to the terminal 2 during the transaction comprise information (ADF1 or ADF3) of a first type relating to (or identifier) at least one non-activated payment application.

This characteristic differs from the prior art, defined in particular by EMV, which does not provide for making non-activated applications of the device 1 visible by the terminal 2. Indeed, according to the EMV standard (PPSE and Application Management for Secure Element - Specification Version 1.0 May 2017), only activated applications appearing in the PPSE register have their identifier entered in the "STATUS" response of the device to the terminal.

Thus, according to a characteristic of this preferred mode, the method may comprise a step of configuring the device 1 so that it stores information of a first type (ADF3) of an unactivated application in a directory ( PPSE) reserved for activated applications. Unactivated applications can be forced, thanks to this configuration, to be mentioned with their identifier (and if necessary associated advantages) in this reserved directory.

Where appropriate, the invention may provide for writing, in particular by OTA in the PPSE, of application data that is not activated. Similarly, the invention may provide to load a code or instructions, including OTA, or internet, WIFI, to write in the PPSE data relating to non-activated applications.

Alternatively, non-activated ADF3 applications can be listed in a directory, including PPSE or other, with the applications enabled; They may have an "unactivated" indication in a dedicated field instead of the "enabled" value. They may include a blocking indication of the application and a reason or reason for blocking. This allows the invention not to encourage use of an application that would have been un-activated, for reasons of serious blockage including a issuing bank that would have led to rejection or refusal of the transaction.

According to a characteristic of a preferred mode of implementation or of realization, the method comprises a step of configuration of the terminal 2 for a selection manual or automatic payment application based on these benefits in the terminal. The selection can be direct by interaction, particularly manual, of the user with the POS. In the case of the Ibis example (two applications enabled), the device 1 may not be modified / configured with respect to the prior art (associated advantages may be pre-loaded in the banking terminal). Or at the limit, in the case where a first activated application is prioritized over the second by a user, the invention can provide for the abstraction of the priority and treat the non-priority applications in the same way as those priority.

In the case of examples 2bis and 3bis (relating respectively to an activated application and a non-activated or two non-activated applications), the invention can perform a treatment identical to the non-priority application. More precisely, although being a less preferred concept, the invention can provide for placing, (notably thanks to the DEX1 program which can be linked to the function 5 FIGS. 3-5), at least the ADF identifier of each non-application. activated or (non-priority) in one of the fields of communication hereinafter referred to by the invention. Thus, although less preferred, the invention can provide a computer program DEX1 in the device 1 whose function is to systematically place, in a secondary field of the priority application and / or activated (especially in the PPSE register), the ADF1 to ADF4 of at least one second payment application, (even if the latter is not a priority or not activated).

Similarly, according to this less preferred concept, if the device contains more than two, or three or four payment applications, all non-priority secondary applications can have their "ADF name" placed in one of the secondary fields of the priority application. or an activated application, especially in the PPSE register.

Among these secondary fields (covered by the invention) that can be filled and communicated to the terminal, may include a field of discretionary data FCI transmitters (Tag ^ FOC), or a field entries directory (Tag '61') or a proprietary registered application selection data field (ASRPD, Tag '9F0A'). ASRPD means in English "Registered Proprietary Data Selection Application"; This field is a subfield of Directory Entry (Tag ^Λ 61 ').

Thus, when the device develops its "status" response conforming to the EMV standard, the latter response contains not only the ADF of the priority application (activated) but also the ADF identifier of at least one other non-priority application or non-activated, or even the ADF of all non-priority or non-activated applications contained in the fields referred to above. The fields covered can thus (according to this less preferred variant) not only contain data of economic benefits or incentives, but also payment application identifiers.

Alternatively, the DEXl program can be configured to communicate on or off the EMV standard, directly information relating to several non-activated applications. Information of a third type (benefit categories) can also be loaded into the device and / or the terminal in the same way as the benefits of the first type. The DEXl program may include or implement a menu offering either category of benefits to the user's choice. The category chosen by the user can be placed by the DEX1 program in one of the communication fields targeted by the invention.

The device 1 (telephone) can meanwhile be configured electronically and / or with the program DEX1 / instructions and / or data to generate a response "STATUS" comprising at least information of a first type relating to at least two activated or non-activated or non-priority payment applications. The DEXl program may be configured to associate economic benefit values associated with each payment software application and pre loaded into a device memory.

The invention may provide a mechanism or program (which may be included in DEX1) configured by default to force the device to be contained in the PPSE or contain in the STATUS response, in addition to those relating to the activated applications, information concerning at least a second application (activated, not activated or not priority).

Preferably, the telephone 1 may be configured to (or understand) an easily selectable function or option to make visible or not visible. all banking applications with visual indicator (I want to make all my banking applications (or means of payment) visible or not). Thus, a user can easily place in the PPSE, with his consent, the information of all applications present so as to make them visible.

Alternatively, this function or option 5 can be implemented remotely by an actuation instruction or instruction prompting the actuation by the user, communicated in particular by OTA.

According to this function 5, deactivated applications (marked with a cross) are also filled in or listed or added in addition to the applications activated in the "STATUS" response from the phone to the POS. This function 5 can be associated with the DEX1 program of the device to activate it directly.

The POS, for its part, has a "POSnEx" execution program; This program is configured to read or extract the data / information (second information ADF2, ADF3 in addition to first ADF1 information) received via "STATUS" and maintained temporarily, including RAM1. The data / information is placed in the aforementioned fields to implement the invention (to know other present applications and to propose to use them in particular by proposing an economic advantage). In the example, FIG. 3, the telephone 1 comprises three payment applications (1-3) whose application 2 only is activated (as in FIG. 1). However, the payment device 1 transmits in its response "STATUS" ADF3 information relating to at least one other non-activated application. Here, second information ADF1, ADF3 relating to the two non-activated banking applications 1 and 3, are also transmitted to the POS in its response "STATUS" in response to its request "SELECT". Only the banking application 2 with first information ADF2 is activated.

The information here includes for the banking application 3:

- ADF: ADF3 or App. Banking 3;

- The label of the application (optional);

- ASRPD data: (disabled, VI: 2% discount, max 2 €).

The "STATUS" information here includes for the banking application 2: - ADF: ADF2 or App. Banking 2;

- The label of the application (optional);

- ASRPD data: (Enabled).

The information here includes for banking application 1:

- The ADF: ADF1 or App. Banking 1;

- The label of the application (optional);

- ASRPD data: (disabled, V2: 4% discount @ Super Merchant).

Then, the reader 2 POS processes this received information with the aid of its microcontroller μ02 which executes a processing software or program "POSnEx" (step 130 fig.3 or fig.8), (POSnEx can be stored in a non memory volatile EEPROM of the POS or associated with the POS, for example using a personalization or updating smart card, which can be read by the POS, in particular during or before its operation). The "POSnEx" program is executed by integrating or using the data received in the "STATUS" and in particular those contained in the ASRP field (relating to a calculation rule of economic advantage). The execution of the instructions of the program POSnEx with the received data, leads to a presentation of benefits to the user calculated by the POS according to the payment application that will be used.

Thus, thanks to the specific program of the invention "POSnEx", the POS 2 can preferably inform the user (in particular by displaying on his screen or other, voice message ...), the economic benefits which he can benefit according to the method of payment (or banking application) chosen for the transaction

(step 130 fig.3 or fig.8) (in order of best direct and indirect offer):

- For the Banking 1 application, for which the "Super Marchand" merchant, offers a V2 credit advantage of 4% "cash back" of € 3, for a sub total and total of € 75;

- For the Banking 3 application, the merchant offers an immediate discount VI benefit of a value of 2% (limited to € 1.5 per rule) associated with the banking application 3 in the ASRP field, for a sub total of € 75 and total discount (- € 1.5) of € 73.5;

- For the Banking 2 application, the merchant offers nothing and the subtotal and total is 75 €. In a next step, the user observes what will be the economic benefits resulting from the use of each of the three means of payment present in his phone. Then, he selects (20) the banking application that offers him the best benefits, namely the means of payment 3 on the POS using a touch screen or keys on the keyboard of the POS. It is the banking application 3 that makes it the largest immediate discount 1.5 € (the first application 1 offers more but deferred). The user is free to make another choice that better meets his expectations. This selection by the user, causes the implementation of subsequent steps to POSnEx including a selection and activation in the POS 2, a banking application reading "POS3" (corresponding to the payment application 3). The articulation between the programs POSnEx and POS3 can be done in different ways known to those skilled in the art. For example, upon receipt of "status", POSnEx operates in priority over the EMV POSn POS applications, putting the execution of POSn applications on hold until a display and a user selection of one of the between them. A selection of the user loops back the POnEx program on one of the POSn reading applications chosen. In fact, the POS passes, preferably here, in the directional interrogation mode forced by the user.

In EMV mode, the POS reading application is implemented by reading the ADF identifier of the activated application read by the POS. All this can be done in an EMV-based POS, except that the automatic choice or not is made on a priority criterion that is in the "PPSE". For example, if there are two applications, one priority 1 and the other priority 2, the terminal chooses the first, unless it has been configured to choose the second one. If there are two applications with the same priority 1, the carrier chooses on the POS screen, unless it has been configured to choose the application of interest.

In the next step, after selecting POSn the user presents his phone again to the POS (if necessary on possible instructions displayed on the POS). The presentation triggers the realization of the contactless transaction by the POS by implementing the banking application 3 selected from the POS reader (corresponding to the banking application card 3 of the phone). Although the credit card 3 application in the phone is marked as non-activated in the ASRPD field, the transaction is still done.

Alternatively, several credit card applications can be activated by the user (or by default through a POSnEx step) and visible to the POS via the "STATUS" information sent from the telephone in response to the EMV request from the POS. It is then optional to have a configuration of the telephone necessary to implement a selection of function 5 (I want to make all payment applications visible).

Information about the deactivated application is more informative for the POS. It does not use it in the prior art. This information does not make the application inactive so far at the telephone, especially for forced directive use. The configuration (or option) selection 5 (I want to make all payment applications visible) forces the phone to transmit the same information about non-activated applications. This selection triggers a memorization of the information of all payment applications present in the PPSE as if they were activated. If necessary, the invention can provide for storing this information of all non-activated applications as soon as they are not blocked.

Specific description of FIG. 4. In FIG. 4, according to a second embodiment or embodiment, the telephone 1 comprises three payment card applications "Debit", "Credit", "4" whose card application Only "Flow" is enabled. However, the payment device 1 transmits, in its response "STATUS", information relating to at least one other non-activated electronic payment card application. Here, information relating to the two non-activated credit card applications "Debit" and "4" and that activated "Credit" are transmitted to the POS in its response "STATUS" in response to its request "SELECT": The information includes here for the application of "Credit":

- The ADF: "App. Credit "or" ADF (Credit) ";

- The label of the application (optional);

- The following ASRPD data: (Enabled) The information here includes for the application of "Flow":

- The ADF: "App. Flow "or" ADF (Credit) ";

- The label of the application (optional)

- The following ASRPD data: (disabled, V3: 4% discount @ "Super Merchant")

The ASRPD includes in part of the available field in addition to the indication of a deactivation, a benefit calculation rule V3 relating to transactions made at a particular merchant (here at the merchant "Super Merchant"). The information here includes for banking application 4:

- ADF: ADF4 or "App. Banking 4 ";

- The label of the banking application 4 (optional)

- The following ASRPD data: (disabled, V4: Bonus, 100 points)

Thus, thanks to "POSnEx", the POS can display on its screen, the expected result (step 130 fig.4 or fig.8) of the transaction depending on the application used (in order of best offer):

- For the "Debit" application, a subtotal of € 225 and a total of € 216 (discounted € 9);

- For the "Banking 4" application, the merchant offers a sub total and a total of € 225 with a bonus of 100 points;

- For the application of "Credit", the merchant offers nothing and the subtotal and total is 225 €.

In a next step, the user observes on the POS screen what will be the expected result of the transaction for the three payment applications present in his phone. Then, for example, it selects (21) the application of "Flow" on the POS using a touch screen (or keys on the keyboard) of the POS. It is the application of "Flow" which makes it the most important immediate discount (9 €).

This selection by the user causes (step 140 fig.3 or fig.8) through "POSnEx" a selection by the POS of a "debit" card reader application (Dl) corresponding to the card application. "Speed" of the phone. In the next step, the user presents his phone again to the POS (if necessary on possible instructions displayed on the POS). The presentation of the phone near the POS triggers the realization of the transaction without contact by the POS by implementing the application of credit card reader of "Debit""Flow1" of the POS corresponding to the application card of "Debit From the phone.

The POSnEx program can realize the bank transaction by applying the displayed economic advantage linked to the debit bank card.

Alternatively, once the choice is made, it can be the classic POS program that carries out the transaction. Depending on the case, this may be a total amount that is altered by a direct delivery rule applied / executed by POSnEx and communicated to POSn for processing; This can be loyalty points, or a cash back applied / executed by POSnEx in parallel with the execution of the selected credit card reader application.

It should be noted that while the corresponding "Debit" banking application in the phone is also marked as disabled in the ASRPD field, the transaction is still proceeding in a directive manner.

Specific description of Figure 5.

In Figure 5 is described an example substantially identical to that of Figure 3. It differs in particular that the phone comprises or is configured with a selectable function 6 automatic selection of the best offer of the merchant (here direct discount) for the transaction.

The example here differs in that the information included in "STATUS" includes an additional indication or instruction for automatic calculation of the best offer and automatic selection of the best offer or application (step 210 fig.5 or fig. .8). The example also differs in that it is the banking application 1 which is used instead of the banking application 3 because of a user parameter introduced in the telephone to allow the automatic selection by the payment terminal of the best direct or indirect offer. The POS is therefore configured accordingly with a "POSnEx" program and in addition to "POSnAuto" instructions to automatically calculate the best offer from the merchant depending on possible parameters (or categories of benefits) preferential (Pr, Pf, Pb ) that the user can indicate or activate in the phone.

The program "POSnAuto" can be triggered by a reading of a flag selected by the user. If an indicator detected by a test, the program plugs into a "POSn" application directly with immediate or delayed delivery values. As a result, the step of posting expected results on the SOP is not implemented. The above parameters may include a selectable preference, for example, for the best immediate discount "Pr" or the best bonus "Pb" for loyalty points or for a better amount of repayment "Pc" or indirect discount (cash back ), etc.

The program POS1 (corresponding to the banking application 1 or ADF1) is executed by integrating or using the data received in "STATUS" and in particular those contained in the field of the ASRP and the data "Pc" indicating that the best offer is equal to the best indirect discount. The execution of the instructions of the program POS1 with the new data received, therefore leads to automatically determine the best banking application for the user (step 120 fig.5 or fig.8). In a next step, (step 140 fig.5 or fig.8) the POS calculates with the programs "POSnEx" and "POSnAuto" what will be the best result of the transaction for the three payment applications present in the phone. Then, it automatically selects (22) the POS1 bank card reader application on the POS corresponding to the credit card application 1. It is indeed the credit card application 1 that offers the largest indirect cash back corresponding to the selection criterion "Pc" preselected by the user.

The POS displays on its screen a presentation of the result and the payment application used:

- "Thank you for your transaction at" Super Marchand ";

- You used the banking application 1,

- Total paid 75 €. - Gain of 3 € "cash back" on your loyalty account »

Advantageously, in this example, thanks to the automatic selection function of the banking application by the POS, the user may only have to present his phone once. If necessary, the user may have to present his device again to the POS (in particular on possible instructions displayed on the POS).

The presentation of the device to the POS triggers the realization of the transaction without contact by the POS by implementing the POSl credit card reader application selected from the POS (corresponding to the application credit card 1 of the phone).

It is observed that, thanks to the invention, although the corresponding banking application 1 in the telephone is marked as deactivated in the ASRPD field, the transaction is still carried out, the selection functions 5 and 6 being activated.

The automatic selection can be carried out also in the absence of option 5 activated in the case in particular where several banking applications are activated and therefore communicated to the POS for processing in the information "STATUS". Preferably, the invention provides that if option 5 is not activated, it is the EMV priority rule that applies. According to another mode of implementation, the invention may provide for a selection by the user of the type "Among my applications (or means of payment) enabled, I wish to select on the POS terminal the application that offers me the more benefits. As a result, the information on the only activated payment applications is transmitted to the POS.

Alternatively, if the automatic option "POSauto" is selected, the most interesting transaction (according to pre-selected criteria of the user) can be done directly. The user can then be informed of the activated application that has been used and the benefits obtained.

If necessary, the system 10 can also integrate (not shown) a bank server center and / or a server center of (or for) merchants (31) or any other on-line server accounting or performing transactions related to transactions. During a transaction, the telephone 1 and / or the POS 2 can interrogate (or interact with) one of the hosts (above) to have additional information including economic, (offer merchant flash 32, banking offer 33 ..., online bonus user account 34, online user loyalty point account 35, online user credit account or cash back account 36. The interaction may involve updating any account (user, merchant or another transfer to an association account has any theme including against a disease, ecological, social, philanthropic, charity ...) remote online following a transaction.

Thus, the invention makes it possible to widen the possibilities of transactions, advantages or economic impacts, related to the use of one or the other payment application in a very practical way for the user.

The mobile can connect to a remote server that will give him preferential offers (which will be indicated in a second information). Similarly, the POS can connect to a remote system on which it will increment for example a points account following the transaction or inform the user of its eligibility for any offer when its points reach a threshold.

In the implementation, the invention may provide for connections and updates of user accounts 34-36 and / or updating offers 33 or merchants 32.

Specific descriptions of Figures 6-9.

FIGS. 6 and 7 respectively illustrate an electronic block diagram of the payment device 1 and the payment terminal 2. The constituents mainly comprise a microcontroller μσΐ and μο2 connected to working memories RAM and program memory, and communications means including NFC. They may comprise other constituents or electronic means as indicated in the figures. In FIG. 8, the steps illustrate a preferred mode of implementation of the invention or a program, for the payment device 1. The steps 200 to 240 (request reception, elaboration of the response, transmission of the response with specific information in the dedicated fields (Tag ^ FOC or Tag '61' or Tag '9F0A') are also illustrated for the most part in Figures 3 to 5.

In FIG. 9, the steps illustrate a preferred mode of implementation of the invention or a program corresponding to executing by μο2, for the payment terminal 2. Steps 100 to 140 (transmission request, reception of the response, extraction of Specific data / information of the fields dedicated above, execution of the program "POSnEx" with said specific information are also illustrated for the most part in Figures 3 to 5.

According to one characteristic, the invention can provide that the data communicated to the terminal by the device may comprise information of a second type indicating why an application is not activated (bearer choice, or blocking of the means of payment by the transmitter etc. .)

This second type information is useful (and preferable), but not strictly necessary. It is not mandatory because, if an application is not activated because it is blocked (in the EMV blocking sense, and not blocked at the authorization server), the "SELECT APP" function ( just after the "SELECT PPSE") will return an error, and the terminal will go to the next application in its priority list (EMV behavior). In this case, the POS can still consider it without compromising the payment.

However, if an application is indicated as not activated because it is blocked by the issuer of the payment method (the bank), it is preferable that the application on the terminal does not propose it (POSnEx) / does not select it (POSnAuto ) at the risk of wasting time, especially when sending the error message. Regardless of the commercial offers that may be associated with each particular banking application, the method of the invention makes it possible not to restrain the features available or at least present in the payment devices (see other device not necessarily payment but electronic transaction in general).

The invention allows more flexibility for a user who does not necessarily know what features or applications are present in his device or usable at a given moment in connection with a terminal given. An application could be activated, downloaded remotely in the meantime without the user having really realized his presence or his possibilities.

A user may have reasons other than economic to choose such or such application, such as the level of security associated with the terminals or the actual transaction (eg level of repudiation), the speed of the transaction, the confidentiality of transactions, the certification of certain applications compared to others.

The invention can be applied to electronic transaction devices in general other than those intended to make payments. The invention can be applied to make various transactions other than in connection with a banking terminal (for example with any transaction terminal, transport, access ...)

Claims

A method for performing a payment transaction on a bank terminal (2, POS) with an electronic payment device (1), said device comprising at least two payment applications (1-4), said method comprising:

a step of data communication (STATUS) from the device to the terminal during a transaction, said data comprising at least information of a first type (ADF1, ADF2) identifying each payment application of the device,

characterized in that it comprises a step of configuring the device such that said data comprises first type information (ADF) relating to at least one non-activated payment application (1, 3).

2. Method according to the preceding claim, characterized in that it comprises

a step of association of economic values (VI-V4) with advantages for the use of one and / or the other payment application,

- A terminal configuration step for making a manual selection (POsnEx) or automatic (POSauto) in the terminal (2) of a payment application based on these benefits.

3. Method according to the preceding claim, characterized in that it comprises a step of storing said data in a directory (PPSE) reserved for activated applications.

4. Method according to one of claims 2 or 3, characterized in that said data comprises information of a second type indicating whether an unactivated application is blocked at the authorization server.

5. Method according to one of the preceding claims, characterized in that it comprises a step of configuring the device so that said data communicated (STATUS) comprises information of a third type, said third type being relative to categories. preferential advantages (Pr, Pb, Pc) preselected by a user in his device.

6. Method according to one of the preceding claims, characterized in that the step of association of economic values (VI-V4) benefits for the use of one and / or the other payment application, is done in the device (1) such that said communicated data (STATUS) comprises said economic values of advantages.

7. Method according to one of the preceding claims, characterized in that said data communication is performed in a response (STATUS) of the device (1) to a query (SELECT) of the terminal according to a standard such as EMC.

8. Method according to one of the preceding claims, characterized in that said communicated data are placed in a discretionary data field FCI transmitters (Tag 'BFOC), in a field entries directory (Tag ¹ 61 ¹ ) or in a proprietary registered application selection data field (ASRPD, Tag '9F0A').

9. System for performing a payment transaction on a bank terminal (2, POS) with an electronic payment device (1), said device comprising at least two payment applications (1-4), said system being configured for:

performing a data communication (STATUS) from the device (1) to the terminal (2) during a transaction, said data comprising at least information of a first type (ADF1, ADF2) identifying each payment application the device,

characterized in that the device is configured such that said data comprises first type information (ADF) relating to at least one unactivated payment application (1, 3).

10. System according to the preceding claim, characterized in that said information of the first type (ADF1) is placed in a field of discretionary data FCI transmitters (Tag ^ FOC) or in a field entries directory (Tag '61') or in a proprietary registered application selection data field (ASRPD, Tag '9F0A').

11. System (10) according to one of claims 9 or 10, characterized in that it comprises a bank server center (30) and / or a merchant host center (31) and in that it is configured in a transaction, the device (1) and / or the terminal (2) interrogate (s) one of said hosts to obtain additional economic information (32-36) or interact with these servers (30). , 31).