Brevet FR3160492A1 — publié le 20250926

La présente invention concerne un procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (31) d’un serveur (3) comprenant des moyens de stockage de données (32) stockant lesdites informations d’identification du marchand associées à un terminal mobile (1) du marchand, et connecté via un réseau de communication (20) audit terminal de paiement électronique (2) et au terminal mobile (1), d’étapes de : Réception, depuis le terminal de paiement électronique (2), d’une requête d’autorisation de ladite transaction ; Transmission au terminal de paiement électronique (2) d’un jeton d’authentification ; Réception, depuis le terminal mobile (1) dudit jeton d’authentification ; Si le jeton d’authentification reçu depuis le terminal mobile (1) coïncide avec le jeton d’authentification transmis au terminal de paiement électronique (2), transmission au terminal de paiement électronique (2) d’une autorisation de mise en œuvre de ladite transaction ; Dans lequel l’étape (c) comprend la transmission préalable d’un message contenant ledit jeton d’authentification, du terminal de paiement électronique (2) au terminal mobile (1), via un canal de communication de proximité. [Fig. 1] Procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine des terminaux de paiement électronique. Plus précisément, elle concerne un procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand. ETAT DE L’ART Traditionnellement, les commerçants disposant d’un terminal de paiement électronique (TPE) ont besoin d’une carte de domiciliation bancaire, dite carte DOM. Il s’agit d’une carte physique au format carte de paiement (à ne pas confondre avec ces dernières), stockant en particulier dans une piste magnétique (ISO2) des informations d’identification du commerçant, tel qu’un un identifiant de contrant commerçant du marchand. La carte DOM est délivrée par un établissement bancaire et permet de lier le TPE au compte bancaire professionnel du commerçant. Cette carte est aujourd’hui indispensable pour faire fonctionner un TPE : elle permet de configurer le TPE de sorte à ce que les paiements soient versés sur le compte lié elle doit être présente pour valider les opérations d’annulation d’une transaction ou de crédit. On note que les informations stockées par la carte (identifiant de contrat commerçant) ne sont pas secrètes, mais l’exigence de la présence de la carte permet de garantir efficacement le consentement du marchand à mettre en œuvre ces opérations particulières. Cette solution est satisfaisante, mais s’avère quand même contraignante. En effet, si le commerçant a plusieurs contrats commerçant (correspondant généralement à plusieurs types de cartes bancaires, d'interface ou de service (contact, sans contact, vente à distance VAD, etc.)), il doit avoir autant de cartes DOM et utiliser la bonne à chaque fois. Et ces cartes sont susceptibles d’être perdues (en particulier s’il en a plusieurs), ce qui peut bloquer l’activité du commerçant. De plus il y a toujours le risque qu’elles soient utilisées sans le consentement du commerçant pour mettre en œuvre une opération frauduleuse, par exemple par un employé ayant accès à ces cartes. La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon une première variante d’un premier aspect à un procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un serveur comprenant des moyens de stockage de données stockant lesdites informations d’identification du marchand associées à un terminal mobile du marchand, et connecté via un réseau de communication audit terminal de paiement électronique et au terminal mobile, d’étapes de : Réception, depuis le terminal de paiement électronique, d’une requête d’autorisation de ladite transaction ; Transmission au terminal de paiement électronique d’un jeton d’authentification ; Réception, depuis le terminal mobile dudit jeton d’authentification ; Si le jeton d’authentification reçu depuis le terminal mobile coïncide avec le jeton d’authentification transmis au terminal de paiement électronique, transmission au terminal de paiement électronique d’une autorisation de mise en œuvre de ladite transaction ; Dans lequel l’étape (c) comprend la transmission préalable d’un message contenant ledit jeton d’authentification, du terminal de paiement électronique au terminal mobile, via un canal de communication de proximité. Selon des caractéristiques avantageuses et non-limitatives, l’autorisation n’est transmise à l’étape (d) que si ledit terminal mobile depuis lequel le jeton d’authentification est reçu est bien celui associé auxdites informations d’identification du marchand. La présente invention se rapporte selon une deuxième variante du premier aspect à un procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un serveur comprenant des moyens de stockage de données stockant lesdites informations d’identification du marchand associées de manière unique à un terminal mobile du marchand, et connecté via un réseau de communication audit terminal de paiement électronique et au terminal mobile, d’étapes de : Réception, depuis le terminal de paiement électronique, d’une requête d’autorisation de ladite transaction ; Transmission au terminal mobile d’un jeton d’authentification ; Réception, depuis le terminal de paiement électronique dudit jeton d’authentification ; Si le jeton d’authentification reçu depuis le terminal de paiement électronique coïncide avec le jeton d’authentification transmis au terminal mobile, transmission au terminal de paiement électronique d’une autorisation de mise en œuvre de ladite transaction ; Dans lequel l’étape (c) comprend la transmission préalable d’un message contenant ledit jeton d’authentification, du terminal mobile au terminal de paiement électronique, via un canal de communication de proximité. Selon des caractéristiques avantageuses et non-limitatives : Ladite autorisation de mise en œuvre de ladite transaction transmise à l’étape (d) comprend lesdites informations d’identification du marchand encodées de sorte à simuler la carte de domiciliation bancaire. Le procédé comprend une étape (e) de mise en œuvre de ladite transaction par le terminal de paiement électronique. Le procédé comprend une étape préalable (a0) de réception par le serveur d’une requête de dématérialisation de la carte de domiciliation bancaire, comprenant lesdites informations d’identification du marchand et un identifiant du terminal mobile à associer sur les moyens de stockage de données du serveur auxdites informations d’identification du marchand. L’étape (a0) comprend la transmission au terminal mobile d’une requête de vérification dudit identifiant du terminal mobile. Ladite requête de vérification dudit identifiant du terminal mobile entraîne l’ouverture d’une application dédiée si elle est déjà installée, et sinon son téléchargement depuis le réseau puis son installation, ladite application étant configurée pour répondre à l’étape (a0) à ladite requête de vérification dudit identifiant du terminal mobile, et à extraire à l’étape (c) du message transmis via le canal de communication de proximité ledit jeton d’authentification et le retransmettre au serveur. Le procédé comprend une étape (a1) de réception par le serveur depuis le terminal d’une requête d’enregistrement d’un terminal secondaire, comprenant un identifiant du terminal mobile secondaire à associer sur les moyens de stockage de données du serveur auxdites informations d’identification du marchand. L’étape (a1) comprend la transmission préalable d’un message, entre le terminal mobile et ledit terminal secondaire, via le canal de communication de proximité. Ladite transaction est soit une transaction de crédit, soit une annulation d’une transaction mise en œuvre antérieurement sur le terminal de paiement électronique. Ledit canal de communication de proximité entre le terminal mobile et le terminal de paiement électronique n’est pas via le réseau. Ledit canal de communication de proximité entre le terminal mobile et le terminal de paiement électronique est un canal optique ou un canal radio en champ proche. L’étape (c) comprend en outre la réception d’au moins un paramètre contextuel du terminal mobile, l’étape (d) comprenant en outre la vérification dudit paramètre contextuel reçu. Selon un deuxième aspect, l’invention concerne un serveur de gestion de cartes de domiciliation bancaire dématérialisées, connecté via un réseau à un terminal de paiement électronique d’un marchand et un terminal mobile du marchand, caractérisé en ce qu’il comprend des moyens de stockage de données stockant des informations d’identification du marchand associées audit terminal mobile, et des moyens de traitement de données configurés pour : Recevoir, depuis le terminal de paiement électronique, une requête d’autorisation d’une transaction nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre à l’un du terminal de paiement électronique et du terminal mobile un jeton d’authentification Recevoir, depuis l’autre du terminal de paiement électronique et du terminal mobile, ledit jeton d’authentification, un message contenant ledit jeton d’authentification ayant préalablement été transféré entre le terminal de paiement électronique et le terminal mobile, via un canal de communication de proximité ; Si le jeton d’authentification transmis à l’un du terminal de paiement électronique et du terminal mobile coïncide avec le jeton d’authentification reçu depuis l’autre du terminal de paiement électronique et du terminal mobile, transmettre au terminal de paiement électronique une autorisation de mise en œuvre de ladite transaction. Selon un troisième aspect, l’invention concerne un ensemble du serveur selon le deuxième aspect, dudit terminal mobile et dudit terminal de paiement électronique, le terminal mobile et le terminal de paiement électroniques comprenant des moyens de traitement de données configurés pour transmettre le message contenant ledit jeton d’authentification, entre le terminal de paiement électronique et le terminal mobile, via ledit canal de communication de proximité. Selon un quatrième et un cinquième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé de mise en œuvre d’une transaction selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation d’un procédé d’initialisation ; FIG. 3 la FIG. 3 représente des exemples d’interfaces lors de la mise en œuvre du procédé d’initialisation ; FIG. 4 la FIG. 4 est un logigramme illustrant les étapes d’un premier mode de réalisation du procédé pour mettre en œuvre une transaction selon l’invention ; FIG. 4 la FIG. 4 est un logigramme illustrant les étapes d’un deuxième mode de réalisation du procédé pour mettre en œuvre une transaction selon l’invention. DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne un procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (TPE) 2 d’un marchand, nécessitant une carte de domiciliation bancaire (carte DOM) stockant des informations d’identification dudit marchand, dans un système tel que représenté sur la FIG. 1 . Ladite transaction est entre le marchand possesseur du TPE 2, et un individu typiquement client du marchand. Elle implique généralement une carte bancaire dudit individu (ou un smartphone émulant une telle carte bancaire), mais par rapport à une transaction de débit classique elle nécessite la carte DOM pour être validée (de sorte à s’assurer du consentement du marchand). On ne confondra pas la carte bancaire d’un individu, i.e. une carte de paiement (typiquement CB, Visa, mastercard…), avec ladite carte de domiciliation bancaire du marchand ou carte DOM (appelée également carte commerçant), qui ne permet aucun paiement mais simplement autorise certaines opérations sur le TPE 2. Cette carte DOM stocke à ce titre des informations d’identification dudit marchand, en particulier sur une piste magnétique (typiquement ISO2), ces informations étant avantageusement un identifiant de contrant commerçant du marchand (en particulier un numéro à 7 chiffres), ou du moins un encodage de cet identifiant (en particulier au format ISO2 comme expliqué). Lesdites informations d’identification dudit marchand peuvent en outre comprendre un identifiant de type de contrat commerçant (CB EMV, CB CLESS, etc.). En effet, il est nécessaire d’avoir autant de cartes DOM que de contrats commerçants, permettant par exemple divers types de paiement : un contrat CB EMV (pour paiement par insertion avec les cartes bancaires usuelles CB Visa ou Mastercard), un contrat CB CLESS (pour paiement sans contact avec les cartes bancaires usuelles), un contrat AMEX, un contrat CONECS (pour carte titre restaurant), etc. Une carte DOM est typiquement fournie par un établissement bancaire auprès duquel le marchand a souscrit ledit contrat commerçant (et a en particulier un compte bancaire ouvert). On se place dans le présent procédé dans le cas particulier d’une transaction nécessitant la carte de domiciliation bancaire. En effet, la majorité des transactions et en particulier les transactions de débit peuvent être faites sans restriction dès lors que le TPE 2 est configuré. Par contraste, certaines transactions « sensibles » nécessitent pour être validées le scan de ladite bande magnétique de la carte DOM par le TPE 2 (« swiper » la carte). Aujourd’hui, les transactions concernées sont en particulier soit une transaction de crédit, avec ou sans contact (on vient transférer de l’argent à l’individu présentant via sa carte de paiement, i.e. le rembourser), soit l’annulation d’une transaction antérieure, en particulier d’une transaction débit enregistrée sur le TPE 2 (avant la télécollecte). A noter qu’il faut utiliser la carte DOM relative au bon contrat commerçant : par exemple, si la transaction demandée est l’annulation d’un paiement sans contact, il faut utiliser la carte DOM du contrat CB CLESS. On comprend que les transactions susmentionnées sont sensibles dans le sens où elles bénéficient à l’individu et non au marchand : un fraudeur mal intentionné pourrait essayer d’utiliser le TPE en l’absence du marchand pour mettre en œuvre des transactions de crédit à son profit, d’où le fait que de telles transactions nécessitent la carte DOM. La liste des transactions nécessitant une carte DOM peut toutefois évoluer et les fournisseurs de cartes DOM sont libres de considérer d’autres transactions (voir toutes) comme sensibles. Ainsi le présent procédé s’applique à toute transaction sur le TPE qui pourrait nécessiter une carte de domiciliation bancaire, et on ne sera pas limité au cas du crédit ou de l’annulation. A noter qu’il est en outre tout à fait possible que le marchand ait plusieurs TPE partageant lesdits contrats (et donc sur chacun desquels on peut mettre en œuvre une transaction avec la même carte DOM). Le présent procédé vise à dématérialiser les cartes de domiciliation bancaire, i.e. autoriser des cartes DOM virtuelles, dites « eDOM », émulées par un serveur 3, de gestion de cartes de domiciliation bancaire dématérialisées, dit serveur eDOM (et une application mobile, comme on expliquera). A ce titre, on comprendra que le présent procédé permet la mise en œuvre d’une transaction nécessitant une carte DOM sans la carte physique, en utilisant à la place un terminal mobile 1 du marchand. Pour reformuler, la présente transaction (comme expliqué, avantageusement crédit ou annulation) pourra être mise en œuvre sans physiquement manipuler la carte DOM (pas de lecture de bande magnétique), mais la transaction nécessite (et utilise) toujours une carte DOM bien que celle-ci soit virtuelle. Par analogie, on peut tout à fait mettre en œuvre une transaction de paiement par carte bancaire en ayant uniquement un smartphone émulant une telle carte, et donc en l’absence de carte physique. Comme l’on verra, on peut complètement se passer de toute carte DOM physique (mode intégralement dématérialisé, ce qui évite toute la logistique associée à la fabrication et l’envoi de la carte, ainsi que les risques de perte ou vol de la carte DOM), ou alors autoriser un mode hybride, i.e. que le marchand dispose toujours d’une carte DOM physique mais puisse au choix utiliser cette carte ou la version dématérialisée s’il ne l’a pas sous la main, voire la garde dans un lieu sécurisé (coffre-fort). Le TPE 2 est connecté via un réseau 20 (en particulier le réseau internet) audit serveur 3, généralement distant. Le serveur 3 est généralement un serveur bancaire, mais il peut tout à fait être limité à la gestion des cartes eDOM, et par sécurité distinct des habituels serveurs bancaires de traitement des transactions. Le terminal mobile 1 et le TPE 2 disposent chacun de moyens de traitement de données 11, 21 (typiquement un processeur) et de moyens de stockage de données 12, 22 (une mémoire, par exemple flash). Chacun peut en outre comporter une interface (par exemple un écran), des moyens de communication sans-fil de proximité (par exemple NFC, voir plus loin), et une caméra. Le terminal mobile 1 est avantageusement de type smartphone (et les éléments précédents tel qu’une caméra sont habituels pour tout terminal mobile), et le TPE 2 dispose généralement d’un lecteur de carte, même si ce pourrait également être un terminal mobile configuré en tant que TPE. A nouveau on peut avoir plusieurs TPE 2 du marchand. Le serveur 3 dispose également de moyens de traitement de données 31 (typiquement un processeur) et de moyens de stockage de données 32 (une mémoire, par exemple un disque dur). Il est également connecté au terminal 1 par le réseau 20. Onboarding De manière à émuler les cartes DOM, le serveur 3 stocke sur ses moyens de stockage de données lesdites informations d’identification du marchand (celles de la carte DOM – comme expliqué typiquement un identifiant de contrat commerçant) associées audit terminal mobile 1 du marchand, notamment en utilisant un identifiant unique du terminal 1 tel que son numéro de téléphone, mais également une adresse MAC, une IMSI. Il est tout à fait possible que plusieurs cartes DOM du même marchand (correspondant à plusieurs contrats) soient en même temps dématérialisées, à ce titre on a donc plusieurs informations d’identification du marchand associées audit terminal mobile 1. On comprendra que chaque information d’identification du marchand peut éventuellement être associée de manière unique au terminal mobile 1 du marchand, mais selon un mode de réalisation on peut également associer lesdites information d’identification du marchand à des terminaux secondaires, qui sont par exemple les terminaux d’ayants-droit du marchand tels que des salariés (voir plus loin). On peut également avoir de attributs supplémentaires relatifs au marchand, comme un localisation (adresse du commerce), des horaires d’ouverture, etc. En résumé, de manière préférée les moyens de stockage 32 stockent des n-uplets d’un identifiant de marchand (contrat commerçant) et d’au moins un identifiant de terminal mobile 1 (numéro de téléphone), plus d’éventuels attributs optionnels. A ce titre, le procédé comprend préférentiellement une étape (a0) de dématérialisation d’une carte DOM, dite d’onboarding. Il s’agit d’une étape d’enrôlement. A nouveau on peut soit dématérialiser une carte DOM physique existante, soit directement créer une nouvelle carte eDOM (au seul format virtuel), lors de la souscription d’un contrat commerçant. A ce titre, l’étape (a0) comprend la réception par le serveur 3, d’une requête de dématérialisation de la carte DOM, en particulier depuis une entité de confiance telle que la banque du marchand. Cette requête de dématérialisation comprend lesdites informations d’identification du marchand et ledit identifiant du terminal mobile 1. Le serveur 3 les stocke donc de manière associée sur les moyens de stockage 32. De manière préférée, l’étape (a0) comprend en outre la vérification dudit identifiant du terminal mobile 1. A ce titre, l’étape (a0) peut comprendre la transmission au terminal mobile 1 d’une requête de vérification dudit identifiant du terminal mobile 1, par exemple sous la forme d’une notification (telle qu’un SMS) envoyée au terminal présentant ledit identifiant, invitant son utilisateur (le marchand) à confirmer qu’il possède bien le terminal 1 et qu’il souhaite bien que ce terminal soit celui enregistré dans le cadre de la dématérialisation de la carte DOM. Si le terminal 1 répond à ladite requête de vérification, le lien entre le terminal 1 et le serveur 3 est établi. De manière préférée ladite requête de vérification comprend un jeton d’authentification (par exemple une donnée à usage unique tel qu’un nonce, avantageusement générée aléatoirement), à renvoyer au serveur 3, de sorte à prévenir de fausses vérifications par un utilisateur frauduleux. Selon un mode de réalisation, on peut sécuriser davantage la vérification en vérifiant que le terminal 1 dispose bien d’un secret (tel qu’une clé privée, par exemple fourni par la banque). Pour cela la réponse attendue comprend alors une donnée fonction du jeton reçu et du secret. Par exemple, on peut envisager que : une paire clé publique/clé privée d’un algorithme de chiffrement asymétrique est généré à la souscription du contrat, par exemple dans les locaux de la banque ; la clé publique est transmise dans la requête de dématérialisation (avec l’identifiant du marchand et l’identifiant du terminal 1), et la clé privée est transmise au marchand de manière sécurisée (par exemple à nouveau directement dans les locaux de la banque juste après la souscription) le serveur 1 génère un nonce et le transfert au terminal 1 grâce à l’identifiant le marchand signe ce nonce sur son terminal 1 au moyen de sa clé privée et renvoie le nonce signé au serveur 3 le serveur 3 vérifie que le nonce reçu est identique au nonce envoyé et vérifie la signature avec la clé publique, et s’assure ainsi que c’est bien le terminal 1 du marchand. On comprendra que le présent procédé n’est pas limité à une technique particulière de vérification dudit identifiant du terminal mobile 1 (qui peut par exemple être à l’initiative du marchand sur le terminal 1) ni même de dématérialisation, il suffira que ledit serveur 3 stocke lesdites informations d’identification du marchand associées à un terminal mobile 1 du marchand. De manière classique, ladite réponse à la requête de vérification peut être gérée par une application dédiée (aux cartes eDOM) sur le terminal 1. A ce titre ladite requête de vérification comprend préférentiellement un lien (URL) permettant de télécharger (ou d’ouvrir) ladite application de gestion de la carte eDOM, et contenant ledit jeton. Comme l’on verra, ladite application pourra être utilisée dans la suite du procédé lorsque la mise en œuvre d’une transaction est souhaitée. L’application pourra en outre par exemple permettre de consulter tous les contrats commerçants, etc. A noter que les moyens 32 peuvent également stocker de manière générique (i.e. pas associé avec un marchand en particulier) des données techniques supplémentaires pour l’initialisation, par exemple pour chaque modèle de TPE 2, telles que des données de mise à jour système. Procédé d’initialisation La présente invention propose en outre un procédé d’initialisation du TPE 2 du marchand, nécessitant également la carte DOM stockant des informations d’identification dudit marchand, préalablement au présent procédé de mise en œuvre d’une transaction. En référence à la FIG. 2 , qui représentent un mode de réalisation préféré, cet autre procédé commence par une étape (a’), de réception par le serveur 3 d’une requête d’initialisation du terminal de paiement électronique 2. Cette étape (a’) est typiquement mise en œuvre par le terminal 1, même si on peut envisager qu’elle soit mise en œuvre par un autre ordinateur voire même le TPE 2 lui-même. Ensuite, dans une étape (b’), le serveur 3 transmet au terminal 1 des données nécessaires à l’initialisation dudit terminal de paiement électronique 2 (qu’on appellera données d’initialisation par commodité). Ces données d’initialisation comprennent au moins lesdites informations d’identification dudit marchand (en particulier l’identifiant de contrat commerçant, et éventuellement le type de contrat), et optionnellement les éventuelles données techniques supplémentaires d’initialisation (dont on rappelle qu’elle ne sont pas liées au marchand). A noter que lesdites données d’initialisation peuvent dans un mode de réalisation n’être que lesdites informations d’identification dudit marchand (et rien d’autre), i.e. le contenu de la carte DOM, si par exemple le TPE est déjà techniquement prêt à l’initialisation. De manière préférée, lorsque la requête d’initialisation est envoyée par le terminal mobile 1, les informations d’identification du marchand renvoyées sont simplement celles associées à ce terminal 1, i.e. ce terminal 1 depuis lequel la requête d’initialisation est reçue (cette requête contenant typiquement un identifiant du terminal mobile 1 tel que son numéro de téléphone) et lesdites informations d’identification du marchand du TPE 2 sont associés dans la base du serveur 3. En d’autre termes, le serveur 3 interroge la base stockée dans les moyens 32 et extrait les informations d’identification de marchand associées à l’identifiant du terminal 1 de la requête reçue. Si la requête provient d’un autre équipement, il faut alors que le marchand y inclue son identifiant du terminal mobile 1. Alors, dans une étape (c’), on souhaite que les données d’initialisation parviennent au TPE 2 tout en prévenant toute possibilité de fraude. Pour ce faire, dans l’étape (c’) un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique 2 est transmis du au terminal mobile 1 au terminal de paiement électronique 2 via un canal de communication de proximité. Par « canal de communication de proximité » on entend un canal de communication à courte portée qui tire parti du fait que le marchand doit être présent et même accéder au TPE 2 pour confirmer qu’il veut réellement mettre en œuvre cette initialisation et que c’est bien son TPE (de la même manière qu’il le ferait en utilisant sa carte DOM), avantageusement rien ne passant via le réseau 20 (bien que chacun des terminaux 1 et 2 soit de son côté connecté au réseau 20). De manière préférée, ledit canal de communication de proximité est un canal sans fil en particulier choisi parmi un canal optique et un canal radio en champ proche, mais ce pourrait être par exemple simplement un canal filaire (en connectant les terminaux 1 et 2 par un câble). Dans le mode de réalisation « canal optique », ledit message prend la forme d’un signal visuel, en particulier un code barre 2D, et en particulier un QR code émis par le terminal mobile 1 (affiché par un écran) et capté par une caméra du TPE 2. Plus précisément, le code barre 2D s’affiche et le marchand est invité à le scanner avec son TPE 2, voir la FIG. 3 . Dans le mode de réalisation « canal radio en champ proche », le message prend la forme d’un signal radio, en particulier un signal NFC (mais ce pourrait par exemple alternativement être du Bluetooth, etc.), transféré entre les terminaux 1 et 2 en les mettant l’un contre l’autre. Alors, le TPE 2 extrait du message transmis via le canal de communication de proximité lesdites données d’initialisation. A noter que si une application dédiée a été installée (à l’étape (a0) ou plus tard), ces étapes (a’) à (c’) peuvent être mises en œuvre par ladite application, de manière transparente pour l’utilisateur. Alors le procédé comprend une étape (d’) de mise en œuvre de l’initialisation dudit terminal de paiement électronique 2 en utilisant les données reçues. Cette initialisation est mise en œuvre automatiquement, de manière identique à ce qui se passait avant, la seule différence est que les données nécessaires proviennent du serveur 3 et non d’une carte DOM physique. De manière préférée, les données d’initialisation comprennent lesdites informations d’identification du marchand et sont avantageusement encodées de sorte à simuler la carte de domiciliation bancaire (par exemple conformément à la piste ISO2). Dans ce dernier cas, le TPE 2 croit que la carte DOM est présentée. Dans tous les cas l’étape (d’) comprend le stockage desdites informations d’identification du marchand (au moins celles relatives au ou aux contrat(s) concernés – voir plus loin) sur les moyens de stockage de données 22 du TPE 2, en vue de les utiliser ultérieurement pour la mise en œuvre de transactions diverses. Si les données d’initialisation comprennent des données techniques additionnelles, celles-ci peuvent être également utilisées, par exemple pour mettre à jour le système (logiciel interne, en anglais firmware) du TPE 2 et/ou pour faciliter l’initialisation (en évitant des saisies manuelles par le marchand sur le TPE). Multi contrats A noter qu’il peut y avoir comme expliqué plusieurs contrats commerçants souscrits par le marchand, i.e. plusieurs cartes DOM dématérialisées. En d’autres termes, lesdites informations d’identification du marchand peuvent être relatives à plusieurs contrats commerçants du marchand, i.e. elles-mêmes contenir plusieurs identifiant de contrant commerçant du marchand (ou encodage d’identifiant – en particulier en ISO2) et le cas échéant plusieurs identifiants de type de contrat commerçant. De manière préférée, ce procédé antérieur au procédé selon l’invention permet l’initialisation du TPE 2 de sorte à implémenter un ou plusieurs contrats commerçants (potentiellement tous). Ainsi, lesdites données d’initialisation comprennent avantageusement toutes les informations d’identification du marchand associées audit terminal mobile 1, i.e. quel que soit le contrat commerçant auquel elles sont relatives. Alors l’étape (c’) comprend la sélection préalable par le marchand sur son terminal 1 (via interface, avantageusement en utilisant l’application dédiée) de la sélection d’au moins un contrat conformément auquel il souhaite initialiser le TPE 2. Cette sélection déclenche la transmission via le canal de communication de proximité (notamment génération et affichage de QR code) Par exemple, comme l’on voit sur la FIG. 3 , on a 4 contrats qui ont été souscrits (et enregistrés sur le serveur 3) pour le marchand, que ce dernier peut sélectionner dans l’application sur son terminal mobile 1 : un contrat EMV, un contrat CLESS, un contrat AMEX et un contrat CONECS. On voit pour chacun l’identifiant du type suivi du numéro de contrat. Le marchand peut n’en sélectionner que certains pour un TPE 2 donnée, comme expliqué. Alors, le QR code est généré de sorte à représenter un message contenant les données d’initialisation relatives aux contrats sélectionnés (informations d’indentification relatives aux contrats sélectionnés, i.e. les numéros de ces contrats). De manière particulièrement préférée, les étape (a’) et (b’) peuvent être mise en œuvre bien avant les étapes (c’) et (d’), potentiellement automatiquement dans la foulée de l’étape (a0) : ainsi, dès que le terminal requiert la dématérialisation d’une carte DOM, on suppose que le marchand veut initialiser au moins un TPE 2, et donc on « pousse » les informations d’indentification du marchand vers le terminal 1. En cas de répétition de l’étape (a0), i.e. de dématérialisation d’une nouvelle carte DOM, les informations d’indentification du marchand sont complétées sur le serveur 3 (avec l’ajout du nouveau contrat), et alors, une nouvelle mise en œuvre des étapes (a’) et (b’) peut être déclenchée pour mettre à jour les données sur le terminal mobile 1. La réponse à la requête de de vérification dudit identifiant du terminal mobile 1 à l’étape (a0) peut avantageusement jouer le rôle de requête d’initialisation. Les étapes (c’) et (d’) reviennent alors à une « finalisation » de l’initialisation, déclenchée par le marchand lorsqu’il sélectionne un ou plusieurs contrats. Procédé de mise en œuvre d’une transaction En référence aux figures 4a et 4b , qui représentent deux modes alternatifs, le présent procédé commence, en ce qui concerne la mise en œuvre de la transaction à proprement parler, par une étape (a), mise en œuvre par les moyens de traitement de données 21 du TPE 2, de transmission audit serveur 3, d’une requête d’autorisation de ladite transaction. On note qu’une telle requête est implicitement déjà existante dans un TPE classique : elle est transmise à l’interface 23 du TPE et demande à l’utilisateur (par exemple via un message affiché) de swiper sa carte DOM. Ce qui est innovant est ici que la requête est transmise à l’extérieur, au serveur 3. A noter qu’il est toujours possible, dans un mode hybride, que l’on indique également qu’il peut toujours utiliser sa carte DOM. Ladite requête d’autorisation de ladite transaction comprend typiquement des informations descriptives de la transaction. En outre, on suppose que le TPE 2 a été correctement initialisé, de sorte que de manière préférée il stocke également lesdites informations d’identification du marchand, et de manière classique la requête peut inclure ces informations (par exemple, tout reçu émis par un TPE suite à une transaction comprend le numéro du contrat commerçant utilisé pour la transaction). En réponse, le serveur 3 transmet un jeton d’authentification (à nouveau par exemple une donnée à usage unique tel qu’un nonce, avantageusement générée aléatoirement). Selon une première variante, correspondant à la FIG. 4 , le jeton d’authentification est transmis au TPE 2 à l’étape (b). En d’autre termes, le serveur 3 se contente de répondre à la requête d’autorisation. Alors, dans une étape (c), on souhaite que le serveur 3 se voie renvoyer le jeton, mais de la part du terminal 1, de sorte à prouver le consentement du marchand. Pour ce faire, dans l’étape (c) un message contenant le jeton d’authentification est transmis préalable du terminal de paiement électronique 2 au terminal mobile 1 via un canal de communication de proximité (qui n’est pas forcément le même que le canal utilisé pour l’éventuelle initialisation). Par « canal de communication de proximité » on rappelle qu’on entend un canal de communication à courte portée qui tire parti du fait que le marchand doit être présent et même accéder au TPE 2 pour confirmer qu’il veut réellement mettre en œuvre cette transaction (de la même manière qu’il le ferait en utilisant sa carte DOM), avantageusement rien ne passant via le réseau 20 (bien que chacun des terminaux 1 et 2 soit de son côté connecté au réseau 20). De manière préférée, ledit canal de communication de proximité est un canal sans fil en particulier choisi parmi un canal optique et un canal radio en champ proche, mais ce pourrait être par exemple simplement un canal filaire (en connectant les terminaux 1 et 2 par un câble). Dans le mode de réalisation « canal optique », ledit message prend la forme d’un signal visuel, en particulier un code barre 2D, et en particulier un QR code émis par le TPE 2 (affiché par un écran) et capté par une caméra du terminal mobile 1. Plus précisément, le code barre 2D s’affiche et le marchand est invité à le scanner avec son terminal 1. Dans le mode de réalisation « canal radio en champ proche », le message prend la forme d’un signal radio, en particulier un signal NFC (mais ce pourrait par exemple alternativement être du Bluetooth, etc.), transféré entre les terminaux 1 et 2 en les mettant l’un contre l’autre. Alors, le terminal mobile 1 extrait du message transmis via le canal de communication de proximité ledit jeton d’authentification et le retransmet au serveur 3 comme expliqué. Le jeton peut tout à fait être encodé, signé, etc., et donc ne pas être renvoyé tel quel. A noter que si une application dédiée a été installée (à l’étape (a0) ou plus tard), ces actions peuvent être mises en œuvre par ladite application, de manière transparente pour l’utilisateur. Selon un mode de réalisation préféré, au moins un paramètre contextuel du terminal mobile 1 est également transmis (par le terminal 1) à l’étape (c) avec le jeton. Par paramètre contextuel, on entend un paramètre représentatif du contexte dans lequel se trouve le terminal, en particulier un paramètre de géolocalisation (coordonnées GPS, identification d’un point d’accès Wifi) ou un paramètre temporel (horodatage), etc. Comme l’on verra, ce ou ces paramètres contextuels pourront être vérifiés pour détecter des cas de fraude. Alors, dans une étape (d), le serveur 3 vérifie que le jeton d’authentification reçu depuis le terminal de paiement électronique 2 coïncide avec le jeton d’authentification transmis au terminal mobile 1. Cette étape peut le cas échéant comprendre le traitement du jeton reçu, si par exemple il a été encodé, d’où le terme « coïncide » qui doit être pris au sens large : on couvrira également le cas d’un challenge/response (la « réponse » fournie par le terminal 1 doit coïncider avec le « challenge » qui le jeton d’authentification initialement envoyé au TPE 2). En effet, si le même jeton est renvoyé, ou du moins un jeton attendu, cela prouve bien au serveur 3 que la communication de proximité a eu lieu correctement. Si au contraire, un jeton différent est reçu, c’est qu’on en manifestement en présence d’une tentative de fraude. De manière préférée, le procédé comprend en outre la vérification que ledit terminal mobile 1 depuis lequel le jeton d’authentification est reçu est bien celui associé auxdites informations d’identification du marchand, i.e. que ce terminal 1 et lesdites informations d’identification du marchand du TPE 2 depuis lequel la requête d’autorisation est reçue sont bien associés dans la base du serveur 3. En effet, on sait depuis quel TPE la requête a été reçue à l’étape (a), cette requête contenant typiquement lesdites informations d’identification du marchand (identifiant de contrat commerçant), et depuis quel terminal mobile 1 a été reçu le jeton d’authentification (identifiant tel que numéro de téléphone). On vérifie que ce terminal 1 est bien celui attendu, i.e. celui associé auxdites informations d’identification du marchand. Cela permet d’évite un autre scénario de fraude dans lequel un tiers tenterait d’utiliser son propre terminal pour valider sans le consentement du marchand la transaction. Enfin, si un paramètre contextuel a été envoyé, il est vérifié. Cela peut se faire par exemple en le comparant avec des attributs associés également auxdites informations d’identifiant du marchand (voir avant). Par exemple, on peut avoir une localisation attendue, qu’on compare avec la localisation du terminal 1 : si les deux sont éloignées, c’est que le terminal 1 n’est pas à proximité du TPE 2 et que l’on est dans une situation frauduleuse. Si les vérifications sont accomplies (si le jeton d’authentification reçu depuis le terminal mobile 1 coïncide avec le jeton d’authentification transmis au terminal de paiement électronique 2, et avantageusement si ledit terminal mobile 1 depuis lequel le jeton d’authentification est reçu est bien celui associé auxdites informations d’identification du marchand), alors le serveur 3 transmet au terminal de paiement électronique 2 une autorisation de mise en œuvre de ladite transaction. Ce peut être une simple notification interprétable par le TPE 2, ou bien un message comprenant lesdites informations d’identification du marchand encodées de sorte à simuler la carte de domiciliation bancaire (par exemple conformément à la piste ISO2). Dans ce dernier cas, le TPE 2 croit que la carte DOM est présentée. Dans les deux cas cela permet au TPE 2, dans une étape (e), de mettre en œuvre ladite transaction. A ce titre, le TPE peut procéder de manière classique et transmettre les données descriptives de la transaction à un serveur bancaire adéquat. Alternativement, si la vérification échoue, alors aucune autorisation n’est transmise au TPE 2, et potentiellement une notification de refus est transmise à la place, de sorte que la transaction est rejetée par le TPE2. Dans tous les cas, les moyens de stockage de données 32 du serveur 3 peuvent stocker un historique des requêtes d’autorisation de transaction du TPE 2, avec le résultat, notamment consultable depuis ladite application dédiée sur le terminal 1. Selon une deuxième variante, correspondant à la FIG. 4 , le jeton d’authentification transite dans le sens inverse. Le jeton est ainsi transmis (depuis le serveur 3) au terminal 1 du marchand à l’étape (b), plus précisément au terminal associé auxdites informations d’identification du marchand, i.e. ce terminal 1 et lesdites informations d’identification du marchand du TPE 2 depuis lequel la requête d’autorisation est reçue (cette requête contenant typiquement lesdites informations d’identification du marchand - identifiant de contrat commerçant) sont associés dans la base du serveur 3. En d’autre termes, le serveur 3 interroge la base stockée dans les moyens 32 et extrait l’identifiant du terminal 1 associé aux informations d’identification reçues. Alors, dans une étape (c), on souhaite que le serveur 3 se voie renvoyer le jeton, mais de la part du TPE 1, de sorte à prouver le consentement du marchand. Pour ce faire, dans l’étape (c) un message contenant le jeton d’authentification est transmis préalable du terminal mobile 1 au terminal de paiement électronique 2 via ledit canal de communication de proximité décrit précédemment. On inverse juste les terminaux, de sorte que dans le mode de réalisation « canal optique », ledit message prend la forme d’un signal visuel, en particulier un code barre 2D, et en particulier un QR code émis par le terminal mobile 1 2 (affiché par un écran) et capté par une caméra du TPE 2 1. Plus précisément, le code barre 2D s’affiche et le marchand est invité à le scanner avec le TPE 2. Alors, le TPE 2 extrait du message transmis via le canal de communication de proximité ledit jeton d’authentification et le retransmet au serveur 3 comme expliqué. Selon un mode de réalisation préféré, au moins un paramètre contextuel du terminal mobile 1 est également transmis (par le terminal 1) soit directement au serveur 3, soit dans le message via ledit canal de communication de proximité à l’étape (c) avec le jeton. Les étapes (d) et (e) et peuvent alors être mises en œuvre de manière identique à la première variante (vérification que le jeton d’authentification reçu depuis le terminal de paiement électronique 2 coïncide avec le jeton d’authentification transmis au terminal mobile 1). A noter qu’il n’y a pas besoin de deuxième vérification puisque l’on est déjà sûr que le jeton a été envoyé au bon terminal 1. En effet, dans cette seconde variante il est de base impossible qu’un individu reçoive frauduleusement le jeton sur un terminal non autorisé. Terminaux secondaires Selon un mode de réalisation préféré, le procédé peut comprendre une étape (a1) de réception par le serveur 3 depuis le terminal 1 d’une requête d’enregistrement d’un terminal secondaire, comprenant un identifiant du terminal mobile secondaire à associer sur les moyens de stockage de données 32 du serveur 3 auxdites informations d’identification du marchand. Il s’agit d’une requête visant à donner audit terminal secondaire le droit d’utiliser également la carte eDOM, il s’agit donc d’une délégation de droits. Par terminal secondaire, on entend un autre terminal mobile que le terminal 1, ce dernier constituant un terminal « principal ». Les terminaux secondaires ceux typiquement ceux d’employés du marchand, qui peuvent eux-mêmes être amenés à devoir mettre en œuvre une transaction nécessitant la carte DOM, et donc en théorie le terminal 1 du marchand si l’on n’a plus de carte DOM physique. L’idée est qu’ils soient autonomes. Cette étape (a1) peut être mise en œuvre n’importe quand après l’onboarding de l’étape (a0). De manière préférée, l’étape (a1) est mise en œuvre de manière similaire au procédé objet de l’invention : avec la transmission préalable d’un message, entre le terminal mobile 1 et ledit terminal secondaire, via le canal de communication de proximité. Cela permet de prouver la proximité des deux terminaux et le consentement du marchand. Par exemple suite à la requête d’enregistrement d’un terminal secondaire, le serveur 3 envoie un jeton d’authentification au terminal principal ou au terminal secondaire, jeton devant être transféré à l’autre terminal via le canal de communication de proximité (par exemple QR code) et envoyé au serveur 3 de manière similaire à l’étape (c). Comme dans l’étape (d), si le jeton d’authentification reçu depuis l’un du terminal principal et du terminal secondaire coïncide avec le jeton d’authentification transmis à l’autre du terminal principal et du terminal secondaire, on considère que le consentement du marchand est acquis et la requête d’enregistrement est acceptée : comme dans l’étape (a0) l’identifiant du terminal secondaire est ainsi associé sur les moyens de stockage de données 32 du serveur 3 auxdites informations d’identification du marchand (ces informations deviennent alors associées à la fois au terminal principal et au terminal secondaire). On peut également se passer de jeton, avec le terminal principal ou le terminal secondaire envoyant directement à l’autre un message contenant son identifiant (numéro de téléphone) via le canal de communication de proximité. Ce mode de réalisation est très pratique, car ledit historique des requêtes d’autorisation de transaction du TPE 2 comprend de manière préférée l’identifiant du terminal à l’origine de la requête. Ainsi, si un terminal secondaire enregistré (et ayant donc le droit d’utiliser la carte eDOM) met en œuvre une opération frauduleuse, le marchand le saura puisque l’historique, consultable depuis ladite application dédiée sur le terminal 1, mentionnera cette opération et le terminal à l’origine. A noter qu’on peut prévoir que les terminaux secondaires permettent eux-mêmes d’enregistrer d’autres terminaux secondaires, ou alternativement seulement le terminal principal. Serveur et terminaux Selon un deuxième aspect, l’invention concerne le serveur 3 pour la mise en œuvre du procédé selon le premier aspect, i.e. un serveur de gestion de cartes de domiciliation bancaire dématérialisées. Ainsi, ce serveur 3 comprend comme expliqué au moins des moyens de traitement de données 31 et une mémoire 32. Il est connecté via le réseau 20 au TPE 2 d’un marchand et au terminal mobile 1 du marchand. On suppose que le marchand est en droit de disposer d’une carte DOM stockant des informations d’identification du marchand (i.e. il a souscrit un contrat commerçant – il peut en pratique ne pas demander de carte DOM physique). A ce titre, les moyens de stockage de données 32 stockent lesdites informations d’identification du marchand associées audit terminal mobile 1. Les moyens de traitement de données 31 sont configurés pour mettre en œuvre des étapes consistant à : Recevoir, depuis le terminal de paiement électronique 2, une requête d’autorisation d’une transaction nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre à l’un du terminal de paiement électronique 2 et du terminal mobile 1 un jeton d’authentification Recevoir, depuis l’autre du terminal de paiement électronique 2 et du terminal mobile 1, ledit jeton d’authentification, un message contenant ledit jeton d’authentification ayant préalablement été transféré entre le terminal de paiement électronique 2 et le terminal mobile 1, via un canal de communication de proximité ; Si le jeton d’authentification transmis à l’un du terminal de paiement électronique 2 et du terminal mobile 1 coïncide avec le jeton d’authentification reçu depuis l’autre du terminal de paiement électronique 2 et du terminal mobile 1 (et préférentiellement, dans le cas où le jeton d’authentification est reçu depuis le terminal 1, ce jeton est bien celui associé auxdites informations d’identification du marchand), transmettre au terminal de paiement électronique 2 une autorisation de mise en œuvre de ladite transaction. Selon un troisième aspect, l’invention propose un ensemble comprenant le serveur 3 selon le deuxième aspect, ledit terminal mobile 1 et ledit terminal de paiement électronique 2. On peut naturellement avoir plusieurs terminaux 1, le cas échéant principal ou secondaire, et plusieurs TPE 2. Ces terminaux 1, 2 comprennent également comme expliqué au moins des moyens de traitement de données 11, 21 et une mémoire 12, 22, et avantageusement une caméra et/ou des moyens d’affichage et/ou des moyens de communication en champ proche, potentiellement en outre un lecteur de carte. Les moyens de traitement de données 11, 21 sont configurés pour transmettre le message contenant ledit jeton d’authentification, entre le terminal de paiement électronique 2 et le terminal mobile 1, via ledit canal de communication de proximité. Produit programme d’ordinateur Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 31 au moins le serveur 3, et potentiellement également les moyens de traitement de donnés 11, 21 des terminaux 1 et 2) d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique 2 d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand ; ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 32 d’au moins le serveur 3, et potentiellement le moyens de stockage de données 12, 22 des terminaux 1 et 2) sur lequel on trouve ce produit programme d’ordinateur. Procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (31) d’un serveur (3) comprenant des moyens de stockage de données (32) stockant lesdites informations d’identification du marchand associées à un terminal mobile (1) du marchand, et connecté via un réseau de communication (20) audit terminal de paiement électronique (2) et au terminal mobile (1), d’étapes de : Réception, depuis le terminal de paiement électronique (2), d’une requête d’autorisation de ladite transaction ; Transmission au terminal de paiement électronique (2) d’un jeton d’authentification ; Réception, depuis le terminal mobile (1) dudit jeton d’authentification ; Si le jeton d’authentification reçu depuis le terminal mobile (1) coïncide avec le jeton d’authentification transmis au terminal de paiement électronique (2), transmission au terminal de paiement électronique (2) d’une autorisation de mise en œuvre de ladite transaction ; Dans lequel l’étape (c) comprend la transmission préalable d’un message contenant ledit jeton d’authentification, du terminal de paiement électronique (2) au terminal mobile (1), via un canal de communication de proximité. Procédé selon la revendication 1, dans lequel l’autorisation n’est transmise à l’étape (d) que si ledit terminal mobile (1) depuis lequel le jeton d’authentification est reçu est bien celui associé auxdites informations d’identification du marchand. Procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (31) d’un serveur (3) comprenant des moyens de stockage de données (32) stockant lesdites informations d’identification du marchand associées de manière unique à un terminal mobile (1) du marchand, et connecté via un réseau de communication (20) audit terminal de paiement électronique (2) et au terminal mobile (1), d’étapes de : Réception, depuis le terminal de paiement électronique (2), d’une requête d’autorisation de ladite transaction ; Transmission au terminal mobile (1) d’un jeton d’authentification ; Réception, depuis le terminal de paiement électronique (2) dudit jeton d’authentification ; Si le jeton d’authentification reçu depuis le terminal de paiement électronique (2) coïncide avec le jeton d’authentification transmis au terminal mobile (1), transmission au terminal de paiement électronique (2) d’une autorisation de mise en œuvre de ladite transaction ; Dans lequel l’étape (c) comprend la transmission préalable d’un message contenant ledit jeton d’authentification, du terminal mobile (1) au terminal de paiement électronique (2), via un canal de communication de proximité. Procédé selon l’une des revendications 1 à 3, dans lequel ladite autorisation de mise en œuvre de ladite transaction transmise à l’étape (d) comprend lesdites informations d’identification du marchand encodées de sorte à simuler la carte de domiciliation bancaire. Procédé selon l’une des revendications 1 à 4, comprenant une étape (e) de mise en œuvre de ladite transaction par le terminal de paiement électronique (2). Procédé selon l’une des revendications 1 à 5, comprend une étape préalable (a0) de réception par le serveur (3) d’une requête de dématérialisation de la carte de domiciliation bancaire, comprenant lesdites informations d’identification du marchand et un identifiant du terminal mobile (1) à associer sur les moyens de stockage de données (32) du serveur (3) auxdites informations d’identification du marchand. Procédé selon la revendication 6, dans lequel l’étape (a0) comprend la transmission au terminal mobile (1) d’une requête de vérification dudit identifiant du terminal mobile (1). Procédé selon la revendication 7, dans lequel ladite requête de vérification dudit identifiant du terminal mobile (1) entraîne l’ouverture d’une application dédiée si elle est déjà installée, et sinon son téléchargement depuis le réseau (20) puis son installation, ladite application étant configurée pour répondre à l’étape (a0) à ladite requête de vérification dudit identifiant du terminal mobile (1), et à extraire à l’étape (c) du message transmis via le canal de communication de proximité ledit jeton d’authentification et le retransmettre au serveur (3). Procédé selon l’une des revendications 1 à 8, comprenant une étape (a1) de réception par le serveur (3) depuis le terminal (1) d’une requête d’enregistrement d’un terminal secondaire, comprenant un identifiant du terminal mobile secondaire à associer sur les moyens de stockage de données (32) du serveur (3) auxdites informations d’identification du marchand. Procédé selon la revendication 9, dans lequel l’étape (a1) comprend la transmission préalable d’un message, entre le terminal mobile (1) et ledit terminal secondaire, via le canal de communication de proximité. Procédé selon l’une des revendications 1 à 10, dans lequel ladite transaction est soit une transaction de crédit, soit une annulation d’une transaction mise en œuvre antérieurement sur le terminal de paiement électronique (2). Procédé selon l’une des revendications 1 à 11, dans lequel ledit canal de communication de proximité entre le terminal mobile (1) et le terminal de paiement électronique (2) n’est pas via le réseau (20). Procédé selon la revendication 12, dans lequel ledit canal de communication de proximité entre le terminal mobile (1) et le terminal de paiement électronique (2) est un canal optique ou un canal radio en champ proche. Procédé selon l’une des revendication 1 à 13, dans lequel l’étape (c) comprend en outre la réception d’au moins un paramètre contextuel du terminal mobile (1), l’étape (d) comprenant en outre la vérification dudit paramètre contextuel reçu. Serveur (3) de gestion de cartes de domiciliation bancaire dématérialisées, connecté via un réseau (20) à un terminal de paiement électronique (2) d’un marchand et un terminal mobile (1) du marchand, caractérisé en ce qu’il comprend des moyens de stockage de données (32) stockant des informations d’identification du marchand associées audit terminal mobile (1), et des moyens de traitement de données (31) configurés pour : Recevoir, depuis le terminal de paiement électronique (2), une requête d’autorisation d’une transaction nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre à l’un du terminal de paiement électronique (2) et du terminal mobile (1) un jeton d’authentification Recevoir, depuis l’autre du terminal de paiement électronique (2) et du terminal mobile (1), ledit jeton d’authentification, un message contenant ledit jeton d’authentification ayant préalablement été transféré entre le terminal de paiement électronique (2) et le terminal mobile (1), via un canal de communication de proximité ; Si le jeton d’authentification transmis à l’un du terminal de paiement électronique (2) et du terminal mobile (1) coïncide avec le jeton d’authentification reçu depuis l’autre du terminal de paiement électronique (2) et du terminal mobile (1), transmettre au terminal de paiement électronique (2) une autorisation de mise en œuvre de ladite transaction. Ensemble du serveur (3) selon la revendication 15, dudit terminal mobile (1) et dudit terminal de paiement électronique (2), le terminal mobile (1) et le terminal de paiement électroniques (2) comprenant des moyens de traitement de données (11, 21) configurés pour transmettre le message contenant ledit jeton d’authentification, entre le terminal de paiement électronique (2) et le terminal mobile (1), via ledit canal de communication de proximité. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 14 pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 14 pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand.