Method for implementing a transaction on a merchant's electronic payment terminal.

Abstract

The present invention relates to a 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, the method being characterized in that it comprises the implementation, by data processing means (31) of a server (3) comprising data storage means (32) storing said identification information of the merchant 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 steps of: Receiving, from the electronic payment terminal (2), a request for authorization of said transaction; Transmitting to the electronic payment terminal (2) an authentication token; Receiving, from the mobile terminal (1) said authentication token;If the authentication token received from the mobile terminal (1) coincides with the authentication token transmitted to the electronic payment terminal (2), transmission to the electronic payment terminal (2) of an authorization to implement said transaction; In which step (c) comprises the prior transmission of a message containing said authentication token, from the electronic payment terminal (2) to the mobile terminal (1), via a proximity communication channel. [Fig. 1];

Description

Title of the invention: Method for implementing a transaction on 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 implementing a transaction, on 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 transaction, 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 variant of a first aspect, to 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, the method being characterized in that it comprises the implementation, by data processing means of a server comprising data storage means storing said identification information of the merchant 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 steps of: a. Receipt, from the electronic payment terminal, of a request for authorization of said transaction; b. Transmission to the electronic payment terminal of an authentication token; c. Receipt, from the mobile terminal, of said authentication token; d. If the authentication token received from the mobile terminal matches the authentication token transmitted to the electronic payment terminal, transmission to the electronic payment terminal of an authorization to implement said transaction;

[0014] In which step (c) comprises the prior transmission of a message containing said authentication token, from the electronic payment terminal to the mobile terminal, via a proximity communication channel.

[0015] According to advantageous and non-limiting characteristics, the authorization is transmitted in step (d) only if said mobile terminal from which the authentication token is received is indeed the one associated with said merchant identification information.

[0016] The present invention relates, according to a second variant of the first aspect, to 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, the method being characterized in that it comprises the implementation, by data processing means of a server comprising data storage means storing said identification information of the merchant 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 steps of: a. Receipt, from the electronic payment terminal, of a request for authorization of said transaction; b. Transmission to the mobile terminal of an authentication token; c. Receipt, from the electronic payment terminal, of said authentication token; d. If the authentication token received from the electronic payment terminal matches the authentication token transmitted to the mobile terminal, transmission to the electronic payment terminal of an authorization to implement said transaction;

[0017] In which step (c) comprises the prior transmission of a message containing said authentication token, from the mobile terminal to the electronic payment terminal, via a proximity communication channel.

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

[0019] Said authorization to implement said transaction transmitted in step (d) comprises said merchant identification information encoded so as to simulate the bank domiciliation card.

[0020] The method comprises a step (e) of implementing said transaction by the electronic payment terminal.

[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 causes the opening of a dedicated application if it is already installed, and otherwise its downloading from the network then its installation, said application being configured to respond in step (a0) to said request to verify 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.

[0024] 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.

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

[0026] Said transaction is either a credit transaction or a cancellation of a transaction previously implemented on the electronic payment terminal.

[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] Step (c) further comprises receiving at least one contextual parameter from the mobile terminal, step (d) further comprising verifying said received contextual parameter.

[0030] According to a second aspect, the invention relates to a server for managing dematerialized bank domiciliation cards, connected via a network to an electronic payment terminal of a merchant and a mobile terminal of the merchant, characterized in that it comprises data storage means storing merchant identification information associated with said mobile terminal, and data processing means configured to: - Receive, from the electronic payment terminal, a request for authorization of a transaction requiring a bank domiciliation card storing said identification information of said merchant; - Transmit an authentication token to one of the electronic payment terminal and the mobile terminal - Receive, from the other of the electronic payment terminal and the mobile terminal, said authentication token, a message containing said authentication token having previously been transferred between the electronic payment terminal and the mobile terminal, via a proximity communication channel; - If the authentication token transmitted to one of the electronic payment terminal and the mobile terminal coincides with the authentication token received from the other of the electronic payment terminal and the mobile terminal, transmit to the electronic payment terminal an authorization to implement said transaction.

[0031] According to a third aspect, the invention relates to an assembly of the server according to the second aspect, of said mobile terminal and of said electronic payment terminal, the mobile terminal and the electronic payment terminal comprising data processing means configured to transmit the message containing said authentication token, between the electronic payment terminal and the mobile terminal, via said proximity communication channel.

[0032] 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 for implementing a transaction, on a 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 for the implementation of a transaction, on an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant. PRESENTATION OF FIGURES

[0033] 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:

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

[0035] [Fig.2] [Fig.2] is a flowchart illustrating the steps of an embodiment of an initialization method;

[0036] [Fig.3] [Fig.3] represents examples of interfaces during the implementation of the initialization method;

[0037] [Fig.4a] [Fig.4a] is a flowchart illustrating the steps of a first embodiment of the method for implementing a transaction according to the invention;

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

[0039] Architecture

[0040] The present invention relates to a method for implementing a transaction, on 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].

[0041] Said transaction is between the merchant who owns the TPE 2, and an individual who is typically a customer of the merchant. It generally involves a bank card of said individual (or a smartphone emulating such a bank card), but compared to a classic debit transaction it requires the DOM card to be validated (so as to ensure the merchant's consent).

[0042] 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 identification information of said merchant, in particular on a magnetic stripe (typically IS02), 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 identification information of said merchant may further include a merchant contract type identifier (CB EMV, CB CLESS, etc.).

[0043] 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).

[0044] In the present method, we are considering the particular case of a transaction requiring a bank domiciliation card. Indeed, the majority of transactions, and in particular debit transactions, can be made without restriction once the TPE 2 is configured. In contrast, certain “sensitive” transactions require the scanning of said magnetic strip of the DOM card by the TPE 2 (“swiping” the card) to be validated. Today, the transactions concerned are in particular either a credit transaction, with or without contact (money is transferred to the individual presenting it via their payment card, i.e., reimbursing them), or the cancellation of a previous transaction, in particular a debit transaction recorded on the TPE 2 (before the remote collection).Please note that you must use the DOM card relating to the correct merchant contract: for example, if the requested transaction is the cancellation of a contactless payment, you must use the DOM card from the CB CLESS contract.

[0045] 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.

[0046] Thus, the present method applies to any transaction on the EFT which could require a bank debit card, and it will not be limited to the case of credit or cancellation.

[0047] Note that it is also entirely possible for the merchant to have several EFTs sharing said contracts (and therefore on each of which a transaction can be implemented with the same DOM card).

[0048] 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).

[0049] In this respect, it will be understood that the present method allows the implementation of a transaction requiring a DOM card without the physical card, using instead a mobile terminal 1 of the merchant. To rephrase, the present transaction (as explained, advantageously credit or cancellation) can be implemented without physically handling the DOM card (no magnetic stripe reading), but the transaction 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.

[0050] 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).

[0051] 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 limited to the management of eDOM cards, and for security reasons separate from the usual banking servers for processing transactions.

[0052] 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 can also include 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 usual for any mobile terminal), and the TPE 2 generally has a card reader, even if it could also be a mobile terminal configured as an TPE. Again, there can be several TPE 2s of the merchant.

[0053] 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.

[0054] Onboarding

[0055] In order to emulate the DOM cards, the server 3 stores on its data storage means said merchant identification information (those 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 quite possible that several DOM cards of the same merchant (corresponding to several contracts) are dematerialized at the same time, as such we therefore have several merchant identification information associated with said mobile terminal 1.

[0056] 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).

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

[0058] 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.

[0059] 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.

[0060] 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.

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

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

[0063] Preferably, step (a0) further comprises the verification of said identifier of the mobile terminal 1. In this respect, step (aO) 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 as part of the dematerialization of the DOM card.

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

[0065] Preferably, said verification request comprises a token

[0066]

[0067]

[0068]

[0069]

[0070]

[0071] authentication (for example, single-use data such as a nonce, advantageously generated randomly), to be returned to server 3, so as to prevent false verifications by a fraudulent user. According to one embodiment, the verification can be made more secure by verifying that the terminal 1 has 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. 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. Typically, the said response to the verification request can be managed by a dedicated application (for eDOM cards) on terminal 1. 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 we will see, said application can be used in the rest of the process when the implementation of a transaction is desired. The application can also, for example, allow the consultation of all merchant contracts, etc. 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. Initialization process

[0072] The present invention further proposes a method for initializing the merchant's TPE 2, also requiring the DOM card storing identification information of said merchant, prior to the present method for implementing a transaction.

[0073] With reference to [Fig.2], which represents a preferred embodiment, this other method begins with a step (a'), of reception by the server 3 of a request to initialize the electronic payment terminal 2.

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

[0075] 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).

[0076] These initialization data comprise at least said identification information of said merchant (in particular the merchant contract identifier, and possibly the contract type), 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.

[0077] 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 from the received request. If the request comes from another device, the merchant must then include his identifier of the mobile terminal 1 therein.

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

[0079] 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.

[0080] By "proximity communication channel" we mean a communication channel short range 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).

[0081] 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).

[0082] 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].

[0083] 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.

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

[0085] 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.

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

[0087] 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.

[0088] 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.

[0089] 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).

[0090] Multi contracts

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

[0092] 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.

[0093] Preferably, this method prior to the method according to the invention allows the initialization of the TPE 2 so as to implement one or more merchant contracts (potentially all).

[0094] 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.

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

[0096] 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.

[0097] 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 initialization data relating to the selected contracts (identification information relating to the selected contracts, i.e. the numbers of these contracts).

[0098] 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 EFT 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 mobile terminal 1.

[0099] 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.

[0100] Method for implementing a transaction

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

[0102] 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.

[0103] 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.

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

[0105] Furthermore, it is assumed that the TPE 2 has been correctly initialized, so that preferably it also stores said merchant identification information, and conventionally the request may 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).

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

[0107] 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.

[0108] 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.

[0109] 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 the possible initialization).

[0110] 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 as he would do 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).

[0111] 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).

[0112] 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 bar code is displayed and the merchant is invited to scan it with his terminal 1.

[0113] 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.

[0114] 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, transparently for the user.

[0115] 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.

[0116] 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).

[0117] 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 at If, on the contrary, a different token is received, this is clearly an attempt at fraud.

[0118] 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.

[0119] 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 verify that this terminal 1 is indeed the one expected, i.e. the one associated with said merchant identification information.

[0120] This prevents another fraud scenario in which a third party would attempt to use their own terminal to validate the transaction without the merchant's consent.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 TPE2.

[0126] 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.

[0127] 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 merchant's terminal 1 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 contract identifier) ​​are 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 identifier of the terminal 1 associated with the identification information received.

[0128] 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.

[0129] 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.

[0130] 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 2 (displayed by a screen) and captured by a camera of the TPE 2 1. More precisely, the 2D barcode is displayed and the merchant is invited to scan it with the TPE 2.

[0131] 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.

[0132] 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.

[0133] Steps (d) and (e) 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).

[0134] 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.

[0135] Secondary terminals

[0136] 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 to register 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.

[0137] 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 have to implement a transaction requiring the DOM card, and therefore in theory the merchant’s terminal 1 if one no longer has a physical DOM card. The idea is that they are autonomous.

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

[0139] Preferably, step (al) is implemented in a similar manner to the method which is the subject of the invention: with the prior 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.

[0140] 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 manner similar to step (c).

[0141] 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).

[0142] 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.

[0143] 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.

[0144] 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.

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

[0146] Server and terminals

[0147] According to a second aspect, the invention relates to the server 3 for implementing the method according to the first aspect, i.e. a server for managing dematerialized bank domiciliation cards.

[0148] Thus, this server 3 comprises, as explained, at least data processing means 31 and a memory 32.

[0149] It is connected via the network 20 to the TPE 2 of a merchant and to the mobile terminal 1 of the merchant.

[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 are configured to implement steps consisting of: - Receive, from the electronic payment terminal 2, a request for authorization of a transaction requiring a bank domiciliation card storing said identification information of said merchant; - Transmit an authentication token to one of the electronic payment terminal 2 and the mobile terminal 1 - Receive, from the other of the electronic payment terminal 2 and the mobile terminal 1, said authentication token, a message containing said authentication token having previously been transferred between the electronic payment terminal 2 and the mobile terminal 1, via a proximity communication channel; - If the authentication token transmitted to one of the electronic payment terminal 2 and the mobile terminal 1 coincides with the authentication token received from the other of the electronic payment terminal 2 and the mobile terminal 1 (and preferably, in the case where the authentication token is received from the terminal 1, this token is indeed the one associated with said merchant identification information), transmit to the electronic payment terminal electronics 2 an authorization to implement said transaction.

[0153] According to a third aspect, the invention proposes an assembly comprising the server 3 according to the second aspect, said mobile terminal 1 and said electronic payment terminal 2. It is naturally possible to have several terminals 1, where appropriate main or secondary, and several TPEs 2.

[0154] These terminals 1, 2 also comprise, as explained, at least data processing means 11, 21 and a memory 12, 22, and advantageously a camera and / or display means and / or near-field communication means, potentially also a card reader.

[0155] The data processing means 11, 21 are configured to transmit the message containing said authentication token, between the electronic payment terminal 2 and the mobile terminal 1, via said proximity communication channel.

[0156] Computer program product

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

Claims

Claims

1. 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, the method being characterized in that it comprises the implementation, by data processing means (31) of a server (3) comprising data storage means (32) storing said identification information of the merchant 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 steps of: a. Receiving, from the electronic payment terminal (2), a request for authorization of said transaction; b. Transmitting to the electronic payment terminal (2) an authentication token; c. Receiving, from the mobile terminal (1) said authentication token; d.If the authentication token received from the mobile terminal (1) coincides with the authentication token transmitted to the electronic payment terminal (2), transmission to the electronic payment terminal (2) of an authorization to implement said transaction; In which step (c) comprises the prior transmission of a message containing said authentication token, from the electronic payment terminal (2) to the mobile terminal (1), via a proximity communication channel.

2. Method according to claim 1, wherein the authorization is transmitted to step (d) only if said mobile terminal (1) from which the authentication token is received is indeed the one associated with said merchant identification information.

3. 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, the method being characterized in that it comprises the implementation, by data processing means (31) of 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 steps of: a. Receiving, from the electronic payment terminal (2), a request for authorization of said transaction; b. Transmitting to the mobile terminal (1) an authentication token; c. Receiving, from the electronic payment terminal (2) said authentication token; d.If the authentication token received from the electronic payment terminal (2) coincides with the authentication token transmitted to the mobile terminal (1), transmission to the electronic payment terminal (2) of an authorization to implement said transaction; In which step (c) comprises the prior transmission of a message containing said authentication token, from the mobile terminal (1) to the electronic payment terminal (2), via a proximity communication channel.

4. Method according to one of claims 1 to 3, wherein said authorization to implement said transaction transmitted in step (d) comprises said merchant identification information encoded so as to simulate the bank domiciliation card.

5. Method according to one of claims 1 to 4, comprising a step (e) of implementing said transaction by the electronic payment terminal (2).

6. Method according to one of claims 1 to 5, 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.

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

8. Method according to claim 7, 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).

9. Method according to one of claims 1 to 8, 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.

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

11. Method according to one of claims 1 to 10, wherein said transaction is either a credit transaction or a cancellation of a transaction previously implemented on the electronic payment terminal (2).

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

13. The method of claim 12, 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.

14. Method according to one of claims 1 to 13, wherein step (c) further comprises receiving at least one contextual parameter from the mobile terminal (1), step (d) further comprising verifying said received contextual parameter.

15. Server (3) for managing dematerialized bank domiciliation cards, connected via a network (20) to an electronic payment terminal (2) of a merchant and a mobile terminal (1) of the merchant, characterized in that it comprises data storage means (32) storing merchant identification information associated with said mobile terminal (1), and data processing means (31) configured to: - Receive, from the electronic payment terminal (2), a request for authorization of a transaction requiring a bank domiciliation card storing said identification information of said merchant; - Transmit to one of the electronic payment terminal (2) and the mobile terminal (1) an authentication token - Receive, from the other of the electronic payment terminal (2) and the mobile terminal (1), said authentication token, a message containing said authentication token having previously been transferred between the electronic payment terminal (2) and the mobile terminal (1), via a proximity communication channel;- If the authentication token transmitted to one of the electronic payment terminal (2) and the mobile terminal (1) coincides with the authentication token received from the other of the electronic payment terminal (2) and the mobile terminal (1), transmit to the electronic payment terminal (2) an authorization to implement said transaction.;

16. Server assembly (3) according to claim 15, of said mobile terminal (1) and of said electronic payment terminal (2), the mobile terminal (1) and the electronic payment terminal (2) comprising data processing means (11, 21) configured to transmit the message containing said authentication token, between the electronic payment terminal (2) and the mobile terminal (1), via said proximity communication channel.

17. Computer program product comprising code instructions for executing a method according to one of claims 1 to 14 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.

18. 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 14 for the implementation of a transaction, on a electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant.

Images