Method for initializing a merchant's electronic payment terminal.

Abstract

The present invention relates to a method for initializing an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant, the method being characterized in that it comprises the implementation of steps of: Reception by a server (3) comprising data storage means (32) storing said merchant identification information uniquely associated with a mobile terminal (1) of the merchant, and connected via a communication network (20) to said electronic payment terminal (2) and to the mobile terminal (1), of a request for initialization of the electronic payment terminal (2); Transmission to the mobile terminal (1) of the data necessary for the initialization of said electronic payment terminal (2);Transmission of a message containing said data necessary for the initialization of said electronic payment terminal (2), from the mobile terminal (1) to the electronic payment terminal (2), via a proximity communication channel Implementation of the initialization of said electronic payment terminal (2) using the received data. [Fig. 1];

Description

Title of the invention: Method for initializing a merchant's electronic payment terminal. [0001 ] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of electronic payment terminals. More specifically, it relates to a method for initializing an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant.

[0003] STATE OF THE ART

[0004] Traditionally, merchants with an electronic payment terminal (EPT) need a bank domiciliation card, known as a DOM card.

[0005] This is a physical card in payment card format (not to be confused with the latter), storing in particular in a magnetic strip (ISO2) identification information of the merchant, such as a merchant contract identifier of the merchant.

[0006] The DOM card is issued by a banking establishment and allows the TPE to be linked to the merchant's professional bank account.

[0007] This card is now essential for operating an EFT: - it allows you to configure the EFT so that payments are paid into the linked account - it must be present to validate transaction cancellation or credit operations.

[0008] It is noted that the information stored by the card (merchant contract identifier) ​​is not secret, but the requirement for the presence of the card effectively guarantees the merchant's consent to implement these particular operations.

[0009] This solution is satisfactory, but still proves restrictive.

[0010] Indeed, if the merchant has several merchant contracts (generally corresponding to several types of bank cards, interface or service (contact, contactless, distance selling VAD, etc.)), he must have as many DOM cards and use the right one each time.

[0011] And these cards are likely to be lost (especially if there are several), which can block the merchant's activity. In addition, there is always the risk that they will be used without the merchant's consent to implement a fraudulent operation, for example by an employee having access to these cards.

[0012] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0013] The present invention therefore relates, according to a first aspect, to a method for initializing an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant, the method being characterized in that it comprises the implementation of steps of: a. Reception by a server comprising data storage means storing said merchant identification information uniquely associated with a mobile terminal of the merchant, and connected via a communication network to said electronic payment terminal and to the mobile terminal, of a request to initialize the electronic payment terminal; b. Transmission to the mobile terminal of the data necessary for the initialization of said electronic payment terminal; c. Transmission of a message containing the said data necessary for the initialization of the said electronic payment terminal, from the mobile terminal to the electronic payment terminal, via a proximity communication channel d. Implementation of the initialization of said electronic payment terminal using the data received.

[0014] According to advantageous and non-limiting characteristics:

[0015] Said data necessary for the initialization of said electronic payment terminal includes said identification information of said merchant.

[0016] The request to initialize the electronic payment terminal is received from the mobile terminal, the identification information of said merchant transmitted in step (b) is that associated with said mobile terminal from which the request to initialize the electronic payment terminal is received.

[0017] Said identification information of said merchant relates to several merchant contracts of the merchant.

[0018] Said data transmitted in step (b) comprises the merchant's identification information relating to all of said merchant contracts of the merchant.

[0019] Step (c) comprises the prior selection by the merchant on the mobile terminal of at least one contract in accordance with which he wishes to initialize the electronic payment terminal.

[0020] Said data transmitted in step (d) only comprises the merchant identification information relating to the merchant contracts of the selected merchant.

[0021] The method comprises a prior step (aO) of reception by the server of a request for dematerialization of the bank domiciliation card, comprising said merchant identification information and an identifier of the mobile terminal to be associated on the data storage means of the server with said merchant identification information.

[0022] Step (aO) comprises transmitting to the mobile terminal a request to verify said identifier of the mobile terminal.

[0023] Said request to verify said identifier of the mobile terminal results in the opening of a dedicated application if it is already installed, and otherwise its downloading from the network and then its installation.

[0024] Said application is configured to respond in step (aO) to said request for verification of said identifier of the mobile terminal, and to extract in step (c) from the message transmitted via the proximity communication channel said authentication token and retransmit it to the server.

[0025] The method comprises a step (al) of reception by the server from the terminal of a request for registration of a secondary terminal, comprising an identifier of the secondary mobile terminal to be associated on the data storage means of the server with said identification information of the merchant.

[0026] Step (al) comprises the prior transmission of a message, between the mobile terminal and said secondary terminal, via the proximity communication channel.

[0027] Said proximity communication channel between the mobile terminal and the electronic payment terminal is not via the network.

[0028] Said proximity communication channel between the mobile terminal and the electronic payment terminal is an optical channel or a near-field radio channel.

[0029] According to a second aspect, a method is proposed for implementing a transaction, on an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant, comprising the implementation of the method for initializing the electronic payment terminal of the first aspect.

[0030] According to a third aspect, the invention relates to a set of a server for managing dematerialized bank domiciliation cards, an electronic payment terminal of a merchant and a mobile terminal of the merchant, connected via a network, characterized in that:

[0031] the server comprises data storage means storing merchant identification information associated with said mobile terminal, and data processing means configured to: - Receive a request to initialize the electronic payment terminal requiring a bank domiciliation card storing said identification information of said merchant; - Transmit to the mobile terminal data necessary for the initialization of said electronic payment terminal;

[0032] The mobile terminal and the electronic payment terminal comprise data processing means configured to: - Transmit a message containing the said data necessary for the initialization of the said electronic payment terminal, from the mobile terminal to the electronic payment terminal, via a proximity communication channel; - Implement the initialization of said electronic payment terminal using the data received.

[0033] According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of initializing an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant, or a method according to the second aspect for implementing a transaction, on an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant;and a storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to the first aspect of initializing an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant, or a method for implementing a transaction, on an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant. ; PRESENTATION OF FIGURES

[0034] Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

[0035] [Fig.l] [Fig.l] is a diagram of a system for implementing the initialization method according to the invention;

[0036] [Fig.2] [Fig.2] is a flowchart illustrating the steps of an embodiment of the initialization method according to the invention;

[0037] [Fig.3] [Fig.3] represents examples of interfaces during the implementation of the initialization method according to the invention;

[0038] [Fig.4a] [Fig.4a] is a flowchart illustrating the steps of a first embodiment of a method for implementing a transaction;

[0039] [Fig.4b] [Fig.4b] is a flowchart illustrating the steps of a second embodiment of a method for implementing a transaction. DETAILED DESCRIPTION

[0040] Architecture

[0041] The present invention relates to a method for initializing an electronic payment terminal (EPT) 2 of a merchant, requiring a bank domiciliation card (DOM card) storing identification information of said merchant, in a system such as represented in [Fig.l].

[0042] By "initialization" of the TPE 2, we mean its configuration so as to allow the subsequent implementation of transactions between the merchant who owns the TPE 2, and an individual who is typically a customer of the merchant. Conventionally, initialization requires the DOM card to be validated (so as to ensure the merchant's consent).

[0043] An individual's bank card, i.e. a payment card (typically CB, Visa, Mastercard, etc.), should not be confused with the merchant's bank domiciliation card or DOM card (also called a merchant card), which does not allow any payment but simply authorizes certain operations on the TPE 2. This DOM card therefore stores information identifying said merchant, in particular on a magnetic strip (typically ISO2), this information advantageously being a merchant contract identifier of the merchant (in particular a 7-digit number), or at least an encoding of this identifier (in particular in ISO2 format as explained). Said information identifying said merchant may also include a merchant contract type identifier (CB EMV, CB CLESS, etc.).

[0044] Indeed, it is necessary to have as many DOM cards as merchant contracts, allowing for example various types of payment: a CB EMV contract (for payment by insertion with the usual CB Visa or MasterCard bank cards), a CB CLESS contract (for contactless payment with the usual bank cards), an AMEX contract, a CONECS contract (for restaurant voucher card), etc. A DOM card is typically provided by a banking establishment with which the merchant has subscribed to said merchant contract (and in particular has an open bank account).

[0045] In the present method, we consider the particular case of said initialization requiring the bank domiciliation card. Indeed, the majority of transactions and in particular, debit transactions can be made without restriction as long as the TPE 2 is configured. In contrast, initialization and certain "sensitive" transactions require the scanning of the said magnetic strip of the DOM card by the TPE 2 ("swiping" the card) to be validated. Note that the DOM card relating to the correct merchant contract must be used, and therefore, in the event of subscribing to a plurality of contracts, as many initializations must be implemented with a DOM card.

[0046] Note that it is also entirely possible for the merchant to have several TPEs sharing said contracts (and therefore each one can be initialized with the same DOM card).

[0047] The present method aims to dematerialize bank domiciliation cards, i.e. to authorize virtual DOM cards, called “eDOM”, emulated by a server 3, for managing dematerialized bank domiciliation cards, called eDOM server (and a mobile application, as will be explained).

[0048] In this respect, it will be understood that the present method allows an initialization requiring a DOM card without the physical card, using instead a mobile terminal 1 of the merchant. To rephrase, the present initialization can be implemented without physically handling the DOM card (no magnetic stripe reading), but the initialization still requires (and uses) a DOM card even though it is virtual. By analogy, it is entirely possible to implement a bank card payment transaction by having only a smartphone emulating such a card, and therefore in the absence of a physical card.

[0049] As we will see, we can completely do without any physical DOM card (fully dematerialized mode, which avoids all the logistics associated with the manufacture and sending of the card, as well as the risks of loss or theft of the DOM card), or else authorize a hybrid mode, i.e. the merchant always has a physical DOM card but can choose to use this card or the dematerialized version if he does not have it to hand, or even keep it in a secure location (safe).

[0050] The TPE 2 is connected via a network 20 (in particular the internet network) to said server 3, generally remote. The server 3 is generally a banking server, but it can be completely limited to the management of eDOM cards, and for security reasons separate from the usual banking servers for processing transactions.

[0051] The mobile terminal 1 and the TPE 2 each have data processing means 11, 21 (typically a processor) and data storage means 12, 22 (a memory, for example flash). Each may further comprise an interface (for example a screen), proximity wireless communication means (for example NFC, see below), and a camera. The mobile terminal 1 is advantageously of the smartphone type (and the preceding elements such as a camera are common for any mobile terminal), and the TPE 2 generally has a card reader, although it could also be a mobile terminal configured as a TPE. Again, you can have several TPE 2s from the merchant.

[0052] The server 3 also has data processing means 31 (typically a processor) and data storage means 32 (a memory, for example a hard disk). It is also connected to the terminal 1 by the network 20.

[0053] Onboarding

[0054] In order to emulate the DOM cards, the server 3 stores on its data storage means said merchant identification information (that of the DOM card - as typically explained a merchant contract identifier) ​​associated with said mobile terminal 1 of the merchant, in particular by using a unique identifier of the terminal 1 such as its telephone number, but also a MAC address, an IMSI. It is entirely possible that several DOM cards of the same merchant (corresponding to several contracts) are dematerialized at the same time, in this respect there are therefore several merchant identification information associated with said mobile terminal 1.

[0055] It will be understood that each piece of merchant identification information may possibly be uniquely associated with the merchant's mobile terminal 1, but according to one embodiment, said merchant identification information may also be associated with secondary terminals, which are for example the terminals of the merchant's beneficiaries such as employees (see below).

[0056] We can also have additional attributes relating to the merchant, such as a location (address of the business), opening hours, etc.

[0057] In summary, the storage means 32 preferably store n-tuples of a merchant identifier (merchant contract) and at least one mobile terminal identifier 1 (telephone number), plus any optional attributes.

[0058] In this respect, the method preferably comprises a step (aO) of dematerializing a DOM card, called onboarding. This is an enrollment step. Again, it is possible to either dematerialize an existing physical DOM card, or directly create a new eDOM card (in virtual format only), when subscribing to a merchant contract.

[0059] In this respect, step (aO) comprises the reception by the server 3 of a request for dematerialization of the DOM card, in particular from a trusted entity such as the merchant's bank.

[0060] This dematerialization request includes said merchant identification information and said identifier of the mobile terminal 1.

[0061] The server 3 therefore stores them in an associated manner on the storage means 32.

[0062] Preferably, step (a0) further comprises the verification of said identifier of the mobile terminal 1. In this respect, step (a0) may comprise the transmission to the mobile terminal 1 of a request to verify said identifier of the mobile terminal 1, for example in the form of a notification (such as an SMS) sent to the terminal presenting said identifier, inviting its user (the merchant) to confirm that he does indeed have the terminal 1 and that he wishes this terminal to be the one registered in the context of the dematerialization of the DOM card.

[0063] If terminal 1 responds to said verification request, the link between terminal 1 and server 3 is established.

[0064] Preferably, said verification request comprises an authentication token (for example, a single-use data item such as a nonce, advantageously generated randomly), to be returned to the server 3, so as to prevent false verifications by a fraudulent user.

[0065] According to one embodiment, the verification can be made more secure by verifying that the terminal 1 does indeed have a secret (such as a private key, for example provided by the bank). For this, the expected response then includes data that is a function of the token received and the secret. For example, it can be envisaged that: - a public key / private key pair of an asymmetric encryption algorithm is generated when the contract is signed, for example on the bank's premises; - the public key is transmitted in the dematerialization request (with the merchant identifier and the terminal 1 identifier), and the private key is transmitted to the merchant securely (for example again directly in the bank's premises just after subscription) - server 1 generates a nonce and transfers it to terminal 1 using the identifier - the merchant signs this nonce on his terminal 1 using his private key and returns the signed nonce to server 3 - server 3 verifies that the nonce received is identical to the nonce sent and verifies the signature with the public key, and thus ensures that it is indeed the merchant's terminal 1.

[0066] It will be understood that the present method is not limited to a particular technique for verifying said identifier of the mobile terminal 1 (which may for example be at the initiative of the merchant on the terminal 1) nor even dematerialization, it will be sufficient for said server 3 to store said merchant identification information associated with a mobile terminal 1 of the merchant.

[0067] Conventionally, said response to the verification request can be managed by a dedicated application (for eDOM cards) on the terminal 1.

[0068] As such, said verification request preferably includes a link (URL) allowing the downloading (or opening) of said eDOM card management application, and containing said token. As will be seen, said application may be used in the remainder of the method when the implementation of the initialization is desired. The application may also, for example, allow all merchant contracts to be consulted, etc.

[0069] Note that the means 32 can also store in a generic manner (i.e. not associated with a particular merchant) additional technical data for initialization, for example for each model of TPE 2, such as system update data.

[0070] Initialization method

[0071] With reference to [Fig.2], which represents a preferred embodiment, the present method begins, as regards the initialization itself, with a step (a), of reception by the server 3 of a request for initialization of the electronic payment terminal 2.

[0072] This step (a) is typically implemented by terminal 1, even if it can be envisaged that it is implemented by another computer or even the TPE 2 itself.

[0073] Then, in a step (b), the server 3 transmits to the terminal 1 data necessary for the initialization of said electronic payment terminal 2 (which will be called initialization data for convenience).

[0074] These initialization data comprise at least said identification information of said merchant (in particular the merchant contract number, and possibly the type of contract), and optionally any additional technical initialization data (which it is recalled are not linked to the merchant). Note that said initialization data may in one embodiment only be said identification information of said merchant (and nothing else), i.e. the content of the DOM card, if for example the TPE is already technically ready for initialization.

[0075] Preferably, when the initialization request is sent by the mobile terminal 1, the merchant identification information returned is simply that associated with this terminal 1, i.e. this terminal 1 from which the initialization request is received (this request typically containing an identifier of the mobile terminal 1 such as its telephone number) and said merchant identification information of the EPT 2 is associated in the database of the server 3. In other words, the server 3 interrogates the database stored in the means 32 and extracts the merchant identification information associated with the identifier of the terminal 1 of the request received. If the request comes from another device, the merchant must include their mobile terminal identifier 1.

[0076] Then, in a step (c), we want the initialization data to reach the TPE 2 while preventing any possibility of fraud.

[0077] To do this, in step (c) a message containing said data necessary for the initialization of said electronic payment terminal 2 is transmitted from the mobile terminal 1 to the electronic payment terminal 2 via a proximity communication channel.

[0078] By "proximity communication channel" is meant a short-range communication channel which takes advantage of the fact that the merchant must be present and even access the TPE 2 to confirm that he really wants to implement this initialization and that it is indeed his TPE (in the same way that he would do it using his DOM card), advantageously nothing passing via the network 20 (although each of the terminals 1 and 2 is on its side connected to the network 20).

[0079] Preferably, said proximity communication channel is a wireless channel in particular chosen from an optical channel and a near-field radio channel, but it could for example simply be a wired channel (by connecting the terminals 1 and 2 by a cable).

[0080] In the “optical channel” embodiment, said message takes the form of a visual signal, in particular a 2D bar code, and in particular a QR code emitted by the mobile terminal 1 (displayed by a screen) and captured by a camera of the TPE 2. More precisely, the 2D bar code is displayed and the merchant is invited to scan it with his TPE 2, see [Fig.3].

[0081] In the “near field radio channel” embodiment, the message takes the form of a radio signal, in particular an NFC signal (but it could for example alternatively be Bluetooth, etc.), transferred between the terminals 1 and 2 by placing them against each other.

[0082] Then, the TPE 2 extracts said initialization data from the message transmitted via the proximity communication channel.

[0083] Note that if a dedicated application has been installed (at step (aO) or later), these steps (a) to (c) can be implemented by said application, in a manner transparent to the user.

[0084] Then the method comprises a step (d) of implementing the initialization of said electronic payment terminal 2 using the received data.

[0085] This initialization is implemented automatically, in the same way as before, the only difference is that the necessary data comes from server 3 and not from a physical DOM map.

[0086] Preferably, the initialization data comprises said merchant identification information and is advantageously encoded so as to simulate the bank domiciliation card (for example in accordance with the ISO2 track). In the latter case, the TPE 2 believes that the DOM card is presented. In all cases, step (d) comprises the storage of said merchant identification information (at least that relating to the contract(s) concerned - see below) on the data storage means 22 of the TPE 2, with a view to using them subsequently for the implementation of various transactions.

[0087] If the initialization data includes additional technical data, these can also be used, for example to update the system (internal software, in English firmware) of the TPE 2 and / or to facilitate initialization (avoiding manual entries by the merchant on the TPE).

[0088] Multi contracts

[0089] Note that, as explained, there may be several merchant contracts taken out by the merchant, i.e. several dematerialized DOM cards.

[0090] In other words, said merchant identification information may relate to several merchant contracts of the merchant, i.e. they themselves contain several merchant contract identifiers of the merchant (or identifier encoding - in particular in ISO2) and where appropriate several merchant contract type identifiers.

[0091] Preferably, the present method allows the initialization of the TPE 2 so as to implement one or more merchant contracts (potentially all).

[0092] Thus, said initialization data advantageously includes all the merchant identification information associated with said mobile terminal 1, i.e. regardless of the merchant contract to which they relate.

[0093] Then step (c) comprises the prior selection by the merchant on his terminal 1 (via interface, advantageously using the dedicated application) of at least one contract in accordance with which he wishes to initialize the TPE 2. This selection triggers the transmission via the proximity communication channel (in particular generation and display of QR code)

[0094] For example, as seen in [Fig.3], there are 4 contracts that have been subscribed to (and recorded on the server 3) for the merchant, which the latter can select in the application on his mobile terminal 1: an EMV contract, a CLESS contract, an AMEX contract and a CONECS contract.

[0095] For each, we see the type identifier followed by the contract number. The merchant can select only some of them for a given TPE 2, as explained. Then, the QR code is generated so as to represent a message containing the data initialization information relating to the selected contracts (identification information relating to the selected contracts, i.e. the identifiers of these contracts).

[0096] In a particularly preferred manner, steps (a) and (b) can be implemented well before steps (c) and (d), potentially automatically following step (a0): thus, as soon as the terminal requests the dematerialization of a DOM card, it is assumed that the merchant wants to initialize at least one EPT 2, and therefore the merchant's identification information is "pushed" to the terminal 1. In the event of repetition of step (a0), i.e. dematerialization of a new DOM card, the merchant's identification information is completed on the server 3 (with the addition of the new contract), and then, a new implementation of steps (a) and (b) can be triggered to update the data on the mobile terminal 1.

[0097] The response to the request for verification of said identifier of the mobile terminal 1 in step (a0) can advantageously play the role of an initialization request. Steps (c) and (d) then amount to a “finalization” of the initialization, triggered by the merchant when he selects one or more contracts.

[0098] Method for implementing a transaction

[0099] Today, in addition to initialization, the transactions concerned by the need for a DOM card are in particular either a credit transaction, with or without contact (money is transferred to the individual presenting it via his payment card, i.e. to reimburse him), or the cancellation of a previous transaction, in particular a debit transaction recorded on the TPE 2 (before the remote collection). Note that you must use the DOM card relating to the correct merchant contract: for example, if the transaction requested is the cancellation of a contactless payment, you must use the DOM card from the CB CLESS contract.

[0100] It is understood that the above-mentioned transactions are sensitive in the sense that they benefit the individual and not the merchant: a malicious fraudster could try to use the EFT in the absence of the merchant to implement credit transactions for his benefit, hence the fact that such transactions require the DOM card. The list of transactions requiring a DOM card may, however, evolve and DOM card providers are free to consider other transactions (or even all of them) as sensitive.

[0101] Thus, preferably, the invention further proposes a method for implementing a transaction, on the merchant's TPE 2 (already initialized), also requiring said DOM card storing identification information of said merchant, following the present initialization method.

[0102] With reference to Figures 4a and 4b, which represent two alternative modes, this other method begins, as regards the implementation of the transaction itself, with a step (a'), implemented by the processing means of data 21 of the TPE 2, of transmission to said server 3, of a request for authorization of said transaction.

[0103] We note that such a request is implicitly already existing in a classic TPE: it is transmitted to the interface 23 of the TPE and asks the user (for example via a displayed message) to swipe his DOM card.

[0104] What is innovative here is that the request is transmitted externally, to server 3. Note that it is always possible, in a hybrid mode, to also indicate that it can always use its DOM card.

[0105] Said request for authorization of said transaction typically includes descriptive information of the transaction.

[0106] Furthermore, it is recalled that the TPE 2 has been correctly initialized, so that it also stores said merchant identification information, and in a conventional manner the request can include this information (for example, any receipt issued by a TPE following a transaction includes the number of the merchant contract used for the transaction).

[0107] In response, the server 3 transmits an authentication token (again, for example, single-use data such as a nonce, advantageously generated randomly).

[0108] According to a first variant, corresponding to [Fig.4a], the authentication token is transmitted to the TPE 2 in step (b'). In other words, the server 3 simply responds to the authorization request.

[0109] Then, in a step (c'), we want the server 3 to see the token returned, but from the terminal 1, so as to prove the merchant's consent.

[0110] To do this, in step (c') a message containing the authentication token is transmitted in advance from the electronic payment terminal 2 to the mobile terminal 1 via a proximity communication channel (which is not necessarily the same as the channel used for initialization).

[0111] By "proximity communication channel" we recall that we mean a short-range communication channel which takes advantage of the fact that the merchant must be present and even access the TPE 2 to confirm that he really wants to implement this transaction (in the same way that he would do by using his DOM card), advantageously nothing passing via the network 20 (although each of the terminals 1 and 2 is on its side connected to the network 20).

[0112] Preferably, said proximity communication channel is a wireless channel in particular chosen from an optical channel and a near-field radio channel, but it could for example simply be a wired channel (by connecting the terminals 1 and 2 by a cable).

[0113] In the “optical channel” embodiment, said message takes the form of a visual signal, in particular a 2D bar code, and in particular a QR code emitted by the TPE 2 (displayed by a screen) and captured by a camera of the mobile terminal 1. More precisely, the 2D barcode is displayed and the merchant is invited to scan it with his terminal 1.

[0114] In the “near field radio channel” embodiment, the message takes the form of a radio signal, in particular an NFC signal (but it could for example alternatively be Bluetooth, etc.), transferred between the terminals 1 and 2 by placing them against each other.

[0115] Then, the mobile terminal 1 extracts from the message transmitted via the proximity communication channel said authentication token and retransmits it to the server 3 as explained. The token can be encoded, signed, etc., and therefore not be returned as is. Note that if a dedicated application has been installed (at step (a0) or later), these actions can be implemented by said application, in a manner transparent to the user.

[0116] According to a preferred embodiment, at least one contextual parameter of the mobile terminal 1 is also transmitted (by the terminal 1) in step (c') with the token. By contextual parameter, we mean a parameter representative of the context in which the terminal is located, in particular a geolocation parameter (GPS coordinates, identification of a Wifi access point) or a time parameter (time stamp), etc. As will be seen, this or these contextual parameters can be verified to detect cases of fraud.

[0117] Then, in a step (d'), the server 3 verifies that the authentication token received from the electronic payment terminal 2 coincides with the authentication token transmitted to the mobile terminal 1. This step may, if necessary, include the processing of the token received, if for example it has been encoded, hence the term "coincides" which must be taken in the broad sense: we will also cover the case of a challenge / response (the "response" provided by the terminal 1 must coincide with the "challenge" which the authentication token initially sent to the EPT 2).

[0118] Indeed, if the same token is returned, or at least an expected token, this proves to server 3 that the proximity communication took place correctly. If, on the contrary, a different token is received, this is clearly an attempt at fraud.

[0119] Preferably, the method further comprises verifying that said mobile terminal 1 from which the authentication token is received is indeed the one associated with said merchant identification information, i.e. that this terminal 1 and said merchant identification information of the EPT 2 from which the authorization request is received are indeed associated in the database of the server 3.

[0120] Indeed, we know from which TPE the request was received in step (a'), this request typically containing said merchant identification information (merchant contract identifier), and from which mobile terminal 1 the authentication token was received (identifier such as telephone number). We check that this terminal 1 is the one expected, i.e. the one associated with the said merchant identification information.

[0121] This helps prevent another fraud scenario where a third party would attempt to use their own terminal to validate the transaction without the merchant's consent.

[0122] Finally, if a contextual parameter has been sent, it is verified. This can be done for example by comparing it with attributes also associated with said merchant identifier information (see above). For example, we can have an expected location, which we compare with the location of terminal 1: if the two are far apart, it means that terminal 1 is not close to EFT 2 and that we are in a fraudulent situation.

[0123] If the verifications are completed (if the authentication token received from the mobile terminal 1 coincides with the authentication token transmitted to the electronic payment terminal 2, and advantageously if said mobile terminal 1 from which the authentication token is received is indeed the one associated with said merchant identification information), then the server 3 transmits to the electronic payment terminal 2 an authorization to implement said transaction.

[0124] This may be a simple notification interpretable by the TPE 2, or a message comprising said merchant identification information encoded so as to simulate the bank domiciliation card (for example in accordance with the ISO2 track). In the latter case, the TPE 2 believes that the DOM card is presented.

[0125] In both cases this allows the TPE 2, in a step (e'), to implement said transaction. In this respect, the TPE can proceed in a conventional manner and transmit the descriptive data of the transaction to an appropriate banking server.

[0126] Alternatively, if the verification fails, then no authorization is transmitted to the TPE 2, and potentially a refusal notification is transmitted instead, so that the transaction is rejected by the TPE 2.

[0127] In all cases, the data storage means 32 of the server 3 can store a history of the transaction authorization requests of the TPE 2, with the result, in particular consultable from said dedicated application on the terminal 1.

[0128] According to a second variant, corresponding to [Fig.4b], the authentication token transits in the opposite direction. The token is thus transmitted (from the server 3) to the terminal 1 of the merchant in step (b'), more precisely to the terminal associated with said merchant identification information, i.e. this terminal 1 and said merchant identification information of the EPT 2 from which the authorization request is received (this request typically containing said merchant identification information merchant - merchant contract identifier) ​​are associated in the database of the server 3. In other words, the server 3 queries the database stored in the means 32 and extracts the identifier of the terminal 1 associated with the identification information received.

[0129] Then, in a step (c'), we want the server 3 to see the token returned, but from the TPE 1, so as to prove the merchant's consent.

[0130] To do this, in step (c') a message containing the authentication token is transmitted in advance from the mobile terminal 1 to the electronic payment terminal 2 via said proximity communication channel described previously.

[0131] The terminals are simply reversed, so that in the “optical channel” embodiment, said message takes the form of a visual signal, in particular a 2D barcode, and in particular a QR code emitted by the mobile terminal 1 (displayed by a screen) and captured by a camera of the TPE 2. More precisely, the 2D barcode is displayed and the merchant is invited to scan it with the TPE 2.

[0132] Then, the TPE 2 extracts from the message transmitted via the proximity communication channel said authentication token and retransmits it to the server 3 as explained.

[0133] According to a preferred embodiment, at least one contextual parameter of the mobile terminal 1 is also transmitted (by the terminal 1) either directly to the server 3, or in the message via said proximity communication channel in step (c') with the token.

[0134] Steps (d') and (e') and can then be implemented in an identical manner to the first variant (verification that the authentication token received from the electronic payment terminal 2 coincides with the authentication token transmitted to the mobile terminal 1).

[0135] Note that there is no need for a second verification since we are already sure that the token has been sent to the correct terminal 1. Indeed, in this second variant it is basically impossible for an individual to fraudulently receive the token on an unauthorized terminal.

[0136] Secondary terminals

[0137] According to a preferred embodiment, the method may comprise a step (al) of reception by the server 3 from the terminal 1 of a request for registration of a secondary terminal, comprising an identifier of the secondary mobile terminal to be associated on the data storage means 32 of the server 3 with said merchant identification information. This is a request aimed at giving said secondary terminal the right to also use the eDOM card, it is therefore a delegation of rights.

[0138] By secondary terminal, we mean a mobile terminal other than terminal 1, the latter constituting a “main” terminal. Secondary terminals are typically those of the merchant’s employees, who may themselves be required to having to implement an initialization requiring the DOM card, and therefore in theory the merchant's terminal 1 if you no longer have a physical DOM card. The idea is that they are autonomous.

[0139] This step (al) can be implemented anytime after the onboarding of step (aO).

[0140] Preferably, step (al) is implemented in a similar manner to the method which is the subject of the invention: with the transmission of a message, between the mobile terminal 1 and said secondary terminal, via the proximity communication channel. This makes it possible to prove the proximity of the two terminals and the consent of the merchant.

[0141] For example, following the registration request of a secondary terminal, the server 3 sends an authentication token to the main terminal or to the secondary terminal, which token must be transferred to the other terminal via the proximity communication channel (for example QR code) and sent to the server 3 in a similar manner to step (c').

[0142] As in step (d'), if the authentication token received from one of the main terminal and the secondary terminal coincides with the authentication token transmitted to the other of the main terminal and the secondary terminal, it is considered that the consent of the merchant is acquired and the registration request is accepted: as in step (a0) the identifier of the secondary terminal is thus associated on the data storage means 32 of the server 3 with said identification information of the merchant (this information then becomes associated with both the main terminal and the secondary terminal).

[0143] It is also possible to do without a token, with the main terminal or the secondary terminal sending a message containing its identifier (telephone number) directly to the other via the proximity communication channel.

[0144] This embodiment is very practical, because said history of transaction authorization requests of the TPE 2 preferably includes the identifier of the terminal at the origin of the request.

[0145] Thus, if a registered secondary terminal (and therefore having the right to use the eDOM card) implements a fraudulent operation, the merchant will know since the history, which can be consulted from said dedicated application on terminal 1, will mention this operation and the terminal at the origin.

[0146] Note that it can be provided that the secondary terminals themselves allow other secondary terminals to be recorded, or alternatively only the main terminal.

[0147] Server and terminals

[0148] According to a third aspect, the invention relates to the assembly of a server 3 for managing dematerialized bank domiciliation cards, of a payment terminal electronic terminal 2 of a merchant and a mobile terminal 1 of the merchant, connected via a network 20, for implementing the method according to the first aspect (and where appropriate the method for implementing a transaction according to the second aspect).

[0149] Thus, this server 3 and these terminals 1 and 2 comprise, as explained respectively, at least data processing means 31, 11, 21 and a memory 32, 12, 22, and the latter two advantageously a camera and / or display means and / or near-field communication means.

[0150] It is assumed that the merchant is entitled to have a DOM card storing merchant identification information (i.e. he has signed a merchant contract - he may in practice not request a physical DOM card).

[0151] In this respect, the data storage means 32 store said merchant identification information associated with said mobile terminal 1.

[0152] The data processing means 31 of the server 3 are configured to implement steps consisting of: - Receive a request to initialize the electronic payment terminal 2 requiring a bank domiciliation card storing said identification information of said merchant; - Transmit to the mobile terminal 1 data necessary for the initialization of said electronic payment terminal 2.

[0153] The data processing means 11, 21 of the mobile terminal 1 and of the electronic payment terminal 2 are configured to implement the step of transmitting a message containing said data necessary for the initialization of said electronic payment terminal 2, from the mobile terminal 1 to the electronic payment terminal 2, via a proximity communication channel.

[0154] The data processing means 21 of the electronic payment terminal 2 are configured to implement the step of implementing the initialization of said electronic payment terminal 2 using the received data (extracted from said message transmitted via said proximity communication channel from the terminal 1).

[0155] Computer program product

[0156] According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means 11, 21, 31 of the terminals 1 and 2, and of the server 3) of a method according to the first aspect for initializing an electronic payment terminal 2 of a merchant or of a method according to the second aspect for implementing a transaction, on the electronic payment terminal of a merchant, each requiring a bank domiciliation card storing identification information of said merchant; as well as storage means readable by a computer equipment (for example the data storage means 12, 22, 32 of the terminals 1 and 2, and of the server 3) on which this computer program product is found.

Claims

Claims

1. Method for initializing an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant, the method being characterized in that it comprises the implementation of steps of: a. Reception by a server (3) comprising data storage means (32) storing said merchant identification information uniquely associated with a mobile terminal (1) of the merchant, and connected via a communication network (20) to said electronic payment terminal (2) and to the mobile terminal (1), of a request for initialization of the electronic payment terminal (2); b. Transmission to the mobile terminal (1) of the data necessary for the initialization of said electronic payment terminal (2); c.Transmission of a message containing said data necessary for the initialization of said electronic payment terminal (2), from the mobile terminal (1) to the electronic payment terminal (2), via a proximity communication channel d. Implementation of the initialization of said electronic payment terminal (2) using the received data.

2. Method according to claim 1, wherein said data necessary for initializing said electronic payment terminal (2) comprises said identification information of said merchant.

3. Method according to claim 2, in which the request for initialization of the electronic payment terminal (2) is received from the mobile terminal (1), the identification information of said merchant transmitted in step (b) is that associated with said mobile terminal (1) from which the request for initialization of the electronic payment terminal (2) is received.

4. Method according to one of claims 2 and 3, wherein said identification information of said merchant relates to several merchant contracts of the merchant; said data transmitted in step (b) comprising the identification information of the merchant relating to all said merchant contracts of the merchant; step (c) comprising the prior selection by the merchant on the mobile terminal (1) of at least one contract in accordance with which he wishes to initialize the electronic payment terminal (2); and said data transmitted in step (d) comprising only the merchant's identification information relating to the merchant's selected merchant contracts.

5. Method according to one of claims 1 to 4, comprises a prior step (aO) of reception by the server (3) of a request for dematerialization of the bank domiciliation card, comprising said merchant identification information and an identifier of the mobile terminal (1) to be associated on the data storage means (32) of the server (3) with said merchant identification information.

6. Method according to claim 5, wherein step (aO) comprises transmitting to the mobile terminal (1) a request to verify said identifier of the mobile terminal (1).

7. Method according to claim 6, in which said request for verification of said identifier of the mobile terminal (1) causes the opening of a dedicated application if it is already installed, and otherwise its downloading from the network (20) then its installation, said application being configured to respond in step (a0) to said request for verification of said identifier of the mobile terminal (1), and to extract in step (c) from the message transmitted via the proximity communication channel said authentication token and retransmit it to the server (3).

8. Method according to one of claims 1 to 7, comprising a step (al) of reception by the server (3) from the terminal (1) of a request for registration of a secondary terminal, comprising an identifier of the secondary mobile terminal to be associated on the data storage means (32) of the server (3) with said merchant identification information.

9. Method according to claim 8, wherein step (al) comprises the prior transmission of a message, between the mobile terminal (1) and said secondary terminal, via the proximity communication channel.

10. Method according to one of claims 1 to 9, wherein said proximity communication channel between the mobile terminal (1) and the electronic payment terminal (2) is not via the network (20).

11. The method of claim 10, wherein said proximity communication channel between the mobile terminal (1) and the electronic payment terminal (2) is an optical channel or a near-field radio channel.

12. Method for implementing a transaction, on an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant, comprising implementing the method for initializing the electronic payment terminal (2) according to one of claims 1 to 11.

13. Assembly of a server (3) for managing dematerialized bank domiciliation cards, an electronic payment terminal (2) of a merchant and a mobile terminal (1) of the merchant, connected via a network (20), characterized in that: the server (3) comprises data storage means (32) storing identification information of the merchant associated with said mobile terminal (1), and data processing means (31) configured to: - Receive a request for initialization of the electronic payment terminal (2) requiring a bank domiciliation card storing said identification information of said merchant; - Transmit to the mobile terminal (1) data necessary for the initialization of said electronic payment terminal (2);The mobile terminal (1) and the electronic payment terminal (2) comprise data processing means (11, 21) configured to: - Transmit a message containing said data necessary for the initialization of said electronic payment terminal (2), from the mobile terminal (1) to the electronic payment terminal (2), via a proximity communication channel; - Implement the initialization of said electronic payment terminal (2) using the received data.;

14. Computer program product comprising code instructions for executing a method according to one of claims 1 to 11 for initializing an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant, or a method according to claim 12 for implementing a transaction, on an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant; when said program is executed on a computer.

15. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 11 for initializing an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant, or a method according to claim 12 for implementing a transaction, on an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant.

Images