FR 3074946 A1 20190614 FR 1761891 A 20171211 METHODES ET SYSTEMES DE TRANSACTION ELECTRONIQUE [1] L'invention a trait au domaine des réseaux électroniques, et plus particulièrement aux infrastructures de transaction électronique. [2] L'invention trouve notamment utilisation dans les infrastructures de paiement électronique. [3] On entend ici par infrastructure de paiement électronique l'ensemble des moyens techniques permettant la réalisation d'opérations de paiement électronique. [4] Le règlement de telles opérations fait intervenir plusieurs éléments, dont un support de transaction, généralement sous la forme d'une carte de paiement ou d'une application mobile mise à disposition d'un porteur par un organisme financier dit « l'émetteur ». Cet émetteur tient, le plus souvent, le compte bancaire auquel est rattaché le support de transaction et sur lequel seront prélevés les débits correspondants aux paiements effectués au moyen de ce support de transaction ; une infrastructure de paiement électronique de l'émetteur, comprenant des moyens configurés pour autoriser ou refuser un paiement électronique utilisant ledit support de transaction, et des moyens configurés pour débiter le compte auquel est rattaché le support de transaction conformément à des règles de fonctionnement prédéfinies ; un moyen d'acceptation, tel qu'un terminal de paiement électronique plus connu sous l'acronyme TPE, ou aussi par POI, (pour « Point of Interaction » désignant un terminal de paiement quel qu'il soit), mis à la disposition de l'accepteur du support de transaction. Un TPE permet l'acceptation d'un moyen de paiement en vue de la réalisation d'un paiement, et permet de lire des données sur le support de transaction et de communiquer à distance avec une ou plusieurs infrastructures de paiement électronique appartenant à des organismes financiers, chacun de ces organismes étant dit « acquéreur » auprès desquels l'accepteur possède un compte bancaire. Un acquéreur assure l'acquisition des transactions de paiement électronique, en vue de leur dénouement financier auprès de l'émetteur, pour le 2 compte de l'accepteur. Les opérations de configuration ou de mises à jour de ce TPE sont traitées par un des acquéreurs ou, le plus souvent, par un mainteneur ; une infrastructure de paiement électronique d'au moins un 5 acquéreur, comprenant des moyens configurés pour créditer le compte bancaire de l'accepteur par un montant correspondant au règlement d'une transaction qui lui a été communiquée par le TPE ; et le cas échéant un réseau interbancaire, comprenant une chambre de 10 compensation et auquel sont connectés le réseau monétique de l'émetteur et le réseau monétique de l'acquéreur. [5] Le déroulement schématique d'un paiement électronique faisant intervenir les éléments cités ci-dessus est illustré à la figure 1. [6] Dans un tel mode de paiement, suite à la communication des 15 références d'une transaction (choix d'un acquéreur, lorsque plusieurs y sont configurés, et un montant de la transaction à payer), à un TPE 21 mis à disposition par exemple d'un commerçant 20, l'insertion de la carte bancaire 11 dans ce TPE 21 ouvre une session, qui commence par une étape d'authentification mutuelle entre le TPE 21 et la carte 20 bancaire 11. [7] Le TPE 21 et la carte bancaire 11 échangent (étape 1) des informations, pour s'assurer que la carte bancaire 11 est valide et que le TPE 21 est un lecteur autorisé. [8] Lors de cette étape 1, il peut également y avoir une 25 authentification du porteur 10 de la carte bancaire 11, en l'invitant à saisir un code PIN ou toute autre information permettant de vérifier qu'il en est le porteur légal. [9] Au succès de l'étape précédente, le TPE 21 envoie (étape 2) une demande d'autorisation, à destination d'un serveur d'autorisation 31 de 30 l'infrastructure de paiement électronique de l'acquéreur 30. [10] Sur réception de cette demande d'autorisation, le serveur d'autorisation 31 de l'acquéreur 30 réalise certains contrôles, comme l'identification du TPE 21 source de la demande et de l'émetteur 40 de la carte bancaire 11 et, ensuite, transfère (étape 3) cette demande 35 d'autorisation à un serveur d'autorisation 41 de l'infrastructure de paiement électronique de l'émetteur 40 identifié. [11] Le serveur d'autorisation 41 de l'émetteur 40 effectue, à son tour, 3 des contrôles monétiques, pour déterminer s'il faut autoriser ou refuser cette transaction. [12] Ces vérifications comprennent, entre autres, l'authentification de la carte 11, le contrôle du solde du compte associé à la carte bancaire 5 11, et le contrôle des plafonds autorisés. [13] La réponse du serveur d'autorisation 41 de l'infrastructure de paiement électronique de l'émetteur 40 emprunte en sens inverse le même chemin que la demande d'autorisation, et est donc rendue (étape 4) au serveur d'autorisation 31 de l'acquéreur 30 qui la renvoie (étape 10 5) au TPE 20 telle quelle ou, dans certains cas, modifiée, en application d'une politique de risque acquéreur qui lui est propre. [14] La réponse à la demande d'autorisation comprend un code réponse indiquant au TPE 21 s'il convient d'accepter ou refuser la transaction de paiement électronique. 15 [015] Le TPE 21 en informe (étape 6) le porteur 10 (transaction refusée ou acceptée), en éditant un ticket de carte bancaire (preuve de l'échec ou de la réussite de la transaction) et ferme la session. [016] Lorsque la transaction de paiement électronique est autorisée, le TPE 21 mémorise en local cette transaction. 20 [017] Sur demande de l'accepteur 20 ou à des temps prédéfinis, le TPE 21 transmet (étape 7) à un serveur 32 de télécollecte de l'infrastructure de paiement électronique de l'acquéreur 30 l'ensemble des transactions de paiement électronique mémorisées, pour que le compte bancaire de l'accepteur 20 soit crédité des montants correspondants. 25 [018] Les transactions remises par le TPE 21 à l'acquéreur 30 sont, par la suite, supprimées de la mémoire du TPE 21. [019] Lorsque l'accepteur 20 dispose de plusieurs points de vente et, par conséquent, de plusieurs TPE 21, la télécollecte peut se faire en un premier temps vers une base de données intermédiaire. 30 [020] Une fois toutes les transactions centralisées, la télécollecte est ensuite effectuée vers le serveur 32 de télécollecte de l'infrastructure de paiement électronique de l'acquéreur 30. [021] Le serveur 32 de télécollecte de l'acquéreur 30 est, en outre, configuré pour centraliser l'ensemble des transactions de paiement 35 électronique remises par les autres accepteurs adhérents, respectivement, détenant un compte bancaire auprès de cet acquéreur 30. 4 [22] En centralisant l'ensemble des transactions de paiement électronique réalisées pour le compte des différents accepteurs, l'acquéreur 30 procède à un traitement de flux. [23] Ce traitement massif et uniforme porte sur l'ensemble des 5 transactions. [24] Ce traitement consiste principalement en une mise en forme de l'ensemble des transactions sous un format de fichier convenable aux émetteurs 40. [25] Pour cela, les acquéreurs ont souvent recours à des méthodes de 10 traitement de transactions en masse, tout comme dans les industries de traitement de l'information. [26] La principale motivation sous-jacente à cette massification des flux réside dans la réduction des coûts, vu notamment le nombre grandissant des paiements électroniques, grâce à l'augmentation du 15 nombre des porteurs des cartes bancaires et à la multiplication et la dispersion des moyens d'acceptation. [27] Suite au traitement massif des flux de l'ensemble des transactions provenant des différends accepteurs adhérents, les fichiers qui en résulte sont communiqués (étape 8) à une chambre 50 de 20 compensation. [28] Cette chambre 50 de compensation se charge de l'équilibre des débits et crédits globaux entre l'acquéreur 30 et les émetteurs 40. [29] L'acquéreur 30, qui a déjà crédité le compte bancaire de l'accepteur 20, perçoit la somme due par le porteur 10 auprès de 25 l'émetteur 40 que ce dernier prélève sur le compte du porteur 10. [30] Dans toutes ces opérations, la capacité de traiter massivement des flux d'informations de bout en bout, c'est-à-dire depuis la remise des transactions par les moyens d'acceptation jusqu'à la compensation et le règlement, est une performance essentielle des infrastructures de 30 paiement électronique. [31] De ce fait, les infrastructures de paiement électronique des organismes financiers sont souvent configurées pour une gestion massive des flux de bout en bout. [32] Ce choix est conforté par l'évolution continue des capacités des 35 équipements de traitement des flux de données (calculateurs, débits de communications, routeurs et centres de données). [33] Ce type de gestion est dans une certaine mesure bénéfique, la 5 massification des flux permettant d'optimiser les coûts, en bénéficiant d'une économie d'échelle. [34] Cependant, ce traitement qui capte le flux dans son ensemble conduit à une automatisation massive et uniforme des transactions, et 5 manque par conséquent d'agilité. [35] Aucun traitement particulier ne peut donc être destiné à une transaction cible faisant partie du flux. [36] S'agissant d'une gestion de flux de bout en bout, toutes les transactions font l'objet d'un traitement systématique, défini avant 10 même que ces transactions n'aient lieu, de sorte qu'aucun traitement spécifique ne peut être adapté à une certaine transaction une fois autorisée. [37] Il en résulte que lorsque le porteur 10 a réalisé un paiement électronique, il ne lui est plus possible d'intervenir par la suite sur cette 15 transaction, qui est destinée à faire partie d'un flux à traiter d'une manière globale et non individualisée. [38] Les méthodes de gestion actuelles des flux des paiements électroniques ne permettent pas, en effet, d'extraire une transaction du flux et encore moins d'y apporter une modification par le porteur 10 à 20 une date postérieure à la date de la transaction. [39] Plus généralement, les méthodes de gestion de flux existantes ne permettent pas d'apporter à une transaction financière un traitement particulier fixé à une date postérieure à la date de la transaction. [40] Un objet de la présente invention est de proposer des systèmes 25 et méthodes de traitement permettant une meilleure maitrise des transactions. [41] Un autre objet de la présente invention est de proposer une infrastructure de transaction électronique, permettant d'appliquer un traitement défini à une date postérieure à la date de la réalisation d'une 30 transaction faisant partie d'un flux. [42] Un autre objet de la présente invention est de proposer une nouvelle chaîne de traitement de transactions. [43] Un autre objet de la présente invention est de pouvoir paramétrer la gestion d'une transaction à une date postérieure à la date de son 35 autorisation et tant qu'elle n'a pas fait l'objet d'une compensation. [44] Un autre objet de la présente invention est d'apporter plus de souplesse aux méthodes de traitements des flux de transactions, de 6 sorte qu'elles puissent prendre en considération des modifications apportées, dans un délai prédéfini, par un demandeur à une transaction qu'il a réalisée récemment. [45] L'invention trouve diverses applications, notamment dans les 5 infrastructures de paiement électroniques. [46] Il est proposé, en premier lieu, une infrastructure de paiement électronique d'un acquéreur à laquelle est connecté au moins un moyen d'acceptation configuré pour accepter un support de transaction en vue de la réalisation d'un paiement électronique, cette infrastructure 10 comprenant : - un serveur d'autorisation configuré pour o recevoir, depuis le moyen d'acceptation, une demande d'autorisation concernant une transaction de paiement électronique au moyen d'un support de transaction, le support 15 de transaction étant émis par un émetteur ; o router la demande d'autorisation vers l'émetteur du support de transaction ; o recevoir, depuis l'émetteur du support de transaction, une réponse à la demande d'autorisation ; 20 o communiquer, au moyen d'acceptation, une réponse à la demande d'autorisation ; o générer, lorsque ce serveur d'autorisation autorise ladite transaction, un code de transaction associé à cette transaction et destiné au porteur du support de transaction, la réponse 25 communiquée au moyen d'acceptation comprenant ce code de transaction - un serveur de rétention configuré pour o recevoir, depuis le moyen d'acceptation, des informations concernant la transaction autorisée, ces informations 30 comprenant le code de transaction, o retenir les informations reçues, avant exploitation de cette transaction par l'acquéreur, pendant un délai prédéfini de rétention ; o permettre l'accès, pendant le délai prédéfini de rétention, à 35 au moins une information parmi les informations retenues sur réception d'au moins le code de transaction associé à la transaction. 7 [047] Diverses caractéristiques supplémentaires peuvent être prévues, seules ou en combinaison : - le serveur de rétention est configuré pour permettre la modification de ladite au moins une information parmi les 5 informations retenues ; - la réponse communiquée au moyen d'acceptation comprend, en outre, une adresse pointant vers le serveur de rétention ; - le serveur d'autorisation est configuré pour générer le code de transaction lorsque le montant de la transaction est supérieur à 10 un montant minimum prédéfini, et/ou lorsque la demande d'autorisation est reçue depuis un moyen d'acceptation compris dans une liste prédéfinie, et/ou l'émetteur du support de transaction est compris dans une liste prédéfinie, et/ou le support de transaction est compris dans une liste prédéfinie ; 15 - le serveur de rétention est configuré pour permettre l'accès à ladite au moins une information parmi les informations retenues sur réception du code de transaction et au moins une information concernant le support de transaction au moyen duquel a été réalisée la transaction ; 20 - le code de transaction est généré de sorte à permettre l'identification de manière unique la transaction. [048] Il est proposé, en second lieu, une procédé de traitement d'une transaction de paiement électronique entre un porteur disposant d'un support de transaction et un accepteur disposant d'un moyen 25 d'acceptation acceptant le support de transaction du porteur en vue de la réalisation d'un paiement électronique, le moyen d'acceptation étant connecté à une infrastructure de paiement électronique d'un acquéreur, le support de transaction étant émis par un émetteur, ce procédé comprenant les étapes suivantes : 30 - envoi d'une demande d'autorisation, depuis le moyen d'acceptation à un serveur d'autorisation de l'infrastructure de paiement électronique de l'acquéreur, cette demande d'autorisation concernant une transaction de paiement électronique au moyen du support de transaction, 35 - routage de la demande d'autorisation, depuis le serveur d'autorisation vers l'émetteur du support de transaction ; - réception, depuis l'émetteur du support de transaction, d'une 8 réponse à la demande d'autorisation ; - communication, au moyen d'acceptation, d'une réponse à la demande d'autorisation ; - génération par le serveur d'autorisation, lorsque ce serveur 5 d'autorisation autorise ladite transaction, d'un code de transaction associé à cette transaction et destiné au porteur du support de transaction, la réponse communiquée au moyen d'acceptation comprenant ce code de transaction ; - réception par un serveur de rétention de l'infrastructure de 10 paiement électronique de l'acquéreur et depuis le moyen d'acceptation d'informations concernant la transaction autorisée, ces informations comprenant le code de transaction ; - rétention, par le serveur de rétention, des informations reçues, pendant un délai prédéfini de rétention avant exploitation de cette 15 transaction par l'acquéreur ; - accès par le porteur, pendant le délai prédéfini de rétention, à au moins une information parmi les informations retenues sur réception par le serveur de rétention d'au moins le code de transaction associé à la transaction. 20 [049] Diverses étapes supplémentaires peuvent être prévues, seules ou en combinaison - une étape de modification de ladite au moins une information parmi les informations retenues ; - une étape d'impression du code de transaction sur le justificatif 25 de paiement et/ou une étape d'envoi par courriel ou par SMS du code de transaction à destination du porteur du support de transaction ; - une étape d'envoi, lorsque ladite au moins une information parmi les informations retenues est modifiée et concerne le support de 30 transaction, d'une demande d'autorisation par le serveur de rétention à l'émetteur du support de transaction modifié. [050] D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation, laquelle est faite en référence aux 35 dessins annexés dans lesquels : - la figure 1 illustre schématiquement des étapes d'une méthode de gestion, connue de l'état de la technique, d'une transaction de 9 paiement électronique ; la figure 2 illustre schématiquement des méthodes et systèmes pour la gestion d'une transaction de paiement électronique selon divers modes de réalisation. 5 [051] En se référant à la figure 2, il est représenté un porteur 210 disposant d'un support de transaction 211, un accepteur 220 disposant d'un moyen d'acceptation 221, un acquéreur 230 recevant les transactions acceptées par l'accepteur 220 via le moyen d'acceptation 221, et un émetteur 240 mettant à disposition du porteur 210 le support 10 de transaction 211 et étant en charge du compte associé à ce support. [52] Dans les modes de réalisations décrits, la transaction est de type paiement électronique. [53] Il est entendu toutefois que l'invention trouve application dans la modification d'une transaction électronique de tout type, commerciale, 15 boursière, ou bien encore non commerciale (par exemple transaction contractuelle, transaction de services, de temps de travail). [54] Le support de transaction 211 est tout moyen matériel et/ou logiciel permettant d'effectuer un paiement électronique tel qu'une carte de paiement (carte à piste magnétique, carte programmable, carte sans 20 contact, ou carte à puce, par exemples) ou une application de paiement installée sur un terminal utilisateur. [55] Le moyen d'acceptation 221 est tout point d'interaction (ou POI pour « Point Of Interaction ») permettant l'acceptation d'une transaction de paiement électronique tel qu'un terminal de paiement électronique 25 (TPE) ou une application de paiement en ligne intégré à un site ou une application e-commerce. [56] L'accepteur 220 est toute entité acceptant un paiement électronique telle qu'un commerçant, une machine de distribution de biens et/ou de services, ou, d'une manière générale, un point de vente 30 réel ou virtuel (un site de vente en ligne, un magasin, une boutique, une superette, un supermarché, ou un hypermarché). [57] La capacité d'acceptation du moyen d'acceptation 221 est définie par les applications de paiement qu'il comprend. [58] A titre d'exemple, un moyen d'acceptation pourvu par l'une des 35 applications EMV (« EMV®, Integrated Circuit Card Specifications for Payment Systems», Version 4.3a, Novembre 2015 https://www.emvco.com/wpcontent/uploads/2017/05/1FM Li Protocol Test Cases v43a 20151103.pdf) telles que OB®, 10 Visa®, ou MasterCard accepte, respectivement, les supports de transaction 211 de type « Cartes Bancaires » désignés par OB®, VISA®, et MASTERCARD®. [59] La sélection d'une application de paiement par le moyen 5 d'acceptation 221 résulte d'un échange entre ce moyen d'acceptation 221 et le support de transaction 211 du porteur 210. [60] Lorsque le porteur 210 initie une transaction de paiement électronique acceptée par l'accepteur 220 (en insérant sa carte dans le TPE ou en renseignant des informations concernant sa carte bancaire 10 dans un formulaire dédié, en déclenchant un paiement sans contact, ou en passant sa carte dans un lecteur de bande magnétique), le moyen d'acceptation 221 sélectionne l'application de paiement convenable et procède à des vérifications telles que spécifiées par l'application de paiement sélectionnée. 15 [061] L'application de paiement sélectionnée est ensuite initialisée. [062] Il convient de noter que la chaîne des traitements de la transaction de paiement est définie par l'application de paiement sélectionnée, dont les spécifications sont connues pour l'homme du métier. 20 [063] Suite à une vérification (étape 201) positive de la validité du support de transaction 211, et éventuellement de l'authentification du porteur 210 et d'une gestion de risques au niveau du moyen d'acceptation 221, le moyen d'acceptation 221 décide de traiter l'autorisation de la transaction en ligne (« on-line »). 25 [064] Autrement dit, avant de conclure quant à la transaction, le moyen d'acceptation 221 demande si l'émetteur 240 du support de transaction 211 accepte ou refuse la transaction en question. [65] La transaction est dite en ligne car le moyen d'acceptation 221 communique en temps réel avec l'acquéreur 230 qui se charge de 30 contacter l'émetteur 240 (émission d'une demande d'autorisation et attente de la réception d'une réponse pour conclure la transaction). [66] Pour cela, le moyen d'acceptation 221 envoie (étape 202) une demande d'autorisation au serveur d'autorisation 231 de l'acquéreur 230. 35 [067] Cette demande d'autorisation comprend le montant de la transaction et des informations concernant le support de transaction 211 (numéro, nom et prénom du porteur, identifiants du compte 11 bancaire associé par exemples). [68] Le serveur d'autorisation 231 de l'acquéreur 230 identifie le moyen d'acceptation 221 source de cette demande d'autorisation, identifie l'émetteur 240 du support de transaction 211 et se charge de 5 router (étape 203), à travers les réseaux monétiques appropriés, cette demande au serveur d'autorisation 241 de l'émetteur 240. [69] Autrement dit, l'acquéreur 230 reçoit la demande d'autorisation que l'accepteur 220 accepte et la met à disposition de l'émetteur 240 pour autorisation ou refus. 10 [070] Le serveur d'autorisation 241 de l'émetteur 240 effectue différents contrôles monétiques vis-à-vis de cette demande d'autorisation et envoie (étape 204), en retour, une réponse au serveur d'autorisation 231 de l'acquéreur 230 signifiant son accord ou son refus. 15 [071] Ces vérifications monétiques comprennent, entre autres, le risque émetteur, la solvabilité du porteur 210, ou le montant maximal autorisé. [072] L'accord de la transaction par l'émetteur 240 signifie que ce dernier garantit la compensation du montant de cette transaction à l'acquéreur 230. 20 [073] A la réception de la réponse de l'émetteur 240 à la demande d'autorisation, le serveur d'autorisation 231 de l'acquéreur 230 interprète cette réponse et communique (étape 205) sa propre réponse au moyen d'acceptation 221. [74] Lorsque la transaction est refusée par l'émetteur 240, le serveur 25 d'autorisation 231 de l'acquéreur 230 transfère (étape 205) ce refus au moyen d'acceptation 221. [75] En revanche, lorsque la transaction est acceptée par le serveur d'autorisation 241 de l'émetteur 240, le serveur d'autorisation 231 de l'acquéreur 240 effectue, à son tour, des contrôles vis-à-vis de cette 30 demande d'autorisation. [76] En effet, en plus de l'application d'une éventuelle gestion de risque propre à l'acquéreur 230, le serveur d'autorisation 231 de l'acquéreur 230 vérifie, en interrogeant (étape 209) une base de données 234, que le porteur 210 et/ou le support de transaction 211 ne 35 figurent pas dans une liste prédéfinie (liste d'oppositions par exemple) tenue par cet acquéreur 230 ou partagée avec d'autres établissements financiers. 12 [077] Lorsque la transaction est également acceptée par le serveur d'autorisation 231 de l'acquéreur 230, ce serveur d'autorisation 231 génère un code de transaction au moyen d'un générateur 232 de code de transaction. 5 [078] Le code de transaction généré est associé à la transaction sur laquelle porte la demande d'autorisation émise par le moyen d'acceptation 221 et autorisée par le serveur d'autorisation 231 de l'acquéreur 230. [79] Dans un autre mode de réalisation, un code de transaction est 10 systématiquement généré et associé à toute transaction autorisée par le serveur d'autorisation 241 de l'émetteur 240 (la réponse du système d'autorisation 231 de l'acquéreur 230 étant, dans ce cas, favorable dès que la transaction est acceptée par l'émetteur 240). [80] Dans un mode de réalisation, le code de transaction permet 15 d'identifier de manière unique la transaction autorisée. [81] Dans un autre mode de réalisation, ce code de transaction permet d'identifier, en combinaison d'au moins une autre information concernant le support de transaction 211 (par exemple, la date d'expiration ou le cryptogramme d'une carte bancaire) et/ou une 20 information concernant le porteur 210 (nom et/ou prénom), de manière unique la transaction autorisée par le serveur d'autorisation 231 de l'acquéreur 230. [82] Le code de transaction généré par le générateur 232 peut prendre toute forme appropriée, tel qu'un mot alphanumérique, un code QR 25 (pour « Quick Response »), ou un code à barres. [83] Dans un mode de réalisation, le code de transaction est généré (ou chiffré) au moins à partir d'une information relative à la transaction (montant, date) et/ou au support de transaction 211 (numéro de carte, date d'expiration) et/ou au porteur 210 (nom, prénom ou tout autre 30 identifiant), et/ou à l'accepteur 220 (identifiant, nom de l'enseigne), ou à partir d'une combinaison de ces informations. [84] Dans un mode de réalisation, un code de transaction est généré uniquement lorsque : - la transaction pour laquelle une autorisation est demandée porte 35 sur un montant supérieur à un montant minimum prédéfini, et/ou - la demande d'autorisation provient d'un moyen d'acceptation 221 et/ou d'un accepteur 220 compris dans une liste prédéfinie 13 (uniquement les terminaux de paiement électronique physique, et/ou uniquement les moyens d'acceptation d'une certaine enseigne commerciale, ou uniquement des modules de paiement électronique d'un site e-commerce par exemple); et/ou 5 - l'émetteur 240 du support de transaction 211 est compris dans une liste prédéfinie d'émetteurs (une liste de banques par exemple) intégrant, dans un mode de réalisation, l'acquéreur 230 lui-même; et/ou - le porteur 210 ne figure pas dans une liste prédéfinie par 10 l'acquéreur 230 dans une base de données 234 ; - le support de transaction 211 est parmi une liste prédéfinie (cartes Visa® par exemple). [85] Les informations concernant chaque transaction autorisée par l'acquéreur 230, y compris le code de transaction généré par le 15 générateur 232, sont mémorisées par le serveur d'autorisation 231 de l'acquéreur 230. [86] Lorsque le serveur d'autorisation 231 de l'acquéreur 230 confirme l'accord du serveur d'autorisation 241 de l'émetteur 240, le serveur d'autorisation 231 de l'acquéreur 230 envoie (étape 205) une réponse 20 favorable, intégrant le code de transaction générée, au moyen d'acceptation 221. [87] En fonction de la réponse reçue depuis le serveur d'autorisation 231 de l'acquéreur 230, le moyen d'acceptation 221 accepte ou refuse la transaction et en informe le porteur 210 et/ou l'accepteur 220. 25 [088] A la réception, par le moyen d'acceptation 221, de l'accord et du code de transaction, le moyen d'acceptation 221 communique (étape 206) ce code au porteur 210. [89] Le porteur 210 est, ainsi, informé du code de transaction généré par le serveur d'autorisation 231 de l'acquéreur 230, en plus des 30 informations standards qui lui sont également communiquées (le montant de la transaction, date et heure de la transaction, et enseigne de l'accepteur 220 par exemples). [90] Dans un autre mode de réalisation, des informations additionnelles sont également communiquées au porteur 210, telles 35 qu'une adresse VVeb, un nom d'une application mobile via lequel le porteur 210 peut utiliser le code de transaction ou, plus généralement, tout pointeur (codé ou en clair) vers une ressource en ligne, et/ou un 14 délai durant lequel ce code de transaction est valide. [91] Dans un mode de réalisation, lorsque le moyen d'acceptation 221 est un terminal de paiement pourvu d'une imprimante, le ticket de carte bancaire (c.à.d. la facturette ou, plus généralement, le justificatif de 5 transaction) imprimé comprend le code de transaction généré par le serveur d'autorisation 231 de l'acquéreur 230. [92] Le justificatif de la transaction comprend, en outre, dans un autre mode de réalisation, une adresse pointant directement ou indirectement vers un serveur distant. 10 [093] En variante ou en combinaison, un délai de validité du code de transaction est, en outre, communiqué au porteur 210. [094] Dans un mode de réalisation, le code de transaction est : - instantanément, imprimé à la caisse sur le justificatif de paiement, tel que le ticket de carte bancaire ou le ticket de 15 caisse ; et/ou - affiché au porteur, de sorte qu'il lui soit porté à sa connaissance ; - envoyé au porteur 210, par courrier, par courriel, par SMS ou via une notification, dans ou séparé du justificatif du paiement. Pour cela, les cordonnées requises (courriel, adresse postale, numéro 20 de téléphone, application mobile de paiement électronique utilisée) peuvent être fournies au préalable ou demandées au porteur 210 et/ou au support de transaction 211. [95] En fonction du support utilisé pour communiquer le code de transaction au porteur 210, le moyen d'acceptation 221 est connecté à 25 un ou plusieurs dispositifs dédiés (une imprimante de ticket de carte bancaire, un écran, un serveur de notification Push, un serveur pour envoi de courriel ou de SMS, ou une interface de communication sans fil de courte portée). [96] Outre la communication (étape 206) au porteur 210 du code de 30 transaction et les informations conventionnelles concernant la transaction autorisée, le moyen d'acceptation 221 mémorise en local les informations relatives à cette transaction (montant, date, et identifiants concernant le support de transaction 211, et/ou le compte associé à ce support, et/ou le porteur 210), y compris le code de 35 transaction correspondant. [97] Lors de la télécollecte, qu'elle soit déclenchée d'une façon manuelle ou automatique, les informations mémorisées par le moyen 15 d'acceptation 221 sont envoyées (étape 207) à un serveur de rétention 233 de l'infrastructure monétique de l'acquéreur 230. [98] Les transactions, par exemple journalières, mémorisées par le moyen d'acceptation 210 sont, ainsi, remises (étape 207) au serveur de 5 rétention 233 de l'acquéreur 230. [99] Suite à cette télécollecte, le compte de l'accepteur 220 est crédité par l'acquéreur 230 d'un montant correspondant aux transactions remises dans un délai convenu entre eux (par exemple, 48 heures). 10 [0100] La configuration du moyen d'acceptation 221 par le mainteneur ou par l'acquéreur 230 lors d'une phase de téléparamétrage permet de connecter le moyen d'acceptation 221 au serveur de rétention 233. [0101] Le serveur de rétention 233 est accessible à distance, via 15 une adresse VVeb, URL ou analogue, au moyen de tout terminal utilisateur apte à se connecter à un serveur distant, tel qu'un ordinateur, une tablette numérique, un Smartphone, un téléphone portable, ou plus généralement tout dispositif permettant au porteur 210 d'interagir avec un serveur distant. 20 [0102] Dans un mode de réalisation, le serveur de rétention 233 est accessible au porteur 210 à l'adresse qui lui a été communiquée au préalable. [0103] Ainsi, lorsqu'un code de transaction lui a été communiqué, le porteur 210 25 s'authentifie (étape 300) auprès du serveur de rétention 233 en renseignant le code de transaction et, éventuellement pour des raisons de sécurité, d'autres informations concernant le support de transaction 211 utilisé (par exemples le cryptogramme, la date d'expiration et/ou le numéro de la carte bancaire utilisée) et/ou 30 concernant le porteur 210 (par exemples, nom, prénom, courriel et/ou identifient) et/ou concernant la transaction (montant, date par exemple) et/ou l'acquéreur 220 (adresse, enseigne par exemple, procédés d'authentification forte); lorsqu'il est authentifié par le serveur de rétention 233 en 35 comparant les informations qui lui sont soumises par le porteur 210 avec les informations qui lui sont communiquées lors de la télécollecte, accède (étape 300) à la transaction en question. 16 [0104] Dans un mode de réalisation, l'authentification peut se faire en saisissant et/ou en scannant (lorsque le code de transaction ou autre information requise est/sont sous la forme d'un code QR ou code à barres) les informations requises dans un formulaire électronique à 5 soumettre au serveur de rétention 233. [0105] Dans un autre mode de réalisation, pour authentifier le porteur 210, le serveur de rétention 233 compare également les informations qui lui sont soumises par le porteur 210 aux informations déjà mémorisées par le serveur d'autorisation 231 dans la base de 10 données 234 de l'acquéreur 230. [0106] De préférence, les méthodes d'authentification et les mécanismes de sécurité applicables au paiement électronique (chiffrement, procédés d'authentification forte) sont utilisés pour protéger l'accès aux transactions mémorisées par le serveur de 15 rétention 233. [0107] Une transaction est identifiée par le serveur de rétention 233 par son code de transaction, combiné, le cas échéant, avec toute autre information mémorisée et qui lui est associée. [0108] Une fois authentifié, le porteur 210 accède, dans un délai 20 prédéfini à compter de la date de la transaction requise, à l'ensemble ou à une partie des informations mémorisées concernant cette transaction. [0109] Dans un mode de réalisation, le porteur 210 peut copier et/ou imprimer ces informations. 25 [0110] Dans un autre mode de réalisation, le porteur 210 peut modifier, parmi les informations auxquelles a accès, certaines informations prédéfinies par l'acquéreur 230. [0111] Il en résulte que le porteur peut avoir accès et extraite, à partir du flux des transactions en gestion par l'acquéreur 230, une 30 transaction qu'il a récemment réalisée et, éventuellement, la modifier. [0112] La modification par le porteur 210 d'une information concernant une transaction mémorisée peut déclencher des actions prédéfinies à entreprendre par le serveur de rétention 233. [0113] Par exemple, 35 la modification des informations concernant le support de transaction (numéro de carte, identité du porteur par exemple) peut déclencher l'émission d'une nouvelle demande d'autorisation 17 auprès de l'émetteur du nouveau support de transaction; - la modification du montant de la transaction peut déclencher la division de la transaction en deux ou plusieurs autres transactions divisionnaires, de sorte que le montant de la 5 première transaction divisionnaire soit inférieur ou égal au montant de la transaction initiale ; - la combinaison des deux modifications précédentes déclenche une demande d'autorisation pour chacune des transactions divisionnaires auprès de l'émetteur de chaque nouveau support 10 de transaction correspondant. [0114] Dans un mode de réalisation, la modification de certaines informations concernant une transaction de paiement peut être refusée au porteur 210 (par exemple, suite à un refus signifié par l'émetteur du nouveau support de transaction renseigné par le porteur 210). 15 [0115] Dans un mode de réalisation, une copie de secours des transactions reçues par le serveur de rétention 233 (les remises) est sauvegardée, de sorte à avoir une copie originale d'une transaction modifiée par la suite par le porteur 210. [0116] Le serveur de rétention est configuré pour retenir chaque 20 transaction qui lui est remise par un moyen d'acceptation, avant qu'elle ne soit exploitée par l'acquéreur, pendant un délai prédéfini de rétention. [0117] Ce délai de rétention correspond au délai de validité du code de transaction. 25 [0118] Dans un mode de réalisation, ce délai prédéfini de rétention est de 2 jours, 3 jours, 4 jours, 5 jours, 6 jours ou 7 jours à compter de la date de la transaction de paiement. [0119] Une transaction demeure, ainsi, accessible au porteur 210 pendant tout ce délai de rétention. 30 [0120] Dans un autre mode de réalisation, la rétention est clôturée à compter d'un nombre prédéfini de modifications. A titre d'exemple, la rétention arrive à échéance suite à la validation, pendant le délai de rétention initial, par le porteur d'un nombre de transactions divisionnaires. 35 [0121] A l'expiration de son délai de rétention, chaque transaction éventuellement consultée, voire modifiée, par le porteur 210 est transmise au serveur de télécollecte 232 pour leur exploitation par 18 l'acquéreur 230. [0122] L'exploitation de ces transactions par l'acquéreur 230 comprend, entre autres, une étape de compensation (étape 208) auprès d'un organisme de compensation 250. 5 [0123] L'ensemble ou seulement une partie des éventuelles transactions divisionnaires générées (c.à.d. en cas de division de la transaction initiale) par le serveur de rétention 233 suite à une modification apportée par un porteur 210 sur une transaction de paiement qu'il a réalisée récemment est transmise au serveur de 10 télécollecte 232 pour traitement ultérieur. [0124] Dans un mode de réalisation, le serveur de rétention 233 est un serveur intermédiaire entre les moyens d'acceptation 221 et le serveur de télécollecte 232. [0125] Le serveur de rétention 233 est, par exemple, un serveur 15 pourvu d'une base de données pour y retenir pendant une durée prédéfinie (délai de rétention) les informations qui lui sont transmises depuis les moyens d'acceptation 221. Ce serveur de rétention 233 est accessible par un utilisateur depuis une interface homme-machine. Cet accès peut être direct ou via un ou plusieurs serveurs intermédiaires. 20 Ces serveurs intermédiaires peuvent être des serveurs VVeb, des serveurs applicatifs ou tout autre moyen présentant une interface homme-machine. [0126] En alternative, le serveur de rétention 233 est le serveur de télécollecte 233 qui est configuré (ou adapté) pour retenir toute 25 transaction qui lui est remise par télécollecte depuis un moyen d'acceptation 221 pendant un délai prédéfini de rétention à compter de la date de cette transaction ou, d'une manière équivalente, de la télécollecte, avant son exploitation par l'acquéreur 230. [0127] Les méthodes et systèmes décrits ci-dessus présentent 30 plusieurs avantages. [0128] Ils permettent, en effet, - une meilleure maitrise des transactions après leur autorisation ; - la modification ultérieure, par le porteur 210, des données d'une transaction, conduisant à la modification des flux de 35 transactions ; - d'apporter une certaine souplesse aux méthodes de traitement des flux de transactions de paiement électronique, dans le sens 19 ils offrent la possibilité d'isoler une transaction particulière du flux en vue d'un traitement spécifique ; - de tenir compte, lors l'exploitation des transactions par l'acquéreur 230, d'informations fournies à une date postérieure à 5 la date de télécollecte de ces transactions depuis les accepteurs ; - de faire intervenir le porteur dans le cycle de vie d'une transaction qu'il REVENDICATIONS1. Infrastructure de paiement électronique d'un acquéreur (230) à laquelle est connecté au moins un moyen d'acceptation (221) configuré pour accepter un support de transaction (211) en vue de la réalisation d'un paiement électronique, cette infrastructure comprenant : - un serveur d'autorisation (231) configuré pour o recevoir, depuis le moyen d'acceptation (221), une demande d'autorisation concernant une transaction de paiement électronique au moyen d'un support de transaction (211), le support de transaction (211) étant émis par un émetteur (240) ; o router la demande d'autorisation vers l'émetteur (240) du support de transaction (211) ; o recevoir, depuis l'émetteur (241) du support de transaction (211), une réponse à la demande d'autorisation ; o communiquer, au moyen d'acceptation, une réponse à la demande d'autorisation ; cette infrastructure de paiement électronique étant caractérisée en ce que - le serveur d'autorisation (231) est, en outre, configuré pour générer, lorsque ce serveur d'autorisation (231) autorise ladite transaction, un code de transaction associé à cette transaction et destiné au porteur (210) du support de transaction (211), la réponse communiquée au moyen d'acceptation (221) comprenant ce code de transaction ; - cette infrastructure de paiement électronique comprend, en outre, un serveur de rétention (233) configuré pour o recevoir, depuis le moyen d'acceptation (221), des informations concernant la transaction autorisée, ces informations comprenant le code de transaction ; o retenir les informations reçues, avant exploitation de cette transaction par l'acquéreur (230), pendant un délai prédéfini de rétention ; o permettre l'accès, pendant le délai prédéfini de rétention, à au moins une information parmi les informations retenues sur réception d'au moins le code de transaction associé à la transaction. 21 2. Infrastructure de paiement électronique selon la revendication précédente, caractérisé en ce que le serveur de rétention (233) est configuré pour permettre la modification de ladite au moins une information parmi les informations retenues. 5 3. Infrastructure de paiement électronique selon la revendication 1 ou 2, caractérisé en ce que la réponse communiquée au moyen d'acceptation (221) comprend, en outre, une adresse pointant vers le serveur de rétention (233). 10 4. Infrastructure de paiement électronique selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur d'autorisation (231) est configuré pour générer le code de transaction lorsque le montant de la transaction est supérieur à un montant 15 minimum prédéfini, et/ou lorsque la demande d'autorisation est reçue depuis un moyen d'acceptation (221) compris dans une liste prédéfinie, et/ou l'émetteur (240) du support de transaction (211) est compris dans une liste prédéfinie, et/ou le support de transaction (211) est compris dans une liste prédéfinie. 20 5. Infrastructure de paiement électronique selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de rétention (233) est configuré pour permettre l'accès à ladite au moins une information parmi les informations retenues sur réception du code 25 de transaction et au moins une information concernant le support de transaction (211) au moyen duquel a été réalisée la transaction. 6. Infrastructure de paiement électronique selon l'une quelconque des revendications précédentes, caractérisé en ce que le code de 30 transaction est généré de sorte à permettre l'identification de manière unique la transaction. 7. Procédé de traitement d'une transaction de paiement électronique entre un porteur (210) disposant d'un support de transaction (211) et un 35 accepteur (220) disposant d'un moyen d'acceptation (221) acceptant le support de transaction (211) du porteur (210) en vue de la réalisation d'un paiement électronique, le moyen d'acceptation (221) étant 22 connecté à une infrastructure de paiement électronique d'un acquéreur (230), le support de transaction (211) étant émis par un émetteur (240), ce procédé comprenant les étapes suivantes : - envoi (202) d'une demande d'autorisation, depuis le moyen 5 d'acceptation (221) à un serveur d'autorisation (231) de l'infrastructure de paiement électronique de l'acquéreur (230), cette demande d'autorisation concernant une transaction de paiement électronique au moyen du support de transaction (211), - routage (203) de la demande d'autorisation, depuis le serveur 10 d'autorisation (231) vers l'émetteur (240) du support de transaction (211); - réception, depuis l'émetteur (240) du support de transaction (211), d'une réponse à la demande d'autorisation ; - communication (205), au moyen d'acceptation (221), d'une 15 réponse à la demande d'autorisation ; ce procédé étant caractérisé en ce qu'il comprend, en outre, les étapes suivantes - génération par le serveur d'autorisation (231), lorsque ce serveur d'autorisation (231) autorise ladite transaction, d'un code de 20 transaction associé à cette transaction et destiné au porteur (210) du support de transaction (211), la réponse communiquée au moyen d'acceptation (221) comprenant ce code de transaction ; - réception par un serveur de rétention (233) de l'infrastructure de 25 paiement électronique de l'acquéreur (230) et depuis le moyen d'acceptation (221) d'informations concernant la transaction autorisée, ces informations comprenant le code de transaction ; - rétention, par le serveur de rétention (233), des informations reçues, pendant un délai prédéfini de rétention avant exploitation 30 de cette transaction par l'acquéreur (230); - accès par le porteur (210), pendant le délai prédéfini de rétention, à au moins une information parmi les informations retenues sur réception par le serveur de rétention (233) d'au moins le code de transaction associé à la transaction. 35 8. Procédé de traitement selon la revendication 7, caractérisé en ce qu'il comprend, en outre, une étape de modification de ladite au 23 moins une information parmi les informations retenues. 9. Procédé de traitement selon la revendication 7 ou 8, caractérisé en ce qu'il comprend, en outre, une étape d'impression du code de 5 transaction sur le justificatif de paiement et/ou une étape d'envoi par courriel ou par SMS du code de transaction à destination du porteur (210) du support de transaction (211). 10. Procédé de traitement selon la revendication 8 ou 9, caractérisé 10 en ce qu'il comprend, en outre, une étape d'envoi, lorsque ladite au moins une information parmi les informations retenues est modifiée et concerne le support de transaction (211), d'une demande d'autorisation par le serveur de rétention (233) à l'émetteur du support de transaction modifié. 15