Brevet FR3160491A1 — publié le 20250926

La présente invention concerne un procédé d’initialisation d’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 d’étapes de : Réception par 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’une requête d’initialisation du terminal de paiement électronique (2) ; Transmission au terminal mobile (1) des données nécessaires à l’initialisation dudit terminal de paiement électronique (2) ; Transmission d’un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique (2), du terminal mobile (1) au terminal de paiement électronique (2), via un canal de communication de proximité Mise en œuvre de l’initialisation dudit terminal de paiement électronique (2) en utilisant les données reçues. [Fig. 1] Procédé pour l’initialisation d’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 l’initialisation d’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 un premier aspect à un procédé d’initialisation d’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 d’étapes de : Réception par 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’une requête d’initialisation du terminal de paiement électronique ; Transmission au terminal mobile des données nécessaires à l’initialisation dudit terminal de paiement électronique ; Transmission d’un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique, du terminal mobile au terminal de paiement électronique, via un canal de communication de proximité Mise en œuvre de l’initialisation dudit terminal de paiement électronique en utilisant les données reçues. Selon des caractéristiques avantageuses et non-limitatives : Lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique comprennent lesdites informations d’identification dudit marchand. La requête d’initialisation du terminal de paiement électronique est reçue depuis le terminal mobile, les informations d’identification dudit marchand transmises à l’étape (b) sont celles associées audit terminal mobile depuis lequel la requête d’initialisation du terminal de paiement électronique est reçue. Lesdites informations d’identification dudit marchand sont relatives à plusieurs contrats commerçants du marchand. Lesdites données transmises à l’étape (b) comprennent les informations d’identification du marchand relatives à tous lesdits contrats commerçants du marchand. L’étape (c) comprend la sélection préalable par le marchand sur le terminal mobile d’au moins un contrat conformément auquel il souhaite initialiser le terminal de paiement électronique. Lesdites données transmises à l’étape (d) comprennent seulement les informations d’identification du marchand relatives aux contrats commerçants du marchand sélectionnés. 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 est 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é. 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. Selon un deuxième aspect, est proposé 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, comprenant la mise en œuvre du procédé d’initialisation du terminal de paiement électronique le premier aspect. Selon un troisième aspect, l’invention concerne un ensemble d’un serveur de gestion de cartes de domiciliation bancaire dématérialisées, d’un terminal de paiement électronique d’un marchand et d’un terminal mobile du marchand, connectés via un réseau, caractérisé en ce que : le serveur 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 une requête d’initialisation du terminal de paiement électronique nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre au terminal mobile des données nécessaires à l’initialisation dudit terminal de paiement électronique ; Le terminal mobile et le terminal de paiement électronique comprennent des moyens de traitement de données configurés pour : Transmettre un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique, du terminal mobile au terminal de paiement électronique, via un canal de communication de proximité ; Mettre en œuvre l’initialisation dudit terminal de paiement électronique en utilisant les données reçues. 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 d’initialisation d’un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, ou un procédé selon le deuxième 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 d’initialisation d’un terminal de paiement électronique d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, ou 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. 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é d’initialisation selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé d’initialisation selon l’invention ; FIG. 3 la FIG. 3 représente des exemples d’interfaces lors de la mise en œuvre du procédé d’initialisation selon l’invention ; FIG. 4 la FIG. 4 est un logigramme illustrant les étapes d’un premier mode de réalisation d’un procédé pour mettre en œuvre une transaction ; FIG. 4 la FIG. 4 est un logigramme illustrant les étapes d’un deuxième mode de réalisation d’un procédé pour mettre en œuvre une transaction. DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne un procédé d’initialisation d’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 . Par « initialisation » du TPE 2, on entend sa configuration de sorte à permettre la mise en œuvre ultérieure de transactions entre le marchand possesseur du TPE 2, et un individu typiquement client du marchand. De manière classique, l’initialisation 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 de ladite initialisation 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, l’initialisation et 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). A noter qu’il faut utiliser la carte DOM relative au bon contrat commerçant, et ainsi en cas de souscription à une pluralité de contrat il faut mettre en œuvre autant d’initialisations avec une carte DOM. A noter qu’il est en outre tout à fait possible que le marchand ait plusieurs TPE partageant lesdits contrats (et donc qu’on peut chacun initialiser 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 une initialisation nécessitant une carte DOM sans la carte physique, en utilisant à la place un terminal mobile 1 du marchand. Pour reformuler, la présente initialisation pourra être mise en œuvre sans physiquement manipuler la carte DOM (pas de lecture de bande magnétique), mais l’initialisation 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 de l’initialisation 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 En référence à la FIG. 2 , qui représentent un mode de réalisation préféré, le présent procédé commence, en ce qui concerne l’initialisation à proprement parler, 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 le numéro 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, le présent procédé 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) 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 relative aux contrats sélectionnés, i.e. les identifiants 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 Aujourd’hui, outre l’initialisation, les transactions concernées par la nécessité d’une carte DOM 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 de manière préférée, l’invention propose en outre un procédé pour la mise en œuvre d’une transaction, sur le TPE 2 du marchand (déjà initialisé), nécessitant également ladite carte DOM stockant des informations d’identification dudit marchand, faisant suite au présent procédé d’initialisation. En référence aux figures 4a et 4b , qui représentent deux modes alternatifs, cet autre 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 rappelle que le TPE 2 a été correctement initialisé, de sorte qu’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’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 TPE 2. 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 (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 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 initialisation 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 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 troisième aspect, l’invention concerne l’ensemble d’un serveur 3 de gestion de cartes de domiciliation bancaire dématérialisées, d’un terminal de paiement électronique 2 d’un marchand et d’un terminal mobile 1 du marchand, connectés via un réseau 20, pour la mise en œuvre du procédé selon le premier aspect (et le cas échéant du procédé pour la mise en œuvre d’une transaction selon le deuxième aspect). Ainsi, ce serveur 3 et ces terminaux 1 et 2 comprennent comme expliqué respectivement au moins des moyens de traitement de données 31, 11, 21 et une mémoire 32, 12, 22, et les deux derniers avantageusement une caméra et/ou des moyens d’affichage et/ou des moyens de communication en champ proche. 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 du serveur 3 sont configurés pour mettre en œuvre des étapes consistant à : Recevoir une requête d’initialisation du terminal de paiement électronique 2 nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre au terminal mobile 1 des données nécessaires à l’initialisation dudit terminal de paiement électronique 2. Les moyens de traitement de données 11, 21 du terminal mobile 1 et du terminal de paiement électronique 2 sont configurés pour mettre en œuvre l’étape consistant à transmettre un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique 2, du terminal mobile 1 au terminal de paiement électronique 2, via un canal de communication de proximité. Les moyens de traitement de données 21 du terminal de paiement électronique 2 sont configurés pour mettre en œuvre l’étape consistant à mettre en œuvre l’initialisation dudit terminal de paiement électronique 2 en utilisant les données reçues (extraites dudit message transmis via ledit canal de canal de communication de proximité depuis le terminal 1). Produit programme d’ordinateur Selon un quatrième et un cinquiè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 11, 21, 31 des terminaux 1 et 2, et du serveur 3) d’un procédé selon le premier aspect d’initialisation d’un terminal de paiement électronique 2 d’un marchand ou d’un procédé un procédé selon le deuxième aspect pour la mise en œuvre d’une transaction, sur le terminal de paiement électronique d’un marchand, chacun 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 12, 22, 32 des terminaux 1 et 2, et du serveur 3) sur lequel on trouve ce produit programme d’ordinateur. Procédé d’initialisation d’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 d’étapes de : Réception par 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’une requête d’initialisation du terminal de paiement électronique (2) ; Transmission au terminal mobile (1) des données nécessaires à l’initialisation dudit terminal de paiement électronique (2) ; Transmission d’un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique (2), du terminal mobile (1) au terminal de paiement électronique (2), via un canal de communication de proximité Mise en œuvre de l’initialisation dudit terminal de paiement électronique (2) en utilisant les données reçues. Procédé selon la revendication 1, dans lequel lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique (2) comprennent lesdites informations d’identification dudit marchand. Procédé selon la revendication 2, dans lequel la requête d’initialisation du terminal de paiement électronique (2) est reçue depuis le terminal mobile (1), les informations d’identification dudit marchand transmises à l’étape (b) sont celles associées audit terminal mobile (1) depuis lequel la requête d’initialisation du terminal de paiement électronique (2) est reçue. Procédé selon l’une des revendications 2 et 3, dans lequel lesdites informations d’identification dudit marchand sont relatives à plusieurs contrats commerçants du marchand ; lesdites données transmises à l’étape (b) comprenant les informations d’identification du marchand relatives à tous lesdits contrats commerçants du marchand ; l’étape (c) comprenant la sélection préalable par le marchand sur le terminal mobile (1) d’au moins un contrat conformément auquel il souhaite initialiser le terminal de paiement électronique (2) ; et lesdites données transmises à l’étape (d) comprenant seulement les informations d’identification du marchand relatives aux contrats commerçants du marchand sélectionnés. Procédé selon l’une des revendications 1 à 4, 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 5, 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 6, 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 à 7, 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 8, 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 à 9, 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 10, 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é 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, comprenant la mise en œuvre du procédé d’initialisation du terminal de paiement électronique (2) selon l’une des revendications 1 à 11. Ensemble d’un serveur (3) de gestion de cartes de domiciliation bancaire dématérialisées, d’un terminal de paiement électronique (2) d’un marchand et d’un terminal mobile (1) du marchand, connectés via un réseau (20), caractérisé en ce que : le serveur (3) 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 une requête d’initialisation du terminal de paiement électronique (2) nécessitant une carte de domiciliation bancaire stockant lesdites informations d’identification dudit marchand ; Transmettre au terminal mobile (1) des données nécessaires à l’initialisation dudit terminal de paiement électronique (2) ; Le terminal mobile (1) et le terminal de paiement électronique (2) comprennent des moyens de traitement de données (11, 21) configurés pour : Transmettre un message contenant lesdites données nécessaires à l’initialisation dudit terminal de paiement électronique (2), du terminal mobile (1) au terminal de paiement électronique (2), via un canal de communication de proximité ; Mettre en œuvre l’initialisation dudit terminal de paiement électronique (2) en utilisant les données reçues. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 d’initialisation d’un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, ou un procédé selon la revendication 12 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 à 11 d’initialisation d’un terminal de paiement électronique (2) d’un marchand, nécessitant une carte de domiciliation bancaire stockant des informations d’identification dudit marchand, ou un procédé selon la revendication 12 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.