Method for implementing a transaction on an electronic payment terminal of a merchant

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 information for identifying the merchant, the method being characterised in that it comprises implementing, using data processing means (31) of a server (3) which comprises data storage means (32) storing the merchant identification information associated with a mobile terminal (1) of the merchant and which is connected via a communication network (20) to the electronic payment terminal (2) and to the mobile terminal (1), the steps of: (a) receiving, from the electronic payment terminal (2), a request to authorise the transaction; (b) transmitting an authentication token to the electronic payment terminal (2); (c) receiving the authentication token from the mobile terminal (1); (d) if the authentication token received from the mobile terminal (1) matches the authentication token transmitted to the electronic payment terminal (2), transmitting an authorisation to the electronic payment terminal (2) to implement the transaction; wherein step (c) comprises the prior transmission of a message containing the authentication token from the electronic payment terminal (2) to the mobile terminal (1), via a proximity communication channel.

Description

[0001] Description

[0002] Title of the invention: Method for implementing a transaction on a merchant's electronic payment terminal.

[0003] GENERAL TECHNICAL FIELD

[0004] The present invention relates to the field of electronic payment terminals. More specifically, it relates to a method for implementing a transaction, on a merchant's electronic payment terminal, requiring a bank domiciliation card storing identification information of said merchant.

[0005] STATE OF THE ART

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

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

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

[0009] This card is now essential for operating an EFT:

[0010] - it allows you to configure the EFT to authorize a type of payment and for payments of this type to be paid into the linked account;

[0011] - it must be present to validate transaction cancellation or credit operations.

[0012] It should be 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.

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

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

[0015] 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 could be used without the merchant's consent to carry out a fraudulent transaction, for example by an employee with access to these cards.

[0016] The present invention improves the situation.

[0017] PRESENTATION OF THE INVENTION

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

[0019] (a) Receipt, from the electronic payment terminal, of a request for authorization of said transaction;

[0020] (b) Transmission to the electronic payment terminal of an authentication token;

[0021] (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;

[0022] Wherein 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.

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

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

[0025] (a) Receipt, from the electronic payment terminal, of a request for authorization of said transaction;

[0026] (b) Transmission to the mobile terminal of an authentication token;

[0027] (c) Receipt, from the electronic payment terminal, of said authentication token;

[0028] (d) If the authentication token received from the electronic payment terminal matches the authentication token transmitted to the mobile terminal, transmitting to the electronic payment terminal an authorization to implement said transaction; Wherein 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.

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

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

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

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

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

[0034] 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 then its installation, said application being configured to respond in step (aO) 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.

[0035] The method comprises a step (a1) 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. Step (a1) comprises the prior transmission of a message, between the mobile terminal and said secondary terminal, via the proximity communication channel.

[0036] The said transaction is either a credit transaction or a cancellation of a transaction previously implemented on the electronic payment terminal.

[0037] The said proximity communication channel between the mobile terminal and the electronic payment terminal is not via the network.

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

[0039] Step (c) further comprises receiving at least one contextual parameter from the mobile terminal, step (d) further comprising verifying said received contextual parameter.

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

[0041] - 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;

[0042] - Transmit an authentication token to one of the electronic payment terminal and the mobile terminal

[0043] - 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;

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

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

[0046] 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 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 executing a method according to the first aspect for implementing a transaction, on an electronic payment terminal of a merchant, requiring a bank domiciliation card storing identification information of said merchant.

[0047] PRESENTATION OF FIGURES

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

[0049] [Fig. 1]Figure 1 is a diagram of a system for implementing the method of implementing a transaction according to the invention;

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

[0051] [Fig. 3]Figure 3 shows examples of interfaces when implementing the initialization method;

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

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

[0054] DETAILED DESCRIPTION

[0055] Architecture

[0056] 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 as shown in Figure 1.

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

[0058] An individual's (a customer'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, and in particular an initialization of the TPE 2 which will be described later. The DOM card is indeed a merchant's card and not a customer's card, and only a customer's card allows a transaction between the merchant and this customer. Thus, this initialization does not require a customer's bank card, and is a generic procedure that is not linked to a particular transaction. In contrast, each subsequent transaction of this type always requires a customer's payment card (and in rare cases also the DOM card for security purposes - see below - but generally not).

[0059] This DOM card stores identification information of said merchant, in particular on a magnetic strip (typically ISO2), this information advantageously being a (unique) identifier of the merchant's merchant contract (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.), defining said authorized payment type.

[0060] Indeed, it is necessary to have as many DOM cards as merchant contracts (even if two contracts can in practice point to the same merchant bank account), 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 AM EX 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 the said merchant contract (and in particular has an open bank account, and makes the link with this account). The merchant can also combine several merchant contracts from various banks (if for example he has several bank accounts opened in several banks).To summarize, the “payment type” preferentially defines the (unique) combination of a payment technology and a merchant’s bank account.

[0061] In this process, we are considering the specific 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 the 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.

[0062] 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 all) as sensitive.

[0063] Thus, this procedure 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.

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

[0065] The present process aims to dematerialize bank domiciliation cards, i.e. 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).

[0066] 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 payment transaction by bank card using only a smartphone emulating such a card, and therefore in the absence of a physical card.

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

[0068] The TPE 2 is connected via a network 20 (in particular the internet network) to said server 3, generally remote. 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.

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

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

[0071] Onboarding

[0072] 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 by 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.

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

[0074] There may also be additional attributes related to the merchant, such as location (business address), opening hours, etc.

[0075] In summary, preferably the storage means 32 store n-tuples of a merchant identifier (merchant contract) and at least one mobile terminal identifier 1 (telephone number), plus any optional attributes. As such, 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.

[0076] In this respect, step (aO) includes 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.

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

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

[0079] 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 within the framework of the dematerialization of the DOM card.

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

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

[0082] According to one embodiment, the verification can be further secured 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;

[0083] - the public key is transmitted in the dematerialization request (with the merchant identifier and the terminal identifier 1), and the private key is transmitted to the merchant securely (for example again directly in the bank's premises just after subscription)

[0084] - server 1 generates a nonce and transfers it to terminal 1 using the identifier

[0085] - the merchant signs this nonce on his terminal 1 using his private key and returns the signed nonce to server 3

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

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

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

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

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

[0091] Initialization process

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

[0093] 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 any individual who is typically a customer of the merchant, in accordance with a given payment type. To rephrase, said initialization is a configuration preliminary to the operation of said TPE 2 implemented by the merchant, so as to authorize any transaction in accordance with said given payment type for its benefit. Initialization makes it possible in particular to link the TPE 2 with a bank account of the merchant, so that transactions in accordance with said given payment type will be from customer accounts to this merchant account, hence the importance of such initialization.We will therefore not confuse the initialization of the TPE 2 (which is done once and makes any transaction possible in accordance with the transaction type) with the simple preparation of the TPE for a given transaction (which requires that the initialization has been done previously and must be repeated for each transaction).

[0094] Initialization typically consists of recording on the TPE 2 at least the said identification information of the said merchant, and if necessary additional technical data.

[0095] With reference to Figure 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, i.e. a request to configure said TPE 2 so as to authorize any transaction in accordance with a type of payment defined by the DOM card for the benefit of said merchant.

[0096] This step (a') is typically implemented by terminal 1, although it could be implemented by another computer or even the TPE 2 itself. We repeat that at this stage no client is involved.

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

[0098] These initialization data include at least said identification information of said merchant (in particular the merchant contract identifier, and possibly the type of contract, type of payment, etc.), and optionally any additional technical initialization data (which it is recalled is 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 EFT is already technically ready for initialization.

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

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

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

[0102] By "proximity communication channel" 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 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).

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

[0104] 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 his TPE 2, see figure 3.

[0105] 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 terminals 1 and 2 by placing them against each other.

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

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

[0108] Then the method comprises a step (d') of implementing the initialization of said electronic payment terminal 2 using the received data. This initialization is implemented automatically, in an identical manner to what happened before, the only difference being that the necessary data comes from the server 3 and not from a physical DOM card.

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

[0110] If the initialization data includes additional technical data, these may 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).

[0111] Multi-contracts

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

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

[0114] 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), i.e. several simultaneous initializations so as to authorize several types of payment at once. Thus, said initialization data advantageously include all the merchant identification information associated with said mobile terminal 1, i.e. regardless of the merchant contract to which they relate.

[0115] Then step (c') includes 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 TPE 2. This selection triggers the transmission via the proximity communication channel (in particular generation and display of QR code)

[0116] For example, as seen in Figure 3, there are 4 contracts that have been subscribed to (and recorded on 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.

[0117] 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 in such a way 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).

[0118] In a particularly preferred manner, steps (a') and (b') can be implemented well before steps (c') and (d'), potentially automatically following step (aO): 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 (aO), 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.

[0119] The response to the verification request for 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.

[0120] Method of implementing a transaction

[0121] With reference to figures 4a and 4b, which represent two alternative modes, the present method begins, with regard to 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.

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

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

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

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

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

[0127] According to a first variant, corresponding to figure 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. Then, in a step (c), we want the server 3 to receive the token back, but from the terminal 1, so as to prove the merchant's consent.

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

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

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

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

[0132] 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 terminals 1 and 2 by placing them against each other.

[0133] 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 (aO) or later), these actions can be implemented by said application, transparently for the user.

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

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

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

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

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

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

[0140] Finally, if a contextual parameter has been sent, it is checked. This can be done, for example, by comparing it with attributes also associated with the 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.

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

[0142] This can be a simple notification interpretable by the TPE 2, or a message including the said merchant identification information encoded in such a way 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.

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

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

[0145] According to a second variant, corresponding to Figure 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 queries the database stored in the means 32 and extracts the identifier of the terminal 1 associated with the identification information received.

[0146] So, in step (c), we want server 3 to receive the token, but from TPE 1, so as to prove the merchant's consent.

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

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

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

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

[0151] Note that there is no need for a second verification since we are already sure that the token was 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.

[0152] Secondary terminals

[0153] According to a preferred embodiment, the method may comprise a step (a1) 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.

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

[0155] This step (a1) can be implemented at any time after the onboarding of step (a0). Preferably, step (a1) 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.

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

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

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

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

[0160] Thus, if a registered secondary terminal (and therefore having the right to use the eDOM card) implements a fraudulent transaction, the merchant will know it since the history, consultable from said dedicated application on terminal 1, will mention this transaction and the terminal at the origin. Note that it can be provided that the secondary terminals themselves allow other secondary terminals to be registered, or alternatively only the main terminal.

[0161] Server and terminals

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

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

[0164] It is connected via network 20 to a merchant's TPE 2 and to the merchant's mobile terminal 1.

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

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

[0167] The data processing means 31 are configured to implement steps consisting of:

[0168] - 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;

[0169] - Transmit an authentication token to one of the electronic payment terminal 2 and the mobile terminal 1

[0170] - 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;

[0171] - 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 2 an authorization to implement said transaction.

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

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

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

[0175] Computer program product

[0176] 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) Receipt, from the electronic payment terminal (2), of a request for authorization of said transaction; (b) Transmission to the electronic payment terminal (2) of an authentication token; (c) Reception, from the mobile terminal (1) of 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) Receipt, from the electronic payment terminal (2), of a request for authorization of said transaction; (b) Transmission to the mobile terminal (1) of an authentication token; (c) Receipt, from the electronic payment terminal (2) of said authentication token; (d) If the authentication token received from the electronic payment terminal (2) matches 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, in which 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, in which 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 (a1) 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, in which step (a1) 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, in which 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, in which said proximity communication channel between the mobile terminal (1) and the electronic payment terminal (2) is not via the network (20).

13. Method according to 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 identification information of the merchant 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 an authentication token to one of the electronic payment terminal (2) and the mobile terminal (1) - Receiving, 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 an electronic payment terminal (2) of a merchant, requiring a bank domiciliation card storing identification information of said merchant.

Images