Brevet FR3001822A1 — publié le 20140808

L'invention se rapporte au domaine du paiement par carte électronique et plus particulièrement de l'autorisation de paiement dans un système de paiement électronique dont le terminal de paiement est hautement sécurisé par l'indépendance des modules logiciels dédiés à chaque type de carte, entre eux. En effet, un terminal selon l'art antérieur utilise des briques logicielles fournissant des fonctions communes à chaque type de cartes. Cette factorisation ne convient pas pour un système hautement sécurisé. Selon un mode de réalisation, l'invention fournit un procédé pour effectuer une transaction électronique avec une carte de paiement, caractérisé en ce que, dans un système de paiement comportant un site local, un site central distant du site local relié au site local par un premier réseau étendu de communication et un ou plusieurs serveurs d'autorisation de paiement reliés au site central par un second réseau étendu de communication, le site local comportant un serveur d'animation, un serveur monétique local, une pluralité de caisses de vente, une pluralité de terminaux de paiement 20 électronique d'une capacité mémoire inférieure à 96 mégaoctets, et un réseau local reliant la pluralité de caisses de vente au serveur d'animation et au serveur monétique local, chaque caisse de vente étant en outre connectée à un dit terminal de paiement électronique, ladite caisse de vente étant apte à communiquer avec ledit terminal de paiement 25 électronique, le serveur d'animation comprenant une base de données des avantages applicables comportant des règles logiques d'attribution d'avantages commerciaux, le site central comportant un portail de paiement, 30 le serveur d'autorisation de paiement comportant une pluralité de modules d'autorisation associés à une pluralité de types de cartes, ledit serveur de monétique local étant apte à interroger le portail de paiement à travers le premier réseau étendu de communication, le procédé comporte les étapes suivantes: a) la caisse de vente initie la transaction électronique en transmettant au 5 terminal de paiement électronique une demande de lecture de carte, b) le terminal de paiement électronique lit la carte insérée dans le lecteur de carte pour obtenir des informations de ladite carte, incluant un identifiant d'un établissement émetteur et un identifiant de la carte, c) le terminal de paiement électronique transmet à la caisse de vente les 10 informations de la carte, d) la caisse de vente extrait des informations l'identifiant de la carte et l'identifiant de l'établissement émetteur, e) la caisse de vente vérifie si l'identifiant de l'établissement émetteur appartient à une liste de codes d'établissements autorisés, 15 f) la caisse de vente transmet au serveur d'animation une demande d'avantages, ladite demande d'avantages comprenant les informations de ladite carte, g) le serveur d'animation construit une trame de demande de profil selon un format de messagerie unifiée, la trame de demande de profil comprenant 20 les informations de ladite carte, h) le serveur d'animation transmet au portail de paiement la demande de profil, i) le portail de paiement transmet les informations de la carte au serveur d'autorisation de paiement, 25 j) le serveur d'autorisation de paiement comprenant une base de données de profil, ledit serveur d'autorisation de paiement extrait le profil correspondant aux informations de la carte, k) le serveur d'autorisation de paiement interrogé transmet une réponse de profil comprenant le profil extrait de la base de données au portail de 30 paiement, I) le portail de paiement construit une trame de réponse de profil selon le format de messagerie unifiée, et transmet la trame de réponse de profil au serveur d'animation, m) le serveur d'animation applique les règles logiques d'attribution des avantages en fonction du profil compris dans la trame de réponse, n) le serveur d'animation transmet au terminal de paiement électronique le 5 profil compris dans la réponse, et des avantages attribués audit profil, o) le terminal de paiement électronique transmet le profil et les avantages à la caisse, p) la caisse calcule un montant total de la transaction en fonction des avantages attribués au profil, 10 q) la caisse de vente transmet au terminal de paiement électronique une demande de règlement comportant des caractéristiques de la transaction incluant le montant total, éventuellement remisé, r) le terminal de paiement électronique créé une demande d'autorisation de paiement pour la carte, 15 s) le terminal de paiement électronique transmet au serveur monétique la demande d'autorisation de paiement comprenant le type de carte, l'identifiant de la carte, le montant total, t) le serveur de monétique local construit une trame de demande d'autorisation de paiement selon le format de messagerie unifiée, la trame 20 de demande d'autorisation de paiement comprenant la demande d'autorisation de paiement, u) le serveur de monétique local poste la trame de demande d'autorisation à l'attention du portail de paiement par un protocole de communication sécurisé, 25 v) le portail de paiement transmet la demande d'autorisation de paiement au serveur d'autorisation de paiement, w) le serveur d'autorisation de paiement identifie le type de carte contenu dans la demande d'autorisation, X) le serveur d'autorisation de paiement sélectionne un module 30 d'autorisation correspondant au type de carte et utilise le module d'autorisation sélectionné pour effectuer une vérification d'autorisation de paiement, et le module d'autorisation génère une réponse d'autorisation de paiement, y) le serveur d'autorisation de paiement transmet la réponse d'autorisation de paiement au portail de paiement, z) le portail de paiement envoie une trame de réponse selon le format de messagerie unifiée au serveur de monétique local, la trame de réponse comprenant la réponse d'autorisation de paiement, la trame de réponse étant destinée au terminal de paiement électronique, aa) le serveur de monétique local transmet la réponse d'autorisation au terminal de paiement électronique, ab) le terminal de paiement électronique transmet la réponse d'autorisation de paiement à la caisse de vente, ac) la caisse de vente envoie un acquittement de transaction au terminal de paiement électronique, ad) le terminal de paiement électronique affiche la réponse sur un écran du 15 terminal de paiement électronique, ae) le terminal de paiement électronique transmet l'acquittement au serveur monétique local. Grâce à ces caractéristiques le système de paiement d'une 20 enseigne de distribution, ou chaîne de magasins, apte à mettre en oeuvre le procédé ci-dessus pour effectuer une transaction électronique est réalisé selon une architecture distribuée. Les caractéristiques liées à cette architecture présentent un certain nombre d'avantages. Le site central permet de centraliser les demandes de profil et 25 d'autorisation de paiement, quelle que soit la carte de paiement utilisée. Le site central communique avec les magasins à l'aide d'une messagerie unifiée afin de standardiser les communications d'un système hétérogène et faciliter l'ajout de nouveaux types de cartes. Ce site peut renvoyer la demande au site de gestion des autorisations. Le site central a donc pour 30 rôle de recevoir les demandes, les traduire et les aiguiller vers un serveur d'autorisation. Les autorisations peuvent provenir d'un ou plusieurs serveurs d'autorisations, présents sur un ou plusieurs sites. Ces serveurs d'autorisations procèdent principalement à des contrôles d'ordre financier. Par exemple, les sites d'autorisations sont sous le contrôle d'un organisme financier. Ces serveurs d'autorisations peuvent donc être indépendants de l'exploitant du système de paiement par exemple l'enseigne de distribution. En outre, un serveur d'autorisation peut à l'aide de modules supporter plusieurs types de cartes émanant par exemple du même réseau financier. Par cette gestion centralisée des autorisations de paiement, il est possible de garantir le respect des seuils d'achats. Un client ne pourra pas faire des achats dans un premier magasin de l'enseigne, puis immédiatement après dans un second magasin de l'enseigne pour un montant total supérieur à son seuil de paiement. Cette architecture permet donc d'éviter ce type de fraude. Le site local comporte un serveur d'animation qui permet de gérer des règles logiques d'attribution d'avantages notamment à un niveau local. Les avantages sont par exemple de deux types. Il y a ceux dont les règles sont générales à l'enseigne et applicables dans tous les sites locaux et ceux dépendant de règles spécifiques à un site local. Ce serveur d'animation en fonction du profil de la carte applique les règles logiques d'attribution des avantages. Le site local comporte également un serveur monétique. Celui-ci transfère les demandes d'autorisation de paiement. Ce serveur monétique peut en outre effectuer la journalisation des transactions effectuées. Chaque jour ce serveur monétique transmet par exemple les transactions effectuées à l'établissement bancaire de l'enseigne. La caisse de vente effectue le calcul du montant de la transaction en fonction des avantages consentis par le serveur d'animation. Grâce aux caractéristiques ci-dessus, le procédé déporte à 30 l'extérieur du terminal des fonctions évoluées telles la vérification d'autorisation et la sélection d'un traitement dédié au type de carte, ce qui libère le terminal du traitement de ces étapes et permet ainsi de supporter une multiplicité de cartes de paiement avec une capacité mémoire très limitée au niveau du terminal. En particulier, grâce au traitement d'une information de type de carte par le serveur d'autorisation, il est possible de fournir des 5 fonctionnalités différentes selon différents types de cartes, tout en fournissant un traitement commun au niveau du terminal de paiement électronique. Le terminal de paiement peut ainsi, avec une capacité mémoire très limitée, mettre en oeuvre des exigences de haute sécurité. De plus, l'utilisation d'une trame selon un format de messagerie 10 unifiée permet de traiter de manière centralisée des demandes d'autorisation provenant d'une multitude de sites locaux pouvant présenter une forte hétérogénéité. Ce format favorise aussi une gestion simple des évolutions du système de paiement, notamment pour supporter des nouvelles cartes de paiement. 15 Selon d'autres modes de réalisation avantageux, un tel procédé peut présenter une ou plusieurs des caractéristiques suivantes. Selon un mode de réalisation, le procédé comprend en outre les 20 étapes dans lesquels : le portail de paiement convertit à l'intention du serveur d'autorisation de paiement la trame de demande de profil selon le format de messagerie unifiée transmise par le serveur de monétique local, 25 le portail de paiement convertit la réponse à la demande de profil émise par le serveur d'autorisation de paiement, en la trame de réponse à la demande de profil selon le format de messagerie unifiée. Grâce à ces caractéristiques, il est possible de supporter une 30 multitude de cartes de paiement avec plusieurs options de paiement par carte, avec une capacité mémoire très limitée au niveau du terminal. Selon un mode de réalisation du procédé, le portail de paiement convertit à l'intention du serveur d'autorisation de paiement la trame de demande d'autorisation de paiement selon le format de messagerie unifiée transmise par le serveur de monétique local, le portail de paiement convertit la réponse à la demande d'autorisation de paiement transmise par serveur d'autorisation de paiement, en la trame de réponse à la demande d'autorisation de paiement selon le format de messagerie unifiée. Selon un mode de réalisation du procédé, le terminal de paiement 10 électronique communique de manière sécurisée par une méthode de cryptographie asymétrique. Selon un mode de réalisation du procédé, le portail de paiement fournit en outre un certificat d'identification au serveur de monétique local. Selon un mode de réalisation du procédé, le protocole sécurisé est 15 le protocole SSL version 3, à clef de longueur non nulle. Selon un mode de réalisation du procédé, le protocole sécurisé est le protocole TSL. 20 Certains aspects de l'invention partent de l'idée de fournir l'ensemble des fonctionnalités associées à chacune des cartes supportées. Certains aspects de l'invention partent de l'idée de faciliter l'ajout 25 de nouvelles cartes d'établissements émetteurs au système de paiement. Certains aspects de l'invention partent de l'idée d'augmenter les exigences de sécurité appliquées au terminal. L'invention sera mieux comprise, et d'autres buts, détails, 30 caractéristiques et avantages de celle-ci apparaîtront plus clairement au cours de la description suivante de plusieurs modes de réalisation particuliers de l'invention, donnés uniquement à titre illustratif et non limitatif, en référence aux dessins annexés. Sur ces dessins : - La figure 1 représente l'architecture d'un terminal de paiement selon l'art antérieur. - La figure 2 représente l'architecture informatique d'un magasin. - La figure 3 est un diagramme de séquence qui illustre les étapes de communications pour le calcul des avantages octroyés au porteur de la carte par l'animation commerciale lors d'un paiement. - La figure 4 représente l'architecture logicielle d'un terminal de paiement selon l'invention. - La figure 5 est un diagramme de séquence qui illustre les communications entre le serveur de monétique local et le serveur central. - La figure 6 est un diagramme de séquence qui illustre les communications entre le terminal de paiement et le serveur monétique local lors d'un paiement par carte. Dans les figures, les chiffres de références identiques entre figures se rapportent au même élément ou à un équivalent technique. Dans ces figures, le terminal de paiement selon l'art antérieur, représenté à la figure 1 est un terminal utilisé par les enseignes commerciales dans leurs magasins pour finaliser un achat par un paiement à l'aide d'une carte de paiement. Ce terminal permet également le paiement à l'aide de cartes publiques ou des cartes privées. Il permet enfin la gestion de fonctionnalités spécifiques associées à certains types de cartes, par exemple, la fidélisation ou encore les cartes cadeaux. En référence à la figure 1, l'architecture selon l'art antérieur d'un 30 terminal désigné dans son ensemble par la référence 1001 comprend un module de lecture 1002, un module de reconnaissance du code d'identification de la banque (BIN en anglais) 1003, un module d'autorisation 1004 et des modules applicatifs désignés dans leurs ensembles par la référence 1005. Lors de l'insertion d'une carte 1006 à puce dans le terminal 1001, en application de la norme IS07816 le module de lecture 1002 est averti de l'insertion de cette carte. Le module de lecture 1002 procède alors à l'initialisation de la carte 1006, par un reset puis une réception du message de réponse au reset pour ensuite pouvoir procéder à la configuration des paramètres de communication afin de pouvoir communiquer avec elle. Finalement, le module de lecture 1002 récupère le code BIN de la carte et le fournit au module de reconnaissance 1003. Ce module de reconnaissance 1003 à l'aide du code BIN de la carte, identifie la banque du porteur de carte et transmet ces informations au module d'autorisation 1004. Le module autorisation 1004 selon le contexte propre à la carte 1006 valide ou non l'autorisation de paiement. Cette validation est soit réalisée par décision locale du module d'autorisation 1004 si les conditions de l'achat et les seuils d'autorisation attribués par la banque à la carte concordent. Dans le cas contraire, le module d'autorisation 1004 interroge l'établissement financier en charge de délivrer l'autorisation pour la carte 1006 insérée. Enfin, suivant la carte 1006 insérée, les fonctionnalités du module applicatif 1005 correspondant sont disponibles. Les modules applicatifs 1007 peuvent être de différents types, module carte bancaire 1007, module carte privative 1008 et module carte publique 1009. Selon la description ci-dessus, l'architecture logicielle du terminal selon l'art antérieur est factorisée. Elle comprend des modules communs 1010 utilisés quelque soit la carte insérée. Ces modules communs 1010 sont le module de lecture 1002, le module de reconnaissance du code d'identification de la banque 1003 et le module d'autorisation 1004. Elle comprend également des modules applicatifs 1005 dédiés à chaque type de carte. Cette architecture présente d'optimiser les étapes d'intégration et de validation du logiciel embarqué lors des changements, mais elle introduit par le code commun des failles de sécurité inacceptable. À cause de ces modules communs 1010, il n'y a pas de segmentation du logiciel, en fonction du type de carte. Du point de vue de la sécurité, l'absence de segmentation est une faiblesse. La figure 2 illustre l'architecture informatique d'une chaîne de magasins. Cette chaîne comprend un site central 33, un site de gestion d'autorisations 34 et des magasins 19 selon l'invention. Chaque magasin 19 communique avec le site central 33 par un réseau étendu. Le site central communique en plus avec le site de gestion d'autorisations 34. En référence à la figure 2, un magasin 19 comprend au moins un terminal point de vente encore appelé TPV référencé 20. Chaque TPV 20 est associé à un terminal de paiement électronique encore appelé TPE référencé 1. Ce magasin 19 comprend également un serveur d'encaissement 21, un serveur monétique 22 local et une passerelle 23. Le TPV 20 comprend un module d'encaissement 25 et un module monétique 24. Le terminal point de vente 20 est connecté d'une part au serveur d'encaissement 21 par l'intermédiaire du module d'encaissement 25 pour réaliser toute la gestion liée à la vente, par exemple, la gestion des stocks, les débits et les crédits. Le terminal point de vente 20 est d'autre part connecté au serveur monétique 22 par l'intermédiaire du module monétique 24 pour l'obtention des autorisations de paiement et de télécollecte. C'est ce serveur monétique 22 qui communique avec un site central 33, via la passerelle 23, pour obtenir les refus ou autorisations de paiement. Le site central 33 comprend une passerelle 32 de communication avec un réseau métropolitain ou un réseau étendu ou un réseau privé. Le site central 33 comprend un portail d'autorisation 30 qui centralise toutes les requêtes monétiques en provenance de l'ensemble des magasins 19. Le système d'autorisation 31 de paiement est localisé sur un troisième site de gestion des autorisations 34. Le portail d'autorisation 30 et le système d'autorisation 31 de paiement sont alors connectés à travers un réseau métropolitain ou étendu. Selon une variante, le site central 33 comprend également un système d'autorisation 31 de paiement. Le portail d'autorisation 30 et le système d'autorisation 31 de paiement sont connectés à travers un réseau local. En variante, le portail d'autorisation 30 est connecté à plusieurs systèmes d'autorisations 31 de paiement différents. Lors d'un encaissement, en référence à la figure 3, sur le TPV 20, le 5 caissier 300 saisit la touche paiement par carte 301, le TPV 20 effectue une demande de prélecture de la carte 302 Le terminal affiche 304 la demande « insertion carte ». Le client 306 insert 305 une carte de la troisième catégorie dans le TPE 1. Dans le cas d'une insertion de la carte 305 dans le mauvais sens (cas non représenté) pour la puce ou la piste, le TPE 1 remonte l'erreur. 10 Le module monétique 24 indique alors au TPE 1 « puce muette ». Ensuite, la transaction se poursuit normalement. Le terminal 1 effectue la prélecture et récupère les informations de la carte 307 Par exemple, pour une carte sans puce, le TPE 1 effectue une lecture de la piste magnétique ISO de la carte, par exemple la piste IS02. 15 Le TPE 1 extrait des informations de la piste ISO le numéro d'identification de la carte encore nommé PAN de l'anglais Primary Account Number. De ce numéro d'identification, il extrait l'identifiant de l'établissement émetteur de la carte également appelé BIN de l'anglais Bank Identification Number. Le PAN est sur 16 ou 19 chiffres dont les six premiers 20 correspondent au BIN. Le terminal 1 vérifie alors si le BIN fait partie d'une liste des BIN autorisés par le magasin. Si la carte fait partie de la liste des BIN du type carte de troisième catégorie alors le TPE 1 transmet 308 à la caisse 20 les informations caractérisant la carte comme la typologie de la carte et le numéro de pivot ou code PAN. La caisse interroge 309 le serveur 25 d'encaissement pour connaître les conditions de facturation applicables au détenteur de la carte. Les conditions sont dépendantes de plusieurs paramètres comme le type de cartes, les animations commerciales en cours pour l'ensemble des magasins de l'enseigne, ou encore les animations locales, spécifiques à un 30 magasin. Pour appliquer les avantages commerciaux, le serveur d'encaissement 21 délègue au module de gestion d'animation commerciale le traitement correspondant. Pour cela, le module d'animation transmet une requête de demande de profil 310 au portail d'autorisation 30. Cette requête utilise une messagerie de trame unifiée définie par des schémas XML. À la suite de l'envoi via le réseau de la requête, le module de gestion d'animation enclenche un compteur jouant le rôle de chien de garde afin de ne pas rester indéfiniment en attente de la réponse à la demande transmise. À la réception d'une requête de profil, le portail d'autorisation 30 convertit le message et le transmet 312 au système d'autorisation 31. Le système d'autorisation 31 extrait d'une base de données le profil correspondant à la carte. Ce profil peut contenir des options de paiement, par exemple, des alternatives au paiement immédiat comme le paiement différé, en trois fois sans frais, ou encore le paiement en dix fois à taux réduit. Ce profil peut également contenir des avantages, comme une journée d'achat avec un pourcentage de remise par exemple 15% sur le linge de maison, ou encore un chèque fidélité d'un montant de 20E obtenu grâce à un cumul de point d'achat. Après avoir extrait le profil, le système d'autorisation 31 transmet ce profil 313 au portail d'autorisation 30 qui le convertit selon le format unifié et le transmet 314 au module d'animation du serveur d'encaissement 21. Le module d'animation stoppe alors le mécanisme de chien de garde 311. À l'aide du profil reçu, le module d'animation extrait les avantages locaux et nationaux applicables à cette carte. Enfin, il transmet les avantages applicables et les informations de profil 315 au terminal 1. Le TPE 1 transmet 316 les options de paiement et les avantages à appliquer fournis par le module d'animation commerciale à la caisse 20. Avec ces différents paramètres, la caisse 20 peut alors calculer 317 le montant total du ticket net applicable à ce client. Ceci est la dernière étape permettant le calcul des avantages consentis au client avant l'encaissement. Une fois le calcul des remises et avantages appliqués, en référence 30 à la figure 6 la caisse 20 envoie une demande de règlement 350 au terminal 1. Cette demande de règlement contient en particulier le montant à débiter. Le TPE 1 propose alors au client les options dont il dispose pour payer. Une fois que le TPE 1 a enregistré le choix effectué par le client, il vérifie 352 les paramètres de la carte puis transmet au serveur monétique 22 une demande d'autorisation 353 de paiement comprenant les paramètres nécessaires à l'identification de la carte. Selon le type de carte la demande d'autorisation est une demande interne ou une demande externe. À la suite de l'envoi de la demande, le terminal 1 active un compteur de type chien 354 de garde pour ne pas rester bloqué dans l'attente d'une réponse si la réponse n'arrive pas au bout d'un délai limite. À la réception du message de la demande, le serveur monétique 22 convertit ce message 355 selon un format de message unifié. Ce format de message unifié est décrit plus loin. À son tour, le serveur monétique 22 interroge 357 un service d'autorisation en ligne et active un compteur du type chien de garde 356. Lors de la réception de la réponse 358, le serveur monétique 22 15 envoie un message 359 contenant l'autorisation positive ou négative au TPE 1. Le terminal 1 transmet 360 alors ce résultat de demande d'autorisation à la caisse 20 qui acquitte la transaction 361. Le terminal 1 informe alors le client 306 du résultat par un message affiché sur son écran. Et il transmet l'acquittement 362 au serveur monétique 22. Une remise de mouvement 20 non représentée sur la figure est effectuée entre le serveur monétique 22 du magasin et son établissement bancaire. Durant toute la phase de transaction, depuis l'étape de prélecture 307 jusqu'à l'acquittement du paiement 362 auprès du serveur monétique 22, le terminal 1 conserve le contexte et notamment les données lues sur la 25 carte dans sa mémoire interne, de manière sécurisée. Pour réaliser le paiement, le TPE 1 est un terminal de paiement, par exemple disponible auprès de la société INGENICO de référence CKD Moneyline L3070. Ce TPE 1 comprend un microprocesseur 16 bits et 16 mégaoctets de mémoire. Des exigences de haute sécurité applicables 30 notamment aux cartes bancaires exigent une étanchéité entre les logiciels présents dans un terminal de paiement 1 pour interagir avec ces cartes de paiement. Dans ce concept, chaque logiciel sur le TPE 1 doit être intégralement dédié à un type de carte. Cette disposition impacte fortement l'architecture du TPE 1. Elle consomme beaucoup de ressources mémoire dans le TPE 1. Il est difficile de concilier des exigences de haute sécurité et d'avoir un système évolutif permettant l'ajout du support de nouvelles cartes. Il convient donc de proposer une solution permettant d'une part de satisfaire à cette exigence d'étanchéité tout en conservant la possibilité de faire évoluer le système. En référence à la figure 4, l'architecture selon l'invention répond à l'exigence d'indépendance entre les logiciels de traitement de certaines cartes. En effet, le TPE 1 doit supporter différents types de cartes pour répondre à une clientèle internationale très variée. La liste des cartes supportées dépend des accords contractés auprès des fournisseurs de cartes. Le terminal supporte les cartes bancaires qui sont des cartes de paiement répondant aux exigences du Groupement d'Intérêt Économique (GIE) des Cartes Bancaires en France, par exemple Eurocard Mastercard et Visa. Selon les exigences du GIE, ces cartes comprennent une puce et éventuellement une piste, un embossage. Il supporte également des cartes publiques. Ce sont des cartes de paiement issues du réseau d'un émetteur de cartes. Elles sont similaires aux cartes bancaires, mais répondent à des normes internationales. Elles ne sont pas certifiées par le GIE Cartes Bancaires. Les cartes American Express ou Diners Club font partie de cette catégorie. Enfin, le TPE 1 supporte des cartes privatives. Cette carte de paiement est distribuée par une enseigne de la distribution ou un établissement de crédit et dont l'utilisation est limitée aux points de vente de la chaîne ou du réseau. La carte permet généralement de régler des achats soit au comptant, soit à crédit et peut intégrer de nombreux services. Elle est également utilisée comme carte de fidélité par les enseignes. C'est par exemple le cas de cartes Cofinoga. Le TPE 1 comprend un écran 450 permettant l'affichage d'informations à l'intention de l'utilisateur, un clavier 451 pour la saisie, un lecteur de cartes à puce et un lecteur de pistes magnétiques non représentés. L'architecture logicielle du TPE est découpée en deux parties, d'une part, des briques logicielles de base 400 et, d'autre part, des applications cartes pouvant être classées en trois grandes catégories 402, 407, 412, elles-mêmes divisées en plusieurs types. Les briques logicielles de bases assurent les fonctions essentielles au fonctionnement du TPE. Ce logiciel de base regroupe un module de lecture de carte 403, un module de reconnaissance de code BIN 404, un module d'interface clavier 405 du TPE, un module d'interface écran 406, un module de communication 408 vers les serveurs locaux, un module de réception des paramètres de fonctionnement 409 et un module de transmission de la journalisation 410 et enfin un module d'interface et de routage 411 entre ce logiciel de base et les applications cartes des trois catégories 402, 407, 412. Les modules d'interface clavier 405 du TPE, d'interface écran 406 permettent de piloter l'interaction avec l'utilisateur en fournissant des fonctionnalités de saisie et d'affichage. Les modules de communication 408 avec le serveur local et de transmission de la journalisation 410 permettent les échanges de données avec les serveurs du magasin, serveur monétique 22 et serveur d'encaissement 21. Le TPE peut également recevoir des paramètres à l'aide du module de réception des paramètres 409. Enfin, les modules de lecture de carte 403 et reconnaissance du 25 code BIN 404, permettent d'assurer la communication entre la carte et l'application dédiée au type de la carte. Pour cela, l'architecture comprend une application par type de carte d'une première catégorie 402, cartes certifiées par le GIE carte bancaire, une application par type de carte d'une seconde catégorie 407, 30 et une application pour l'ensemble des cartes d'une troisième catégorie 412. Une application typique comprend un module d'accès aux données de profil 420, un module de vérification des seuils 422, un module d'appel serveur 423, un module de journalisation 424. Pour certains types de cartes, l'application comprend également un module de vérification du 5 code PIN 421. Chaque module d'une même application est autorisé à communiquer avec les autres modules de cette application. En revanche, l'étanchéité entre applications lui interdit de communiquer avec ceux des autres applications. Chaque application est totalement indépendante des autres. De même, comme chaque application est dédiée à un type de 10 carte, les modules constituant ces applications sont spécialisés pour un type de carte et donc tous différents. Avec cette architecture, le fonctionnement du terminal lors d'une transaction varie selon si l'utilisateur effectue l'insertion d'une carte à puce, ou celle d'une carte à piste. Dans un premier temps, on va décrire le 15 fonctionnement avec une carte à puce, puis le fonctionnement avec une carte à piste magnétique. Lors de l'insertion d'une carte à puce dans le TPE 1, le module de lecture 403 procède à l'initialisation de cette carte (également nommé reset en anglais). À la réception de la réponse au reset (nommé ATR, Answer To 20 Reset) faite par la carte à puce, le module de lecture configure les paramètres de communication pour pouvoir dialoguer avec la carte à puce, et notamment le protocole qui peut par exemple être un protocole orienté caractères nommé TO ou encore un protocole orienté blocs nommé Ti. Enfin, il lit les informations de la carte. 25 Lors de l'insertion d'une carte magnétique ne possédant pas de puce, le lecteur lit la piste magnétique ISO. Une fois que le module de lecture 403 a obtenu les informations de la carte, il les transfère au module de reconnaissance de code BIN 404. Ce module de reconnaissance 404 de code BIN identifie le type de carte pour 30 le fournir au module d'interface 411. Le module d'interface 411 assurant le routage démarre l'application carte selon le type de carte transmis par le module de reconnaissance 404 de code BIN. À partir de cette étape et tant que la transaction n'est pas close par un l'acquittement d'une transaction réussi, un échec ou une annulation, le module d'interface 411 bloque les ressources du logiciel de base pour l'application carte démarrée. Il route toutes les communications entre ce logiciel de base et cette application. Enfin, il interdit le démarrage en parallèle d'une autre application carte. Ce scénario de fonctionnement nominal est appliqué que si le type de la carte insérée correspond à un des types de cartes reconnues par le lecteur. Dans ce mode de réalisation, le type de carte doit faire partie d'une des trois catégories 402, 407, 412. La première catégorie 402 comprend les cartes de type 1 et type 2. La seconde catégorie 407 comprend les cartes du type 3, type 4, type 5 et type 6. Enfin, la troisième catégorie 412 comprend les cartes du type 7. Pour les cartes d'une première catégorie, le module de vérification du code PIN 421 demande à l'utilisateur via le module d'interface écran 406 de saisir son code PIN qu'il transmet crypté à la carte pour que celle-ci le vérifie. À l'aide des modules d'accès aux données de profil 420 et du module d'appel serveur, l'application carte obtient notamment les seuils de paiements du profil du client. En fonction du montant de l'achat en traitement, des achats réalisés sur la période flottante de sept jours et des seuils de paiements autorisés définis pour la carte insérée, le TPE 1 procède à une autorisation hors ligne ou une autorisation en ligne. Dans le premier cas, l'autorisation de paiement est délivrée localement par le TPE 1. Dans le second cas, un service d'autorisation d'un établissement bancaire par l'intermédiaire du serveur monétique 22 est interrogé pour valider cette autorisation. Pour les cartes 7 d'une seconde catégorie, suivant le type de la carte, comme précédemment le module de vérification du code PIN demande le code PIN si la procédure de sécurité associée l'exige comme pour les cartes du type 4 et du type 6. Pour certaines cartes du type 3 ou du type 5, la procédure de sécurité remplace la saisie d'un code PIN par exemple par une signature demandée au client. Dans ce cas, comme précédemment le module d'autorisation 7 réalise alors les procédures de sécurité d'autorisation hors ligne ou en ligne, qui selon les cas peuvent être déclenchées par différents événements comme le dépassement de seuils d'achats. Si nécessaire, l'autorisation est demandée à un service d'autorisation d'un établissement bancaire par l'intermédiaire du serveur monétique 22. Pour les cartes de la troisième catégorie 412, le fonctionnement est 10 différent. En effet, le logiciel dédié, présent dans le TPE 1 doit répondre à l'exigence d'étanchéité, mais ne subit pas le même niveau d'exigences du point de vue sécurité. Une partie du traitement est déportée sur le TPV 20. Ainsi pour économiser des ressources mémoire, il est possible de limiter l'empreinte du logiciel dédié à chaque carte de la troisième catégorie 412 15 en le limitant au traitement minimum indispensable qui ne peut être déporté. C'est le TPV 20 qui traite la demande concernant les avantages applicables (promotion, réductions fidélité, etc.) en fonction du type de carte en initiant l'obtention du profil associé à la carte et le calcul du montant final du ticket de caisse en fonction des avantages consentis. 20 La figure 5 illustre la demande d'autorisation formulée par le serveur monétique 22 présent dans le magasin 19 pour de la troisième catégorie. En effet, lors de la réception par le serveur monétique 22 d'une demande émanant du module monétique 25 présent dans le TPV 20, pour une carte 25 de la troisième catégorie, celui-ci communique cette demande à un portail d'autorisation en ligne 30. Pour cela, le serveur monétique 22 traduit 500 la requête selon un format de trame définit dans une messagerie unifiée. La trame construite par le serveur monétique 22 comprend un entête et un identifiant du type de carte, suivi du message. L'entête et l'identifiant sont 30 transmis en clair pour permettre le routage de la trame émise alors que le corps du message est crypté 501. Cette trame est illustrée ci-dessous. Tableau 1: architecture d'une trame Entête Type de Corps de message XML crypté carte Le serveur monétique 22 utilise un mode de communication sécurisé 5 asynchrone pour poster 502 sa requête. Dans le cas présent ce mode est basé sur une couche de communication à travers des Sockets sécurisées à l'aide de SSL (de l'anglais Secure Socket Layer) version 3. La clé de cryptage peut être par exemple sur 128 bits. Cependant, ce transfert sécurisé peut très bien être réalisé à l'aide d'autres méthodes, comme TLS (en anglais Transport 10 Layer Security) ou encore un réseau privé virtuel également appelé VPN (en anglais Virtual Private Network). Selon un mode de réalisation alternatif, le portail d'autorisation 30 émet à l'attention du serveur monétique un certificat d'authentification. Le portail d'autorisation 30 reçoit la trame, la décrypte et la traduit 15 éventuellement 503 selon un second format de messagerie. Ensuite, le portail d'autorisation 30 transmet 504 la trame au système d'autorisation 31 qui valide la possibilité de paiement 505 et transmet une réponse 506 au portail d'autorisation 30. Ce portail d'autorisation 30 traduit éventuellement 507 la réponse 506 dans le format de messagerie unifiée. Ensuite, la trame de 20 réponse à l'exception de l'entête et du type de carte est cryptée, puis transmise au serveur monétique 22 qui est à l'origine de la requête. Pour les échanges entre le serveur monétique 22 et le portail d'autorisation en ligne 30, une messagerie unifiée a été définie pour rendre le système évolutif. Elle regroupe l'ensemble des besoins d'échange 25 d'informations pour chaque type de carte privée entre les deux serveurs. Les champs sont répartis en trois catégories : un champ d'identification du type de carte, des champs communs à toutes les cartes et des champs spécifiques dont le contenu varie selon le type de carte. La liste des champs définis dans la messagerie est disponible dans le tableau 2 ci-dessous. Dans cette liste le champ « type de carte » permet de savoir comment interpréter les champs, au contenu spécifique dépendant du type de carte. Prenons par exemple la carte « CP VIP » et supposons que seule la 5 carte « CP VIP » comporte une piste et une puce. Le champ « support de la carte » nommé Cam_Ind est à 0 pour toute carte autre que la carte CP VIP. Dans notre exemple, le champ type de carte précise que la trame se rapporte à une carte CP VIP et donc que le champ Cam_Ind fournit une information permettant de savoir si les données proviennent d'une lecture 10 manuelle avec une valeur à 1, une lecture de la piste, valeur 2, une lecture de la puce, valeur 3. Comme second exemple, la trame contient un champ « status » dont la signification diffère selon la carte. Dans le cas d'un type de carte désigné par la chaîne de caractères 15 « ECI », représentant par exemple une carte émise par une chaîne de magasin espagnol, ce champ status peut prendre les valeurs suivantes : OK: Demande acceptée 20 : refus 20 : Appel service crédit 20 05: Refus Magasin Inconnu Dans le cas d'un type de carte désigné par la chaîne de caractères « BM », représentant par exemple une carte associée aux listes de mariage Galeries Lafayette, il prendra les valeurs suivantes : 00 : OK 25 85 : Solde disponible Insuffisant. 86 : Compte Inconnu. Pour une carte CP VIP, les valeurs seront : OK: demande acceptée. 60: client à options de paiement restreintes. 30 Le choix des valeurs d'un champ ayant une même signification pour des cartes différentes peuvent être identiques ou différentes d'une carte à l'autre. De même pour un champ, une même valeur peut avoir d'une carte à l'autre une signification identique ou différente. C'est alors le champ « type de carte » qui permet de faire l'interprétation de la valeur. Tableau 2: liste des champs de la messagerie unifiée Champ Libellé Date_Enc Date de la demande d'autorisation Heure_Enc heure de la demande Typ_Enc Type Encaissement Terminal Nom du terminal Num_Caisse Numéro de caisse Num_UC Numéro de magasin Num_Carte Numéro Carte (PAN) Type carte Type de carte Cd Service Code Service Cd_Enc Code Encaissement Cd_Escp Code Escompte Cd_Credit Code Crédit Cd_MVT Code Mouvement Montant Montant de la transaction Signe Signe du montant Mt_Solde Montant du solde Signe_solde Signe du solde Date_valid Date de fin de validité de la carte Camind support de la carte Piste_ISO Piste ISO de la carte lue Status Indicateur Interne de l'application d'autorisation Cd_Repons Code réponse du centre bancaire Cd_Auto Code Autorisation (CA) Ret_Mess Message de retour CA Nb_Points Nombre de point de fidélité Cd_Dev Code devise Mt_Dev Montant de la transaction en devises Typ_Op_Comm Type Opération commerciale Choix_escpte Flag de choix Escompte CLI Numéro client Cofinoga Mode_RgIt Mode règlement Code_Trans Code Transaction Cette messagerie repose sur des trames de type document XML. Les trames sont définies à l'aide de schémas de définition XML encore nommé en anglais XSD pour XML Schema Definition. Un extrait de schéma XML est fourni à la fin de la description (exemple 1) pour illustrer une trame pour une demande d'autorisation. Dans ce schéma, on retrouve les champs présents dans le tableau ci-dessus. Comme tout fichier XML, le schéma débute dans un prologue par une déclaration XML en ligne 3 puis la déclaration de la racine du schéma. Selon la hiérarchie utilisée, le schéma définit une liste de 5 champs, un peu comme un entête, puis décrit chaque champ. Dans l'extrait fourni, la liste de champ est déclarée sous la forme d'élément. Elle débute ici par « DateEnc » et se termine pour ce message par « DaErreur ». Dans une seconde partie, chaque élément est décrit par ses caractéristiques propres qui sont par exemple son type, sa valeur par défaut, 10 etc. Dans cet exemple pour présenter le principe, seuls quelques champs sont détaillés. Par exemple, le champ Piste_ISO est un champ de type chaîne de caractères. Ses caractéristiques contiennent une restriction sur les caractères admis. Seuls les caractères de 0 à 9 sont acceptés. 15 L'exemple 2 présente un message réalisé à l'aide d'un schéma XML du type de l'exemple 1. Cet exemple illustre une demande d'autorisation de paiement émise le 24 novembre 2012, pour un achat d'un montant de 1000E réalisé par le titulaire de carte dont la piste ISO est « 123456... » avec une carte de type « Cl ». 20 Bien que l'invention ait été décrite en liaison avec plusieurs modes de réalisation particuliers, il est bien évident qu'elle n'y est nullement limitée et qu'elle comprend tous les équivalents techniques des moyens décrits ainsi 25 que leurs combinaisons si celles-ci entrent dans le cadre de l'invention. L'usage du verbe « comporter », « comprendre » ou « inclure » et de ses formes conjuguées n'exclut pas la présence d'autres éléments ou d'autres étapes que ceux énoncés dans une revendication. L'usage de l'article indéfini « un » ou « une » pour un élément ou une étape n'exclut pas, 30 sauf mention contraire, la présence d'une pluralité de tels éléments ou étapes. Plusieurs moyens ou modules peuvent être représentés par un même élément matériel. Dans les revendications, tout signe de référence entre parenthèses ne saurait être interprété comme une limitation de la revendication. Exemple 1 : exemple d'un extrait de la description d'une trame de la messagerie unifiée, d'envoi d'une demande d'autorisation de paiement faite par le serveur monétique local. Message demande autorisation Emis par AXIS pour PIKACHU 40 20 25 30 35 Numero du PAN sortie XSLT : "NULL", CI, GI, ' 3, ' 4'. --> Type de carte CI, GA, GI, VI, BM Montant de la demande d'autorisation> Image de la piste ISO xs:pattern="[0- 9]*" Exemple 2 : exemple d'une trame selon la messagerie unifiée. 2012-11-24 19:40:00.0Z 1 String String String CI String 0 0 String 1000 String 0 String 0 String 1234567890123456789012345678901234567890 String 0 String 0 0 String String String String String REVENDICATIONS1. Procédé pour effectuer une transaction électronique avec une carte de paiement, caractérisé en ce que, dans un système de paiement comportant un site local (19), un site central (33) distant du site local relié au site local par un premier réseau étendu de communication et un serveur d'autorisation de paiement (31) relié au site central par un second réseau étendu de communication, le site local comportant un serveur d'animation (21), un serveur monétique local (22), une pluralité de caisses de vente (20), une pluralité de terminaux (1) de paiement électronique d'une capacité mémoire inférieure à 96 mégaoctets, et un réseau local reliant la pluralité de caisses de vente au serveur d'animation et au serveur monétique local, chaque caisse de vente étant en outre connectée à un dit terminal de paiement électronique, ladite caisse de vente étant apte à communiquer avec ledit terminal de paiement électronique, le serveur d'animation comprenant une base de données des avantages applicables comportant des règles logiques d'attribution d'avantages commerciaux, le site central comportant un portail (30) de paiement, le serveur d'autorisation de paiement comportant une pluralité de modules d'autorisation associés à une pluralité de types de cartes, ledit serveur de monétique local étant apte à interroger le portail de paiement à travers le premier réseau étendu de communication, le procédé comporte les étapes suivantes: a) la caisse de vente initie la transaction électronique en transmettant (302) au terminal de paiement électronique une demande de lecture de carte, b) le terminal de paiement électronique lit la carte insérée dans le lecteur de carte pour obtenir des informations de ladite carte, incluant un identifiant d'un établissement émetteur et un identifiant de la carte,c) le terminal de paiement électronique transmet (309) à la caisse de vente les informations de la carte, d) la caisse de vente extrait des informations l'identifiant de la carte et l'identifiant de l'établissement émetteur, e) la caisse de vente vérifie si l'identifiant de l'établissement émetteur appartient à une liste de codes d'établissements autorisés, f) la caisse de vente transmet (309) au serveur d'animation (21) une demande d'avantages, ladite demande d'avantages comprenant les informations de ladite carte, g) le serveur d'animation construit une trame de demande de profil selon un format de messagerie unifiée, la trame de demande de profil comprenant les informations de ladite carte, h) le serveur d'animation transmet (310) au portail de paiement la demande de profil, i) le portail de paiement transmet les informations de la carte (312) au serveur d'autorisation de paiement, j) le serveur d'autorisation de paiement comprenant une base de données de profil, ledit serveur d'autorisation de paiement extrait le profil correspondant aux informations de la carte, k) le serveur d'autorisation de paiement interrogé transmet une réponse (313) de profil comprenant le profil extrait de la base de données au portail de paiement, I) le portail de paiement construit une trame de réponse de profil selon le format de messagerie unifiée, et transmet la trame de réponse de profil (314) 25 au serveur d'animation, m) le serveur d'animation applique les règles logiques d'attribution des avantages en fonction du profil compris dans la trame de réponse, n) le serveur d'animation transmet (315) au terminal de paiement électronique le profil compris dans la réponse, et des avantages attribués 30 audit profil, o) le terminal de paiement électronique transmet (316) le profil et les avantages à la caisse,p) la caisse calcule un montant total de la transaction en fonction des avantages (317) attribués au profil, q) la caisse de vente transmet au terminal de paiement électronique une demande de règlement (350) comportant des caractéristiques de la 5 transaction incluant le montant total, r) le terminal de paiement électronique créé une demande d'autorisation de paiement pour la carte, s) le terminal de paiement électronique transmet (353) au serveur monétique la demande d'autorisation de paiement comprenant le type de 10 carte, l'identifiant de la carte, le montant total, t) le serveur de monétique local construit une trame de demande d'autorisation de paiement selon le format de messagerie unifiée, la trame de demande d'autorisation de paiement comprenant la demande d'autorisation de paiement, 15 u) le serveur de monétique local poste (502) la trame de demande d'autorisation à l'attention du portail de paiement par un protocole de communication sécurisé, y) le portail de paiement transmet (504) la demande d'autorisation de paiement au serveur d'autorisation de paiement, 20 w) le serveur d'autorisation de paiement identifie le type de carte contenu dans la demande d'autorisation, X) le serveur d'autorisation de paiement sélectionne un module d'autorisation correspondant au type de carte et utilise le module d'autorisation sélectionné pour effectuer une vérification d'autorisation de 25 paiement, et le module d'autorisation génère une réponse d'autorisation de paiement, y) le serveur d'autorisation de paiement transmet (506) la réponse d'autorisation de paiement au portail de paiement, z) le portail de paiement envoie une trame de réponse (508) selon le format 30 de messagerie unifiée au serveur de monétique local, la trame de réponse comprenant la réponse d'autorisation de paiement, la trame de réponse étant destinée au terminal de paiement électronique,aa) le serveur de monétique local transmet (359) la réponse d'autorisation au terminal de paiement électronique, ab) le terminal de paiement électronique transmet (360) la réponse d'autorisation de paiement à la caisse de vente, ac) la caisse de vente envoie un acquittement (361) de transaction au terminal de paiement électronique, ad) le terminal de paiement électronique affiche la réponse sur un écran du terminal de paiement électronique, ae) le terminal de paiement électronique transmet l'acquittement (362) au 10 serveur monétique local. 2. Procédé selon la de revendication 1, comprenant en outre les étapes caractérisées en ce que : le portail de paiement convertit à l'intention du serveur d'autorisation de 15 paiement la trame de demande de profil selon le format de messagerie unifiée transmise par le serveur de monétique local, le portail de paiement convertit la réponse à la demande de profil émise par le serveur d'autorisation de paiement, en la trame de réponse à la 20 demande de profil selon le format de messagerie unifiée. 3. Procédé selon l'une des revendications 1 et 2, comprenant en outre les étapes caractérisées en ce que : le portail de paiement convertit (503) à l'intention du serveur d'autorisation 25 de paiement la trame de demande d'autorisation de paiement selon le format de messagerie unifiée transmise par le serveur de monétique local, le portail de paiement convertit (507) la réponse à la demande d'autorisation de paiement émise par le serveur d'autorisation de paiement, 30 en la trame de réponse à la demande d'autorisation de paiement selon le format de messagerie unifiée. 4. Procédé selon l'une des revendications 1 à 3, dans lequel le terminal de paiement électronique communique de manière sécurisée par une méthode de cryptographie asymétrique. 5. Procédé selon l'une des revendications 1 à 4, dans lequel le portail de paiement fournit en outre un certificat d'identification au serveur de monétique local. 6. Procédé selon l'une des revendications 1 à 5, dans lequel le 10 protocole sécurisé est le protocole SSL version 3, à clef de longueur non nulle. 7. Procédé selon l'une des revendications 1 à 5, dans lequel le protocole sécurisé est le protocole TSL. 15